Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "RAP/CodingStandards"

< RAP
(Add rule for short methods, reorder)
 
(6 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
This document describes the coding conventions used by the RAP project.
 
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.
+
'''Note''': These conventions affect only code created by the RAP project. Code from SWT, JFace and RCP 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:  
+
We follow the Oracle (Sun) conventions for the Java language: [http://www.oracle.com/technetwork/java/codeconvtoc-136057.html oracle.com/technetwork/java/codeconvtoc-136057.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 ==
Line 37: Line 37:
 
  String message =  "Long text that does not fit on a "
 
  String message =  "Long text that does not fit on a "
 
                   + "single line...";
 
                   + "single line...";
 
==== Speaking names ====
 
Use speaking names for variables, methods and classes.
 
One letter names are only allowed as loop variables in loops.
 
  
 
==== No parameter assignments ====
 
==== No parameter assignments ====
 
Method parameters must never be overwritten by an assignment.
 
Method parameters must never be overwritten by an assignment.
  
==== No multiple returns ====
+
==== Initialize in constructor ====
A method must not have more than one return statement.
+
Fields should be initialized in the constructor, not in the declaration statement.
For example, instead of:
+
  
public boolean isReady() {
+
==== Speaking names ====
  if( processor != null ) {
+
Use speaking names for variables, methods and classes.
    return processor.isInitialized(); <strong>// BAD</strong>
+
One letter names are only allowed as loop variables in loops.
  }
+
  return false;
+
}
+
  
write this:
+
==== Keep methods short ====
 +
Write methods that do only one thing. If a method becomes too long, try to split it up into smaller ones.
 +
The method name should indicate what the method does, it should normally start with a verb.
  
public boolean isReady() {
+
==== No empty lines ====
  boolean result = false;
+
Empty lines in methods are discouraged. The desire to separate code blocks with empty lines is often an indication that a methods does more than one thing. Consider to extract these blocks into methods of their own.
  if( processor != null ) {
+
    result = processor.isInitialized();
+
  }
+
  return result;
+
}
+
  
==== No dirty exit ====
+
An exception to this rule are unit tests. To visually emphasize the set up - execute - assert structure it is permitted to separate these with empty lines like in the example below:
It is not allowed to exit a loop using <code>continue</code>, <code>break</code> or <code>return</code> statements.
+
For example, this code:
+
  
for( int i = 0; i < values.length; i++ ) {
+
  public void testFoo() {
  if( values[ i ] == wanted ) {
+
    Foo foo = new Foo()
    found = true;
+
 
    break; <strong>// BAD</strong>
+
    boolean actual = foo.bar();
  }
+
 
}
+
    assertTrue( actual );
 +
  }
  
can also be written without the <code>break</code>:
+
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.
 
+
for( int i = 0; i < values.length<strong> && !found</strong>; i++ ) {
+
  if( values[ i ] == wanted ) {
+
    found = true;
+
  }
+
}
+
 
+
==== Initialize in constructor ====
+
Fields should be initialized in the constructor, not in the declaration statement.
+
  
 
==== One thing per line ====
 
==== One thing per line ====
Line 105: Line 84:
 
==== <code>@since</code> Tags ====
 
==== <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.
 
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.
 
==== 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:
 
 
  public void testFoo() {
 
    Foo foo = new Foo()
 
 
 
    boolean actual = foo.bar();
 
 
 
    assertTrue( actual );
 
  }
 
 
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 ==
 
== Formatter and Code Template Settings ==
Line 127: Line 91:
 
'''Note''': This formatter isn't able to cover all style conventions we use, but it helps to get started.
 
'''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.
 
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. [[Media:Example.ogg]]
+
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.
[eclipse.org/rap/resources/rap-java-formatter.xml link download rap java formatter]
+
 
 +
[http://eclipse.org/rap/resources/rap-java-formatter.xml download formatter]
 +
 
 +
== JavaScript Code ==
 +
 
 +
All RAP bundles that contain JavaScript files have a jshint configuration file. All JavaScript has to conform to these settings. It is recommended to use the [http://github.eclipsesource.com/jshint-eclipse/ eclipse ide jshint plugin].
  
 
[[Category:RAP]]
 
[[Category:RAP]]

Latest revision as of 10:49, 19 December 2013

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

Note: These conventions affect only code created by the RAP project. Code from SWT, JFace and RCP is not re-formatted.

We follow the Oracle (Sun) conventions for the Java language: oracle.com/technetwork/java/codeconvtoc-136057.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

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...";

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.

Speaking names

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

Keep methods short

Write methods that do only one thing. If a method becomes too long, try to split it up into smaller ones. The method name should indicate what the method does, it should normally start with a verb.

No empty lines

Empty lines in methods are discouraged. The desire to separate code blocks with empty lines is often an indication that a methods does more than one thing. Consider to extract these blocks into methods of their own.

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

 public void testFoo() {
   Foo foo = new Foo()
 
   boolean actual = foo.bar();
 
   assertTrue( actual );
 }

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.

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.

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.

download formatter

JavaScript Code

All RAP bundles that contain JavaScript files have a jshint configuration file. All JavaScript has to conform to these settings. It is recommended to use the eclipse ide jshint plugin.

Back to the top