Skip to content

CodingConvention

Daniel Dietsch edited this page Feb 11, 2022 · 15 revisions

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.

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]*$.

Here are some additional syntactic conventions that often come up:

  • 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.
  • 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.
  • All fields, local variables, and method parameters should be final if they can be made final.

We actually use many more conventions, but instead of listing all of them you should rely on the output of the SonarQube tool, which is available as an Eclipse plugin (see Eclipse-Settings) and as web interface.

Clone this wiki locally