Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Jetty Java Coding Standards

The following is an example of the java formatting and naming styles to be applied to Jetty:

Code Block
import some.exact.ClassName;      // GOOD
import some.wildcard.package.*;   // BAD!

package org.always.have.a.package;

/* --------------------------------------------------------- */
/** Always have some javadoc
 */
class MyClassName
{
    // indent by 4 spaces.
    // use spaced to indent
    // The code must format OK with default tabsize of 8.

    private static final int ALL_CAPS_FOR_PUBLIC_CONSTANTS=1;

    // Field prefixed with __ for static of _ for normal fields.
    // This convention is no longer mandatory, but any given
    // class should either consistently use this style or not.
    private static String __staticField;
    private Object _privateField;


    // use getters and setters rather than public fields.
    public void setPrivateField(Object privateField)
    {
        _privateField=privateField;
    }

    public Object getPrivateField()
    {
        return _privateField;
    }

    public void doSomething()
        throws SomeException
    {
        Object local_variable = _privateField;
        if (local_variable==null)
        {
             // do Something
        }
    }
}

Javascript coding standards

With Ajax, we are using Javascript Javascript is used as a first class programming language, not just as a value-ad to html mark up. Thus it is very important that we establish good coding practises. The following are some key points to how we wish to use javascript in the ETrade jetty project:

Formatting

The formatting should be as for javascript, with the exception that tabs may be used for indents. If tabs are used for
indents, then spaces should not be used. ie all spaces or all tabs - no mixed.

...

Note that this is a very light weight form of object and we are not using any concept of class. It is equivalent to a javaclass of static members and simply groups related functions together for name space clarity.

Javascript also supports classe class via the prototype mechansimmechanism. This should also be used when appropriate but is not covered by the example above.

...

I know it is optional, but it makes it easier for old C-hacks to parse as well as making it easier for the interpretors to spot errors if a typo is made.

Use the behaviour library

We are using the behaviourlibrary and all developers should become familiar with it. The key aspect of behaviour is that it allows us to separate javascript from markup. We should not write any scripts of functions within html, nor should we hard code onclick or onload attributes within html. With Ajax, much of our html will be generated and thus using markup is not an option.

Unique Id's, multiple classes

...

Code Block
for (var i = 0; i < tokens.length; i++) {
  //process
}

Use behaviour

Many libraries have a concept of behaviours, not least the behaviour library: behaviour.
This is a good paradigm for separating concerns and avoiding excessive use of javascript within markup. Behaviours should
be used where possible/suitable.

Contact the core Jetty developers at www.webtide.com
private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services from 1 day to full product delivery