Software Coding Conentions


This page describes the coding conventions for the components project. The conventions on this page are intended to improve the readability of the software, allowing team members and external users to understand the code more quickly and thoroughly. All code is required to follow the conventions on this page. Other, more detailed conventions, can be found in the Java Code Conventions by Sun and in the Javadoc guidelines. These conventions will be enforced through code reviews.

Java Conventions

The conventions in this file supplement standard Java conventions, such as using packages to manage namespaces and placing only one class or interface per Java source file.

File Headers

All files must begin with a header section that contains basic information about the file. For non-LLNL contributors, the copyright holder won't be UC or LLNS, LLC. Please contribute source under the Lesser GNU Public License. The header format is as follows:

//
// File:        the filename for this file
// Package:     package in the distribution (e.g., GOV.llnl.babel.parser)
// Copyright:   (c) 1998-2000 Lawrence Livermore National Security, LLC
// Revision:    @(#) $Id: conventions.html,v 1.4 2000/04/25 20:09:28 skohn Exp $
// Description: one-line description of file
//
For example, the header for file Class.java in the gov.llnl.babel.ast package is:
//
// File:        Class.java
// Package:     gov.llnl.babel.ast
// Copyright:   (c) 1998-2000 Lawrence Livermore National Security, LLC
// Revision:    @(#) $Id: conventions.html,v 1.4 2000/04/25 20:09:28 skohn Exp $
// Description: AST node for an IDL class description
//
The Release and Revision entries are automatically updated by the Subversion system; Id by a date and author string. The @(#) is included for the SCCS what command. In files for which // cannot be used to begin a comment, use the comment tokens appropriate for that file. For example, headers in makefiles should use ##:
##
## File:        Makefile.in
## Package:     gov.llnl.babel.ast
## Copyright:   (c) 1998-2000 Lawrence Livermore National Security, LLC
## Revision:    @(#) $Id: conventions.html,v 1.4 2000/04/25 20:09:28 skohn Exp $
## Description: makefile for the ast package
##
and C files should use /* and */:
/*
 * File:        file.c
 * Package:     Babel run-time support code
 * Copyright:   (c) 1998-2000 Lawrence Livermore National Security, LLC
 * Revision:    @(#) $Id: 1.4 $
 * Description: A C file in the run-time support package
 */

Formatting

While the following conventions may appear a bit pedantic, a well-formatted code projects an image of professionalism and help us read each others code. The following is an example of a well-formated code fragment (note: header omitted):
/**
 * The <code>Foo</code> class demonstrates proper formatting conventions.
 */
public class Foo extends Bar {

   /**
    * The Foo constructor does nothing interesting but demonstrate an if block.
    */
   public Foo() {
      if (something) {

         /*
          * I would assume something interesting happens in this block.
          */
         if (something else) {
            ...
         }
      }
   }
}

Braces

Curly braces "{}" are requred for all scoping of if, else, while, and for constructs. For example, the following piece of code:
if (test)
   doSomething();
should be re-written as:
if (test) {
   doSomething();
}
The first case (without the braces) can be confusing if doSomething is followed by other code. The only exception to this rule is when the entire clause can be clearly written on one line, as in the following:
if (test) doSomething();
Nested if statements should be formatted as follows:
if (testA) {
   doResultA();
} else if (testB) {
   doResultB();
} else ... {
   ...
} else {
   doFinalElse();
}

Comments

All classes and public methods must be commented using JavaDoc comments /** */. The comment should clearly describe the purpose of the code, any necessary preconditions or postconditions, and assumptions. Because most Java methods are relatively short, there will be few in-code comments. If, however, a method becomes longer than perhaps ten lines or if the algorithm/logic is complicated, then it might be necessary to include comments within the method implementation. Use /* */ for in-code comments as shown in the Formatting section.

Do not use comments to remove or deactivate code! Delete unwanted code. Commented out code is extremely confusing to those who edit the code after you. All our changes are archive in a source code repository, so we can always look at the repo for old code.

Naming Conventions

The following list describes naming conventions for packages, classes and interfaces, methods, data members, and method arguments and local variables. Many of these conventions follow standard Java practice and many are suggestions from the Lakos book that have proven to be useful.

The following code sample demonstrates these conventions:
public class ObjectType {
   public static final int BLUE = 1;
   public static final int RED  = 2;

   private static String s_class_name = "ObjectType";

   private String d_name;
   ...
   public void setName(String name) {
      d_name = name;
   }

   public void setInheritanceRelationship(ObjectType some_type) {
      String some_string = "...";
      ...
   }
}

Resource utilization

All temporary resource allocations other than memory (i.e. files, network connections, a URL connection, and database connections) should be done using the following try...finally pattern or the equivalent:
FileInputStream in = null;
try{
   in = new FileInputStream(/* appropriate argument */);
   // insert code using "in" here
}
// insert any catch clauses you want here
finally {
   if (in != null){
      try {
         in.close();
      }
      catch(IOException ioe){ /* ignore */ }
   }
}
The situation is similar for an output file. Thing get more complicated when you layer several I/O classes as Java encourages:
FileOutputStream out = null;
BufferedOutputStream buf = null;
try{
   out = new FileOutputStream(/* appropriate argument */);
   buf = new BufferedOutputStream(out);
   // insert code using "buf" here
}
// insert any catch clauses you want here
finally {
   if (buf != null){
      try {
         buf.close();
      }
      catch (IOException ioe) { /* ignore */ }
   }
   if (out != null){
      try {
         out.close();
      }
      catch(IOException ioe){ /* ignore */ }
   }
}

buf has to be closed before out, so any buffered output is flushed to out. If you're not worried about runtime errors or exceptions, this can be simplified because the only thing that new BufferedOutputStream could throw is a runtime error or exception. Don't blame me. I didn't write the language. Just keep telling yourself, "Java is elegant; garbage collection is good."

No System.exit(), Runtime.exit() or Runtime.halt() calls outside of main()

Programmers should never call System.exit(), Runtime.exit(), or Runtime.halt() outside the static void main() driver method. Throw an exception instead; that's what they are there for.

Editing tools

This .emacs file tries to encourage these style guidlines.



Last Updated: Oct. 8, 2007