:toc: macro

IRIS Client

toc::[]

== Feedback

If you have any feedback or questions mailto:iris@steiger-stiftung.de[just contact us].

== Participation

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 http://selector.harmonyagreements.org[Harmony standard]. Please sign the corresponding document for link:.clas%2FIRIS%20Gateway-Individual.pdf[natural persons] or for link:.clas%2FIRIS%20Gateway-Entity.pdf[organizations] and send it to mailto:iris@steiger-stiftung.de[us].

[[dev]] == Development === Commits

We use the specification https://www.conventionalcommits.org[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 repository

=== Branches

https://www.atlassian.com/de/git/tutorials/comparing-workflows/gitflow-workflow[Git 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 bugfix

[[java]] === Java parts

We use Java 17 and the following code style.

==== Eclipse

link:infrastructure/ide/eclipse-code-formatter.xml[]
link:infrastructure/ide/eclipse.importorder[]

==== IntelliJ

You can use following plugin to consume the eclipse formatting config:

==== Import order

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.

==== Save Actions

Use Save Actions with activated "organize imports" and format source code" in your IDE to check in the code in a tidy manner.

==== Blank lines

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:

[source, java]

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.

[source, java]

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:

[source, java]

Object someMethod(…) {

return condition ? if-true-do-this : else-do-that; }

==== Sonarlint

As further support, use https://www.sonarlint.org/[SonarLint] to avoid code smells. We don't currently use any fixed rules here, but Sonarlint gives useful hints during development.

Supporting organizations

Björn Steiger Stiftung SbR - https://www.steiger-stiftung.de

== License

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 link:LICENSE[] for more details.

Please see the https://api.reuse.software/info/github.com/iris-connect/iris-client[detailed licensing information] via the https://reuse.software/[REUSE Tool] for more details.

iris-connect / iris-client

readme

IRIS Client

[source, java]

void someOneLineMethod() { // Single-line statement }

[source, java]

// Multi-line instruction // Multi-line instruction }

[source, java]

return condition ? if-true-do-this : else-do-that; }

Supporting organizations