-
Notifications
You must be signed in to change notification settings - Fork 44
CodingConvention
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.
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 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 brace.
- There is a whitespace after
if
,else
,for
,while
, etc. and before their condition or brace. - All global fields are declared at the beginning of a class.
- All nested classes are declared at the end of the parent class.
- Use the keyword
this
only if necessary, never when not necessary. - Document all public API with Javadoc (i.e., all methods that have visibility public)
- Do not use public fields except for constants.
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.
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:
- Server URL:
https://monteverdi.informatik.uni-freiburg.de/sonar
- Server Label:
monteverdi
- Username:
<blank>
- Password:
<blank>
- 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.
- 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"
- 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
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"
- Home
- Ultimate Development
- Ultimate Build System
- Documentation
- Project Topics