If you have any feedback or questions just contact us.
We are happy about your contribution to the project! In order to ensure compliance with the licensing conditions and the future development of the project, we require a signed contributor license agreement (CLA) for all contributions in accordance with the Harmony standard. Please sign the corresponding document for natural persons or for organizations and send it to us.
We use the specification Conventional Commits for our commit messages and want to use it to generate our changelogs and semantic versions as automatically as possible. Each commit message should thus contain a type and, if necessary, the note "BREAKING CHANGE". As types we have not specified anything beyond the specification.
Commits should always refer to an issue (user story, bug or task). Therefore, always include the reference to the issue at the end of the commit message.
Refs #{issue number} ⇒ same repository
Refs iris-connect/iris-backlog#{issue number} ⇒ other repositoryGit Flow is our branching strategy and the base of our release process. Thus, development takes place on feature branches, which is merged in the develop branch. The main branch is reserved for releases.
Branches should be named according to the following scheme:
feature/{issue number}-{name}
bugfix/{issue number}-{name}
chore/{issue number}-{name} ⇒ which is neither feature nor bugfixWe use Java 17 and the following code style.
You can use following plugin to consume the eclipse formatting config:
-
static imports, wild card used from the first declaration
-
*- all unmatched imports -
java.… -
javax.– -
org.… -
com.…
For non-static imports we switch to * imports after the 10th import.
For static ones we always use * ones.
Use Save Actions with activated "organize imports" and format source code" in your IDE to check in the code in a tidy manner.
Use blank lines to group pieces of code logically: variable initializations go together, followed by the method invocations that use those variables. There’s no hard rule here. It’s just nice to be able to identify different steps in the execution order.
For blocks (if clauses, methods) we start with a blank line if the subsequent code is longer than a single line:
void someLongMethod() {
// First statement
// Second statement
}
VS.
void someOneLineMethod() {
// Single-line statement
}Symmetric blocks usually also use a blank line on the end to clearly separate the blocks' content from the outer instruction. Again, the single line rule applies, here, too.
if (…) {
// Single line instruction
} else {
// Single line instruction
}
but
if (…) {
// Multi-line instruction
// Multi-line instruction
} else {
// Multi-line instruction
// Multi-line instruction
}The intermediate lines surrounding the …} else {… make it easier to see where the block flips.
In general, for if-else-clauses, prefer the ternary expression (condition ? if-true : if-false) over an if block.
That creates incentives to rather extract the statements to be executed in either and make the overall expression readable.
If the overall expression gets so long it would line break, it’s nice to read if the three parts are each brought onto a single line:
Object someMethod(…) {
return condition
? if-true-do-this
: else-do-that;
}As further support, use SonarLint to avoid code smells. We don’t currently use any fixed rules here, but Sonarlint gives useful hints during development.
-
Björn Steiger Stiftung SbR - https://www.steiger-stiftung.de
Currently this code is licensed under Affero GPL 3.0.
This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the LICENSE for more details.
Please see the detailed licensing information via the REUSE Tool for more details.