Source Files

Source Files

On file-based host implementations of Java, the compilation unit is a Java source file. A Java source file should contain only one public class or interface definition, although it may also contain any number of non-public support classes or interfaces. Source files should be kept to less than 2,000 lines. Files longer than this become difficult to manage and maintain. Exceeding this limit is a good indication that the classes or interfaces should probably be broken up into smaller, more manageable units.

For all but the most trivial projects, source files should be kept under a version management system (such as SCCS in Unix).

Source File Naming

You should always follow a common naming convention for program source files. In Java, most compilers enforce a source file naming convention of the form: 

where ClassOrInterfaceName is exactly the name of the public class or interface defined in the program file. The file name suffix is always .java except on systems that support only three-character extensions; on such systems, the suffix is .jav.

Source File Organization

You should always follow a standard organization within a program source file. In Java, one possible format would be:

  1. file identifiers

  2. file comments

  3. package declaration

  4. import declarations

  5. one or more class/interface declarations

If you are using a version control tool based on SCCS, you can automatically generate much of the file identifiers by embedding SCCS ID strings. Some commonly used SCCS ID strings keywords include:

 %W%: module version        %E%: date 

Every source file should contain a package declaration. Omitting the package declaration causes the types to be part of an unnamed package, with implementation-defined semantics.


 package java.lang; 

Import statements should start in column 1, and a single space should separate the keyword import from the type name. Import statements should be grouped together by package name. A single blank line may be used to separate groups of import statements. Within groups, import statements should be sorted lexically.

Wildcard type-import-on-demand declarations (e.g., import java.util.*;) should not be used; use fully qualified type names instead. Specifically listing packages being imported makes their use clear to future readers of the program and also prevents someone later adding a new unexpected class to a file that conflicts with another type you are using.

Following the import sections are one or more class declarations and/or interface declarations, collectively referred to simply as type declarations. The number of type declarations per file should be kept small. There should be at most one public type declaration per file. The public type, if any, should be the first type declaration in the file.

Software Development. Building Reliable Systems
Software Development: Building Reliable Systems
ISBN: 0130812463
EAN: 2147483647
Year: 1998
Pages: 193
Authors: Marc Hamilton © 2008-2017.
If you may any questions please contact us: