For PathVisio development:

We use  checkstyle to check for certain style issues. Our checkstyle rules are defined in tools/dailybuild/pv_checks.xml

If you want to check your coding style using checkstyle you can...

• From the command line: simply run ant checkstyle and check the contents of the generated warnings.txt
• In eclipse: there is an eclipse plugin that you can install, and if you add our ruleset all style problems will be automatically underlined in yellow.

Regardless of checkstyle, here are some guidelines:

• Specify each import. Don't use wildcard imports.
• Use tabs for indentation
• Each java or perl file should begin with the same license header. Simply c/p from another file when starting a new one. The license header should be the very first thing, so before any "package" or "import" lines.
• Braces should line up, e.g.

  	public class Comment implements Cloneable
  	{
  		Comment (String _comment, String _source)
  		{
  			source = _source;
  			comment = _comment;
  		}
  		
  		public Object clone() throws !CloneNotSupportedException
  		{
  			return super.clone();
  		}
  		
  		public String source;
  		public String comment;
  	}
  

• case
  • classes and interfaces are CamelCasingStartsWithUpper
  • methods and fields are camelCasingStartsWithLower
  • static finals are ALL_CAPS_WITH_UNDERSCORES
  • enum constants are also ALL_CAPS_WITH_UNDERSCORES

• naming. We use prefixes to indicate semantic types, e.g. where a java type alone does not fully specify the meaning of the variable. For example, model coordinates and view coordinates both have the java type "double". to distinguish between the two we use prefixes.

• coordinates should get a prefix "m" for model, "v" for view (e.g. Mclass, mMethod or M_CONSTANT). This goes for font sizes as well. Conversion between the two is always done through the mFromV or vFromM methods, this way one can see if a line is correct at a glance. For example: mWidth = mFromV (vWidth) is correct. mWidth = mFromV (vWidth + mOffset) is wrong.

• use the following parts in names:
  • ...Dlg for dialogs (so not: AboutBox)
  • ...Wizard for wizards
  • ...Panel for sidepanels
  • Gex for stuff related to gene expression data (so not: ImportExprDataWizard)

• Try to keep Class names short and to the point. Don't put implementation details in the class name if it is not necessary. E.g. not "GmmlBpBrowser" but "BackpagePanel". Not "SuggestGdbCellEditor" but "GdbCellEditor".