[prev][next]

2-File Names


This Section is commonly used file suffixes and names

2.1 File Suffixes
java software uses the ff. suffixes
file type suffix
java source .java
java bytecode .class

Common file Names
File Names Use
GNUMakefile the preferred name for markefiles.
we use gnumake to build our software
README The preferred name for the file that summarizes the
contents of a particular directory.

File Organization

A file consists of sections that should be separated by blank lines and an optional comment
identifying each section.

files longer than 2000 lines are cumbersome and should be avoided.

for an example of a java program properly formatted,"Java Source File Example" on page 18.

3.1 Java Source Files

Each Java source file contains a single public class or interface. When private classes and
interface are associated with a public class, you can put them in the same source file as the
public class. The public class should be the first class or interface in the file.

Java Source files have the following ordering:

  • Beginning comments (see "Beginning Comments" on page 2)
  • Package and import Statements
  • Class and interface declarations(see "Class and Interface Declaration" on page 3)


    • 3.1.1 Beginning Comments

    All source files should begin with a c-style comment that lists the class name,version
    information,date and copyright notice.

    /*
    *classname
    *
    *version information
    *
    *date
    *
    *copyright notice
    */


    3.1.2 Package and Import Statements

    The first non-comment line of most java source files is as package statement. after that,
    import statements can follow. For example:

    package java.awt;

    import java.awt.peer.canvaspeer;

    3.1.3 Class and Interface Declarations

    The following table describes the parts of a class or interface declaration,in the order that they
    should appear "Java Source File Example" on page 18 for an example that includes
    comments.
    Part of class/interface Declaration Notes
    1.Class/interface documentation
    comment(/**...*/)    		 see "Documentation Comments" on page 8 for
    information on what should be in this comment
    2.class or interface statement
    3.class/interface implementation
    comment(/*...*/),if necessary    		 this comment should contain any class-wide or
    interface-wide information that wasn't appropriate
    for the class/interface documentation comment.
    4.Class(static) variables first the public class variables, then the protected,
    then package level(no access modifier),
    and then the private.
    5.Instance Variables First public, then protected, then package
    level(no access modifier), and then private
    6.Constructors
    7.Methods These methods should be grouped by functionality
    rather than by scope or accesssiblility. for
    example, a private class method can be in
    between two public instance methods. the goal is
    to make reading and understanding the code easier