CSC 509 Design and Implementation Conventions

CSC 509 Design and Implementation Conventions
for Java Programs


  1. Define each class in one .java file. The only exception to this rule is for homogeneous collection or container classes. For such classes, a single .java file may (but is not required to) contain the definitions for both the container class as well as the elements that it contains. For example, a database class and the type of its elements may be defined in a single .java file. If the element type of the container has data members that are defined as other classes, all of those other class must be defined in separate .java files.

  2. Format and document .java files precisely as follows, with strict adherence to the format of the comments, including the number and placement of *'s and the amount of indentation.
    import ... ;
    
    /****
     *
     * The comment at the top of a .java file is a high-level description of the
     * class defined in the file.  Start the description with the words "Class X"
     * and then describe the purpose of the class and the major functions it
     * provides.  The function descriptions in this header comment are generally
     * brief, e.g., "Class X provides functions to add, delete, change, and find
     * its elements."  Do not list all of the function details in the header
     * comment, since full comments for each function appear below in the body of
     * the class, at the cite of each function declaration.  The header comment can
     * describe the data representation used in the class in high-level terms if
     * it's germane to explaining what the class is for.  The header comment does
     * not describe low-level details of the data representation or any details of
     * member function implementation.
     *
     *
     * Author: Full name and current email address of file's author; name is at
     *         least first and last, with middle name or initial if necessary or
     *         commonly used by author; email address appears in parentheses
     *         following full name; email address may be abbreviated to a local
     *         address if the full address can be expected to be known to.  E.g.,
     *         Gene Fisher (gfisher@thyme); John H. Smith (john_smith).
     *
     * Create Date: Date file was originally created (NOT last modified), in the
     *              format ddmmmyy, where dd is a one or two-digit month date, mmm
     *              is the three-character all lowercase abbreviation for the
     *              month, consisting of the first three characters of the month
     *              name, yy is a two-digit year.  E.g., 31jan00.
     *
     */
    
    [public] class X : extends Y implements Z {
    
        /**
         * Prose description of the function, describing what the function does,
         * not how it is implemented.  Describe the use of each parameter by name,
         * refer to the instance object as "this", and use the word "return" to
         * describe the return value if there is one.  Also describe each data
         * member used as an input and each data member modified as an output.
         * Modification to a parameter or data member includes indirect
         * modification to the value of a reference parameter or data member.
         * Stylistically, use complete sentences, avoid passive voice.
         *
         * pre: formal precondition
         *
         * post: formal postcondition
         *
         */
        public T1 FuncName(T2 t2, ..., Tn tn) [throws ...] {
    
            /*
             * Include comments for each local variable and comments above each
             * line or group of lines that describe how the function works.  All
             * but the "totally obvious" lines of code should be commented.
             * Comments for variables should be descriptive noun phrases.  Comments
             * for code lines should be in complete sentences.
             *
             * All code comments should be formatted exactly as as this one is: (1)
             * start with "/*" on a separate line, indented to the current level of
             * code indentation; (2) start each comment line with "*", indented to
             * current indentation + 1; (3) end with "*/" on a separate line,
             * indented to current indentation + 1.
             *
             * See below under "indentation and spacing conventions" for further
             * discussion of the format of code within a function body.
             */
    
        }
    
         ... other public functions ...
    
        Note no public data members 
    
    
        Protected functions in same format as public functions. 
    
        /** Comment describing data member */
        protected T1 varname;
    
         ... other protected data members ...
    };
    

  3. Indentation and spacing conventions
    1. Except for the specific indentation shown within a class definition above, indentation should be every 4 spaces.
    2. If tabs are used, assume tab width = 8 characters, so that spacing is physically 4-spaces-then-tab, ... .
    3. Do not set tabwidth to any value other than 8 characters in any editor.
    4. The following is a template for indentation and spacing of Java function bodies; blank lines are significant.
      T1 FuncName(T2 t2, ..., Tn tn) {
      
          /* Comment ... */
          Tv1 tv1;
          ...
      
          /** Comment ... */
          Tvm tvm;
      
          /*
           * Comment ... .
           */
          for (...) {
      
              /*
               * Comment ... .
               */
              if (...) {
                  ...
              }
              /*
               * Comment, if necessary.
               */
              else if {
                  ...
              }
              ...
              //
              // Comment, if necessary.
              //
              else {
                  ...
              }
          }
      
          /*
           * Comment ... .
           */
          while (...) {
              ...
          }
      
          /*
           * Comment ... .
           */
          for (start-expression; while-expression; end-expression) {
              ...
          }
      
          /*
           * Comment ... .
           */
          for (long-start-expression ... ;
                  long-while-expression ... ;
                      long-end-expression) {
              ...
          }
      
      
          /*
           * Comment ... .
           */
          switch (...) {
              /*
               * Comment, if necessary.
               */
              case c1:
                  ...
                  break;
              ...
              /*
               * Comment, if necessary.
               */
              case ck:
                  ...
                  break;
          }
      }
      

  4. Class and function naming conventions
    1. The names of MVP model types (i.e., class names) should be identical to the names of corresponding RSL objects. If the RSL object name does not obey the capitalization conventions for type names given below, then the RSL name should be changed accordingly.
    2. The names of model functions should be identical to the names of corresponding RSL operations, except the first letter of all function names should be lower case. If the RSL operation name does not obey the capitalization rules for function names given below (except for first letter lower case), then the RSL name should be changed accordingly.
    3. The names of view types (i.e., class names) should be the same as corresponding model names, with the suffix "UI" added. If a single design defines two or more alternative views, the view class names should be disambiguated with the type of UI for each. E.g., for model class PersonDatabase, view classes PersonDatabaseButtonUI and PersonDatabaseMenuUI are button-style and menu-style UI's, respectively.
    4. The names of view functions should be full-word mnemonic, including multi-word where appropriate, with the same capitalization conventions as for model type and function names. See "capitalization conventions" below for further details.
    5. The names of process types and functions should be full-word mnemonic, including multi-word where appropriate, with the same capitalization conventions as for model type and function names. See "capitalization conventions" below for further details.
    6. The names of constants should be mnemonic, typically one word or two words, all uppercase, with multiple words separated by underscores. E.g., LENGTH, MAX_SIZE.
    7. The names of data member access functions should start with "get".
    8. The names of data member setting functions should start with "set".
    9. The names of boolean-valued query functions should start with "is".
    10. The names of searching functions should start with "find".

  5. Capitalization conventions
    1. Type names (i.e., class names) should begin with a capital letter, and each distinct word in the name should be capitalized, e.g., PersonRecord. If an abbreviation is used in the name, all letters in the abbreviation should be capital, e.g. PersonDB.
    2. Function names should follow the same conventions as type names.
    3. .java root filenames must be the same as the class name, including capitalization.

  6. Variable naming conventions (including function parameters and class data members).
    1. For variable names of user-defined types:
      1. Variable names (including parameter and data member names) start with a lower case letter and otherwise follow the conventions for class names.
      2. A variable name may be a "proper" abbreviation of the type name, e.g., PersonRecord personRec, PersonDB personDB.
      3. A "proper" abbreviation is an abbreviation the characters of which are a proper subset of the characters in the words of the variable's type. E.g., PersonDB personDataBase is not a proper abbreviation.
      4. Short variable names are acceptable as long they are sufficiently mnemonically understandable in their context of use, e.g., PersonRecord pr, PersonDB pdb. Given the "proper abbreviation" rule, a variable name may be no shorter than the total number of capital letters in its type name.
      5. When a variable name abbreviates two or more words, the second words and beyond are capitalized.
      6. These rules are one of the few places in these standards open to subjective interpretation. E.g., in a context where few other variables start with the letter "p", the name "pRec" could be sufficiently mnemonically significant to be used instead of the longer "personRecord".
      7. In all cases, variable naming should be consistent throughout a project.
      8. In the case where two or more variables of the same type are declared in a given scope, the names should be suffixed with unique integers starting with 1, e.g., PersonRecord personRec1, personRec2 or prefixed or suffixed with short mnemonic identifiers, e.g., JTextField nameTextField or JTextField nameJtf.
    2. For variable names of atomic types or external library types that follow some other type naming conventions:
      1. Variable names (including parameter and data member names) should be lower case, short, and mnemonic, e.g.,
        boolean status
        int counter
        
      2. Where very short names are sufficiently mnemonic, such as with loop counter variables, single-character variables names are allowed, e.g., int i; for (i=1, ... ) ... ;
      3. The same numeric suffix and disambiguation rules above should be used.

  7. Size limits
    1. No function may be longer than 25 lines, excluding comments and blank lines. This rule may not be achieved by condensing lines in such a way as to violate any of the preceding formatting conventions. E.g., the following is legal
      for (i=1; i<=n; i++) {
          if (i % 2) {
              x.Foo1(i);
              x.Foo2(i);
          }
      }
      
      the following is NOT legal
      for (i=1; i<=n; i++) { if (i % 2) { x.Foo1(i); x.Foo2(i); } }
      
      nor is even the following
      for (i=1; i<=n; i++) {
          if (i % 2) {
              x.Foo1(i);
              x.Foo2(i);}
      }
      
    2. No class may have more than 25 public functions plus 25 protected functions, i.e., no more than 50 functions total. If a class has fewer that 25 public functions, it may have up to 50 functions total, however in may never have more than 25 public functions. Typically classes should have far fewer than 50 functions total.
    3. No class may have more than 25 protected data members.
    4. Note that combining the 25-line rule with the 50-function rule means that no .java file can be longer the 1250 lines of code, excluding comments. Typically, .java files should have far fewer than 1250 lines.

  8. Encapsulating non-conventional external libraries and utilities
    1. Resources provided by any external Java or C++ library that violates any of the preceding conventions must be encapsulated in exactly one class.
    2. That is, a "wrapper" must be placed around all non-conventional outside services.