FILE ORGANISATION

[Contents] [Prev] [Next]

3 - File Organization

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

3.1 Java Source Files

Each Java source file contains a single public class or interface. When private classes and interfaces 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:

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:

package com.fitltd.web;
//*************************************************************
// Main module of the Servlet
//
// Author: Serguei Poliakov,  December 2000
//
// Notes:
// 1. Normally SCREEN_NAME value form the request is used to determine
//    which page is been processed (the value is setup in LF_SCREEN class
//    as a hidden input field
// 2. Path ./serguei clears all database connections and all cashed data
// 3. File FIT.INI is used to read configuration
//**************************************************************

3.1.2 Package and Import Statements

The first non-comment line of most Java source files is a package statement. After that, import statements can follow. For example:

package java.awt;

import java.awt.peer.CanvasPeer;

Note: The first component of a unique package name is always written in all-lowercase ASCII letters and should be one of the top-level domain names, currently com, edu, gov, mil, net, org, or one of the English two-letter codes identifying countries as specified in ISO Standard 3166, 1981.

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.


Part of Class/Interface Declaration


Notes


1


Class/interface documentation comment


See "Documentation Comments" 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 accessibility. 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.

[Contents] [Prev] [Next]