CodingConvention

Ultimate's Coding Conventions

Contributing to Ultimate requires that you adhere to Ultimate's coding conventions. In general, we do not reject contributions that do not match our guidelines, but this may change in the future.

Most of the coding conventions are already applied automatically in Eclipse (using save actions), if you followed the installation instructions to import the predefined settings (see here). For example, these conventions include:

• Use only tabs for indentation.
• You should break lines after 120 chars.
• All curly braces open on the same line and close on their own line.
• All control statements (if, else, for, while, etc.) always use curly braces.
• There is no whitespace between method name and opening signature parenthesis.
• There is a whitespace after if, else, for, while, etc. and in front of an opening curly brace.
• All fields, local variables, and method parameters should be final if they can be made final.

Additionally, you should adhere to the following conventions that are not applied automatically.

Important Conventions

The following table lists the most important naming conventions.

	Description
Class names	Class names should begin with a upper case letter and be CamelCase. They must match the regular expression ^[A-Z][a-zA-Z0-9]*$.
Interface names	Interface names should begin with I and be followed with CamelCase. They must match the regular expression ^I[A-Z][a-zA-Z0-9]*$.
Method names	Method names should begin with a lower case letter and be followed with CamelCase. They must match the regular expression ^[a-z][a-zA-Z0-9]*$.
Field names	Field names should begin with m and be followed with CamelCase. They must match the regular expression ^m[A-Z][a-zA-Z0-9]*$.
Package names	Package names should be all lower case, should not contain any special symbols except _, and begin with de.uni_freiburg.informatik.ultimate.. The period symbol is used as separator. They must match the regular expression ^[a-z]+(\.[a-z][a-z0-9_]*)*$.
Static non-final field names	Static non-final fields (i.e., static fields that are not constant) should begin with s followed by CamelCase. They must match the regular expression ^s[A-Z][a-zA-Z0-9]*$.
Constant names	Constant names should be all upper case and may use _ to separate words. They must match the regular expression ^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$.
Local variables and method parameters	Local variables and method parameters should begin with a lower case letter and be followed by CamelCase. They must match the regular expression ^[a-z][a-zA-Z0-9]*$.

Addionally, here are some additional syntactic conventions that often come up:

• Class contents are ordered as follows: fields, constructors, methods, nested classes.
• Use the keyword this only if necessary.
• Document all public API with Javadoc (i.e., all methods that have visibility public)
• Do not use public fields except for constants.
• Avoid outcommented code
• Reduce indentation (e.g., if, while) where possible.

These cannot be done automatically, but you can rely on the output of the SonarQube tool, which is available as an Eclipse plugin (see Eclipse-Settings) and as web interface.

• Dashboard
• Coverage