Coding Conventions

In general, we follow the Java Code Conventions.

In the following are noteworthy divergences or additions which we use in our codebase:

Most important rule:

Write APIs so that client code is the best fluently readable code (if possible)! We mean by this: Before following a rule, think about the usage of the part of the API you are developing and think how a usage example would look like. Always make sure, that the clause in the usage example reflects as precisely as possible the task the code is performing.

Getters and setters

In general, we do not use any prefixes for getters and setters (get..., is..., set...). First of all, we basically almost never have setters in the codebase in any case, because we use immutable objects wherever possible. Secondly, we think that it makes the code more concise and readable. E.g. for example, if an object would have a property 'value' of type Double, an corresponding line to read this value would read like:

Double value = object.value();

Sometimes though it turns out to be useful to stick to the 'is' convention for boolean getters, as it can make the code more fluently readable. However, sometimes other words are used, like 'has', 'can', ... etc. We are not fully strict in this, but what should definitely be avoided are constructs like 'isCanApply()', 'isShouldKeep()', or similar.

Generic Type Parameters

In general we stick to the one-letter convention wherever possible. Since we realized that we are in danger for overusing similar terms very often interchangible (e.g. a 'scalar' could be the value of a tensor, or a e.g. the element of a field), we hereby define some conventions which we try to follow in the codebase (though they are still not fully correctly implementing at the time of writing this):

• T is a general type which can be applied whenever none of the following applies
• V represents the type of the values of a tensor (On purpose we do not use S for scalar here, because a scalar is a separate type in tensorics - a tensor with zero dimensions and exactly one value)
• E is used in the context of mathematical structures to represent the type of the element of the structure (e.g. of a field)
• E is also used to denote a type of expression (this usually does not clash with the usage in mathematical structures)
• R is used to denote the return type of an expression
• C is used for a type of a coordinate within a tensor

If more then one type parameter is required for the same type, usually, we do not use different letters, but devert to 2-character types with appended numbers (e.g. C1, C2, C3), like in the following (exemplary) method signature:

public <C1 extends C> Set<C1> allCoordinatesOfType(Class<C1> coordinateClass);