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.

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 SonarLint tool, which is available as an Eclipse plugin (see the next section) and as web interface.

• Overview
• Dashboard
• Hotspots
• Issue overview

Installing and Configuring SonarLint for Eclipse

Installation

• Get the latest SonarLint from the Eclipse marketplace.
• Install it by dragging the install icon in your Eclipse window.

Configure the server connection

• Go to "Window" -> "Show View" -> "Other..." -> "SonarLint"
• Open the view "SonarQube Servers"
• Find the SonarQube Servers view in your workspace
• Add a new connection: (Note: The names have changed with SonarLint v3.1.)
• URL: https://monteverdi.informatik.uni-freiburg.de/sonar
• Username / Token: <blank>
• Password: <blank>
• Organization: <blank>
• Name: monteverdi
• Test the connection (it should work if you have internet and https://monteverdi.informatik.uni-freiburg.de/sonar is reachable).

Configure the project bindings

• Mark the projects you want to work with. If you want to work with all projects, mark them as follows
  • Mark all projects in your Ultimate Workspace
  • Unmark all that already have Sonar bindings
  • Unmark non-Java projects like Servers, BA_, Web,
  • Unmark all test projects
• Right-click on the marked projects and select "SonarLint" -> "Bind to a Sonar Qube Project..."
• The following dialog presents you with the local name of your projects in the left column, and the remote name on the right column.
• First, click "Refresh project list" in the dialog
• Then, check for each project that the right column contains the correct identifier.
• You can click in a cell of the right column and type an identifier, which will search the projects available on the server
• After you are finished, click "Finish"

Working with SonarLint
SonarLint will automatically analyse the classes you have open in your editor (during build, when you save, etc.) and synchronize its findings with our sonar server. To see Sonar issues for the currently focused editor, you need to use the "SonarLint Issues view".

• Go to "Window" -> "Show View" -> "Other..." -> "SonarLint"
• Open the view "SonarLint Issues"

In certain cases, it may be necessary to tell Sonar that it should ignore certain rules because it is justified in this particular case. You can use the annotation @SuppressWarnings("<ruleid>") or @SuppressWarnings({"<ruleid1>", "<ruleid2>",...}) for this purpose. The suppressed warning will still show up as violation of rule S1309, but this rule has just information level and serves as reminder for all the places were warnings were ignored. Eclipse will per default also issue a warning about an unknown warning type. You should configure your Eclipse to ignore those unknown warning types by switching the flag "Java" -> "Compiler" -> "Errors/Warnings" -> "Annotations" -> "Unhandled Token in '@SuppressWarnings'" from Warning to Ignore.