Opale project coding standards

Opale project coding standards

Revision History
Revision 0.1Feb 19th, 2003
Translation from the French document v0.1
Revision 0.2April 13th, 2003
Translation from the French document v0.2
Revision 0.3June 21th, 2003
Some minor corrections

Table of Contents

Java coding standards

Java coding standards

Meta-rule : .  If a rule is missing in this document, refer to the IPSquad Java coding standards version 1.0. If this rule is missing from the IPSquad standards then refer to SUN coding standards. If this rule is missing from these standards then do what you think is best !!!

The Opale project coding standards are based upon IPSquad coding standards (version 1.0) with these modifications or precisions :

  • Header: Every file must have a header with the following content :

    	      /*
    	      * OPALE is a scientific library under LGPL. Its main goal is to
    	      * develop mathematical tools for any scientist.
    	      *
    	      * Copyright (C) 2002 Opale Group
    	      *
    	      * This library is free software; you can redistribute it and/or
    	      * modify it under the terms of the GNU Lesser General Public
    	      * License as published by the Free Software Foundation; either
    	      * version 2.1 of the License, or (at your option) any later version.
    	      *
    	      * This library is distributed in the hope that it will be useful,
    	      * but WITHOUT ANY WARRANTY; without even the implied warranty of
    	      * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
    	      * Lesser General Public License for more details.
    	      * 
    	      * You should have received a copy of the GNU Lesser General Public
    	      * License along with this library; if not, write to the Free Software
    	      * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
    	      * 
    	      * You can visit the web site http://opale.tuxfamily.org to obtain more
    	      * information about this program and/or to contact the authors by mail
    	      * developers@opale.tuxfamily.org.
    	      */
    	    

  • File organization :  Every file contains first the license header, then the package directive, then the imports relative to the Java API, then those relatives to used extern libraries and at last those of the project.

  • Default constructor : . The Opale objects always have a default constructor except on specific cases where it is then put in comments.

  • Classes clonage : Every Java object which inherits from the OpaleObject class implements the Cloneable interface. That is to say, every object must redefine the clone() method. In the other cases it is highly advised to implement Cloneable except in specific cases, such as the singleton design pattern for example.

  • Variables and calculations. The standards for the variable affectations and calculation expressions are : Every affectation or calculation must be written in a way to make easier the comprehension of used algorithms.

  • Interface name .  The name of an Interface always begins with an i capital letter. Like IxyFt.

  • Accessors.  The behavior of getXXX methods, where XXX is a class attribute, is to return a reference pointing to the attribute. If you want to return a copy of the attribute, the accessor's name should be prefixed with "cgetXXX" or "getCXXX" instead of "getXXX".

  • Exceptions and assertions.  When semantically wrong parameters are passed to public methods, those methods must throw an exception. Public methods are responsible for passing correct arguments to private methods. Private methods do not throw exception and they use the assertion mechanism provided by the opale.tools.Assert class to insure that parameters are correct. The assertion mechanism is only enabled the debugging mode which is controlled by the opale.tools.Debug class.


Opale Team : February 14 2004 19:30:24.






valid xhtml image