Jump to: navigation, search

Difference between revisions of "RAP/CodingStandards"

< RAP
(Java code)
(Reformatted coding conventions, removed final parameter declarations, changed max line length to 100)
Line 1: Line 1:
'''Coding Conventions'''
+
This document describes the coding conventions used by the RAP project.
  
This document describes the basic Coding Conventions used by the RAP development team.
+
'''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.
  
'''Note''': These conventions affect only newly created code. RAP reuses a lot of code from RCP (currently by copying that code) - These code-snippets are normally 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:
  
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:
+
== General rules for text files ==
  
=== General rules for text files ===
+
==== Unix newlines ====
 +
Text files must use only Unix line delimiters (<code>\n</code>).
  
* Text files must use Unix line delimiters (\n)
+
==== UTF-8 ====
* If files contain non-ASCII characters, they have to be UTF-8 encoded
+
If files contain non-ASCII characters, they have to be UTF-8 encoded.
* TAB characters are forbidden
+
* 80 characters per line is maximum
+
  
=== Java code ===
+
==== No TABs ====
 +
We use spaces only to indent. TAB characters are forbidden in RAP source files.
  
* Method parameters (with the exception of abstract methods) are never assigned to and have to be declared as final.
+
==== 100 chars per line ====
* Initialize fields in the constructor, not in the declaration statement.
+
We just decided to extend the line length from 80 to 100 characters.
* In general, do one thing in one line (e.g. don't write <code>int a, b;</code>)
+
This is a hard limit.
* There must be at most one return statement in each method
+
* Do not use continue, break or return statements in loops
+
* Use for loops if there is a known number of iterations in the loop, else use while loops (i.e.: don't use for loops with a list iterator)
+
* Do not use variable names with only one letter (except loop variables in loops)
+
* Insert a space after opening braces and before closing braces(i.e.: <code>if( someMethod( arg1, arg2 ) == array [ i ] ) { ... </code>)
+
* If lines are broken at an operator, the operator must be on the next line, and the next line is indented once. (No naked operators at the end of a line)
+
* All public API must be marked with a <code>@since</code> tag at the class/interface level. Only methods, fields etc. that are added in a later release cycle must carry their own <code>@since</code> tag. The version number denotes the *release* version in which the element was/will be published the first time.
+
  
 +
== Java code ==
  
'''Formatter and Code Template Settings'''
+
==== No parameter assignments ====
 +
Method parameters must never be overwritten by an assignment.
 +
 
 +
==== 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
 +
<s>int a, b;</s>
 +
 
 +
==== Only one return per method ====
 +
A method must not have multiple return statements.
 +
 
 +
==== No continue, break, return in loops ====
 +
It is not allowed to exit loops using <code>continue</code>, <code>break</code> or <code>return</code> statements.
 +
 
 +
==== No misused <code>for</code> loops ====
 +
Use <code>for</code> loops ''only'' if there is a known number of iterations in the loop, otherwise use <code>while</code> loops.
 +
Particularly, don't use <code>for</code> loops with a list iterator).
 +
 
 +
==== Speaking names ====
 +
Use speaking names for variables, methods and classes.
 +
One letter names are only allowed as loop variables in loops.
 +
 
 +
==== Spaces inside braces ====
 +
Insert a space after opening braces and before closing braces. Examples:
 +
if( value == array[ i ] ) {
 +
  someMethod( arg1, arg2 );
 +
}
 +
 
 +
while( count <= maxNumber ) {
 +
  ...
 +
 
 +
==== Linebreak before operators ====
 +
If lines are broken at an operator, the operator must be on the next line, and the next line is indented once.
 +
There must be no naked operators at the end of a line. Example:
 +
 
 +
String message =  "Long text that does not fit on a "
 +
                  + "single line...";
 +
 
 +
==== <code>@since</code> Tags ====
 +
All public API must be marked with a <code>@since</code> tag at the class/interface level. Only methods, fields etc. that are added in a later release cycle must carry their own <code>@since</code> tag. The version number denotes the ''release'' version in which the element was/will be published the first time.
 +
 
 +
 
 +
== 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.
 
All relevant projects are configured with project-specific settings to use the formatter and code templates that are used by the RAP team.

Revision as of 18:09, 6 March 2011

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:

General rules for text files

Unix newlines

Text files must use only Unix line delimiters (\n).

UTF-8

If files contain non-ASCII characters, they have to be UTF-8 encoded.

No TABs

We use spaces only to indent. TAB characters are forbidden in RAP source files.

100 chars per line

We just decided to extend the line length from 80 to 100 characters. This is a hard limit.

Java code

No parameter assignments

Method parameters must never be overwritten by an assignment.

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 a, b;

Only one return per method

A method must not have multiple return statements.

No continue, break, return in loops

It is not allowed to exit loops using continue, break or return statements.

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 with a list iterator).

Speaking names

Use speaking names for variables, methods and classes. One letter names are only allowed as loop variables in loops.

Spaces inside braces

Insert a space after opening braces and before closing braces. Examples:

if( value == array[ i ] ) {
  someMethod( arg1, arg2 );
}
while( count <= maxNumber ) {
  ...

Linebreak before operators

If lines are broken at an operator, the operator must be on the next line, and the next line is indented once. There must be no naked operators at the end of a line. Example:

String message =   "Long text that does not fit on a "
                 + "single line...";

@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.


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.