• Wednesday August 20th 2008
• Do you want fries with that project?

Skip to Content

MozCreator Project

resources:	Home Mailing List Installation Source Code Developers Corner Members Bugs Screenshots
subprojects:	XulParser XulBrowser

Coding Style Guide

R.J. Keller

This document attempts to explain the basic styles and patterns that are used in the MozCreator codebase. New code should try to conform to these standards so that it is as easy to maintain as existing code. Of course every rule has an exception, but it's important to know the rules nonetheless!

This is particularly directed at people new to the MozCreator codebase, who are in the process of getting their code reviewed. Before getting a review, please read over this document and make sure your code conforms to the recommendations here.

General Practices

• Have you checked for compiler warnings? Warnings often point to real bugs.
• Don't put an else right after a return. Delete the else, it's unnecessary and increases indentation level.
• Don't leave debug System.out.println()s lying around. Instead use the Java logging system with the logging turned off by default.
• Insert Javadoc comments into all classes and functions (even private ones).
• When fixing a problem, check to see if the problem occurs elsewhere in the same file, and fix it everywhere if possible.

Code conventions

Use leading-lowercase, or "interCaps"

When defining a method or attribute, the first letter should be lowercase, and each following word should be capitalized. For example:

long updateStatusBar();

Use attributes wherever possible

Whenever you are retrieving or setting a single value without any context, you should use attributes. Don't use two methods when you could use one attribute. Using attributes logically connects the getting and setting of a value, and makes scripted code look cleaner.

This example has too many methods:

class blah
{
    public long getLength()
    {
    }
    public void setLength(long length)
    {
    }
    public Color getColor()
    {
        return Color.WHITE;
    }
}

The code will equal the same below but is more readable:

class blah
{
    public long length;
    public Color getColor()
    {
        return Color.WHITE;
    }
}

Use all caps for constants

When defining scriptable constants, the name should be all uppercase, with underscores between words:

public static final int ERROR_UNDEFINED_VARIABLE = 1;

Naming and Formatting code

Whitespace : No tabs. No whitespace at the end of a line.

Line Length : 80 characters or less (for Bonsai and printing).

Control Structures

if (...)
{
}
else if (...)
{
}
else
{
}

while (...)
{
}

do
{
}
while (...);

for (...; ...; ...)
{
}

switch (...)
{
    case 1:
        int var;
        break;
    case 2:
        ...
        break;
    default:
        break;
}

Classes

public class myClass extends JFrame implements ActionListener, WindowListener,
                             MouseListener
{
    private int mVariable;

    public myClass()
    {
        ...
    }

    public void myFunc()
    {
    }
}

For small functions in a class declaration, it's OK to do the above. For larger ones use something similar to method declarations below.

Methods:

public void myFunc()
{
    ...
}

Mode Line: Files should have an Emacs mode line comment as the first line of the file, which should set indent-tabs-mode to nil. For new files, use this, specifying 4-space indentation:

/* -*- Mode: Java; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 2 -*- */

Prefix Conventions

• g = global
• m = member
• a = argument
• s = static