Rules and Standards

Global layout

Each Java source contains a single class or interface.

The code presentation must obey the following order:

• Copyright

  // COPYRIGHT DASSAULT SYSTEMES 2000

• Not mandatory, for development sources only, an historical account of the modifications and their authors

  /* ----------------------------------------- * creation: 04/01/2000 by egr * modification: 13/02/2000 by egr to add the dump method * modification: 23/05/2000 by egr. IR A234789. to treat the case when the file does not exist. ---------------------------------------------*/

• Package Statement

  package com.dassault_systemes.ENOVDesktop.ENOVDtpCommand;

• Import Statements

  // PortalBase Framework import com.dassault_systemes.catweb.base.catlet.CSO // to manage current selection import com.dassault_systemes.catweb.base.catlet.CATlet // to retrieve the CSO import com.dassault_systemes.catweb.base.event.CSOListener // to subscribe to CSO // PortalApplications Framework import com.dassault_systemes.catweb.databackend.dataType/Driver2 // to implement the interface

  • Always import each used class and interface even if it belongs to the current package
  • Never use the * character to import a whole package.
  • Group them by framework and package
  • Explain for what each one is used
    
• Class/Interface documentation comment in javadoc style

  /** * Class which manages the current selection. * <br><b>Role</b>: This class stores a list of the currently selected elements. * Each CATlet has one and only one instance of a CSO object. * To get this instance, call the {@link ICATlet#getCSO()} method. * Use this class to add or remove elements from the selection. * This class dispatches {@link CSOEvent} when the selection is modified. * Implement the {@link CSOEventListener} interface to subscribe to this events. */

• Class or interface statement

  public class CSO

• Optionally, a class/interface comment in C++ style with implementation information (which cannot be written in an API documentation).
• Class (static) variables sorted by modifiers (public, protected, no modifier, private). Every variable must be preceded by a javadoc comment.
• Instance variables sorted by modifiers (public, protected, no modifier, private). Every variable must be commented in javadoc style.
• Constructors. Each one is preceded by a javadoc comment.
• Methods grouped by functionalities rather than by accessibility. Each one is preceded by a javadoc comment.

[Top]

Method layout

• Indentation

  • Always use the same type of indentation (2 or 4 spaces)
  • Use spaces, not tabs.
    
• Line Length < 80 characters

  When an expression will not fit on a single line, break it after a comma or before an operator.
  Align the new line with the beginning of the expression at the same level on the previous line, or if it is too far on the right, use an indentation twice as big as usual.

  MyMethod(longArg1, longArg2, longArg3, longArg4, longArg5); longName1 = longName2 * (longName3 + longName4 - longName5) + 4 * longname6;

• One Statement per Line

  int level; // indentation level int size; // size of table

  however, the following declarations are acceptable:

  int x, y, z; // point coordinates

  In the same way, do not use embedded assignments (ex: a=b=c).

• Blank Spaces

  Air out, use spaces:

  • after commas in argument lists
  • around binary operators (except .)
  • between the expressions of a for statement
  • after a keyword (while, for, ... but not after a method)
  • after a cast.

  for (expr1; expr2; expr3) { a = b / (c + d) * e++ + (int) l; myVar.myMethod(a, b, c); }

• Braces
  • Be constant in your way of using braces around statements.
  • Always use braces with if-else or for statements even if there is only one line.

  class Sample extends Object { int var; void Print(int i, int j) { if (condition) { statement1; } else { statement1; statement2; } } ... }

• Parentheses

  Use parentheses liberally in expressions involving mixed operators to avoid operator precedence problems.

  if (a == b) && (c == d)

  But avoid them in a return statement unless they make the return value more obvious in some way.

  return; return myDisk.size(); return (size ? size : defaultSize);

• Constants
  Numerical constants (literals) should not be coded directly, except for -1, 0, and 1, which can appear in a for loop as counter values. Use static final variables instead.
  
• Type names
  Always use simple type names in the class body (except when a name conflict prevents it). That obliges to add the import declaration corresponding to the type if it belongs to another package.
  
• Local variables
  • Declare local variables at the beginning of the block where they are used
  • Initialize local variables where they're declared
  • Do not hide higher level declarations by giving names which already exist.
    
• Conditions
  Put constants first:

  if (MAX_LENGTH == lg)

• Naming
  As regards naming, see CAA2 Naming Conventions.

[Top]

Naming Conventions

• method names are to be verbs or verb phrases, in mixed case with the first letter lowercase and the first letter of any subsequent words capitalized. e.g., run(), runFast().
  Specific methods:
  • The getter and setter of a V property should be getV and setV. e.g., setPriority
  • A method that tests a boolean condition V should be named isV, e.g., isInterrupted
  • A method that converts its object to a particular format F should be named toF, e.g., toString.
• variable names are to begin with a lowercase letter
• a constant (public final variable) name should be a sequence of one or more words, acronyms, or abbreviations, in uppercase letters, with components separated by underscore "_" characters. eg: MAX_VALUE.
• Hungarian notation is useful to recognize data members, parameters and local variables and also to know the type of the variables. Therefore we recommend the usage of the following prefixes:
  • _ for data member
  • i for input variables (method arguments)
  • a for array

As regards the other variables, using a prefix is optional.
The usually used prefixes are:

• b for boolean
• c for char
• n for number
• o for object
• s for string

and, as for classes, an abbreviation of three or four characters is often used as a prefix:

• btn for Button
• dlg for Dialog
• lbl for Label
• rec for Record
• rect for Rectangle

[Top]

Comments

All the exposed entities (class, interface, public and protected methods and fields) must be preceded by a comment in the javadoc style. See Documenting Your Interfaces and Classes. But even the not exposed entities should be commented in the same way, particularly in the CAA use cases.
Moreover, C++ style comments should be used to give overviews of code and provide additional information to make the code easier to understand. However, redundant information must be avoided.
Comments are written at the third singular person (e.g., creates).

[Top]

History

Copyright © 2000, Dassault Systèmes. All rights reserved.