All RAP bundles that contain JavaScript files have a jshint configuration file. All JavaScript has to conform to these settings. It is recommanded to use the [http://github.eclipsesource.com/jshint-eclipse/ eclipse ide jshint plugin].

[[Category:RAP]]

[[Category:RAP]]

Revision as of 06:25, 3 July 2012

This document describes the coding conventions used by the RAP project.

Note: These conventions affect only code created by the RAP project. RAP reuses a lot of code from RCP (currently by copying that code) - this code is not re-formatted.

We follow the Sun conventions for the Java language: http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html (Note that this includes braces around if, while and for constructs even if their 'then'-clause or body has only one line; see section 7.4 of the conventions.) Apart from that, the following rules are mandatory:

Initialize in constructor

Fields should be initialized in the constructor, not in the declaration statement.

One thing per line

In general, do one thing in one line.
For example, don't write

int count = 0, line = 1; // BAD

but instead:

int count = 0;
int line = 1;

No misused for loops

Use for loops only if there is a known number of iterations in the loop, otherwise use while loops.
Particularly, don't use for loops to iterate over a list iterator.

@since Tags

All public API must be marked with a @since tag at the class/interface level. Only methods, fields etc. that are added in a later release cycle must carry their own @since tag. The version number denotes the release version in which the element was/will be published the first time.

No empty lines

Empty lines in methods are not permitted. The desire to separate blocks with empty lines is often a sign for too long methods. Extract them into methods of their own.

An exception thereof are test methods. To visually emphasize the set up - execute - assert structure it is permitted to separate these with empty lines like in the example below:

Structuring test methods like this is inspired by Robert C. Martin's book Clean Code. See the BUILD-OPERATE-CHECK pattern in the chapter about unit testing.

Formatter and Code Template Settings

All relevant projects are configured with project-specific settings to use the formatter and code templates that are used by the RAP team.

Note: This formatter isn't able to cover all style conventions we use, but it helps to get started.
We recommend not to run the formatter on the entire file, but to select a region of code to format.
When you press Ctrl-Shift-F in the Java Editor while a section (e.g. a method) is selected, only this section will be formatted.