Follow the code conventions of the public majority by default. Here are only things are listed, that deviate from that or are controversial.

Use only private or public visibility modifier. Method arguments are implicitly final. The source code has to comply with net.splitcells.dem's Java grammar. Classes must not be final, because this is useful for net.splitcells.network.community.via.javadoc.

Here are problems encountered with Java listed and not solved. These should be considered, when an alternative language to Java is searched.

There is no known way, in order to define a static API in Java in a similar portable, easy, performant and adaptable way, like C header files. The most portable way seems to be the usage of the service locator pattern and similar patterns, but the resulting code requires some non-trivial boiler code.

Use Java records only for primitive attributes, function arguments or return values, as complex attributes cause problems via their identity, equals and hashcode.

Inheritance works great as adhoc wrappers and type and implementation extenders, but nothing more. Inheritance does not support swapping out the parent implementation, which makes it often not portable in practice.

Readability is preferred over compactness, but compactness is still important.

Every full name should have an unambiguous meaning. This means a renaming would be valid in general, if every instance of the name can be renamed, while still maintaining the correct meaning. Names are preferred to abbreviation and abbreviation are preferred to symbols as a shorthand.

If there is an inverse usage for a given method likeisEmpty, consider creating a dedicated method. This minimizes the likelihood of misreading such an inverse usage. For example, it helps to create an isEmpty and an hasElements method, because it is relatively hard to distinguish someObject.doSomething().doSomtingeElse().isEmpty() and !someObject.doSomething().doSomethingElse().isEmpty() from one another, if one just skim through the code.

For method names prefer using a noun, if the of the method is to retrieve something. Use verbs instead, if the goal of the function is to do something or to change something. Use camelcase for identifiers by default and capital case with underscores for constants. For long names like testing methods do not use a name where every word is separated by an underscore, if the name is a sentence like test_performance_difference_of_assignments_and_tables. This simplifies the guidelines and is more compliant with existing code scanning tools for Java.

Avoid these if possible, because they are often not intuitively understandable. There are reasonable exceptions, where the abbreviations are intuitively understandable:

1. Impl
2. Doc

Use following command in order to start the Java process. java -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8000 -jar [path to jar, that is executed]

In this case suspend=y let's pauses the program start, until something connects to the debugging port.

Any not explicitly allowed usage of Lombok is prohibited, in order to limit dependencies, that are hard to replace and to avoid unintended effects caused by Lombok.

Val is used as a syntactic sugar for final var. Lombok was removed temporary in the past, as val was increasing the compile time by about a factor of 10. This was caused by the fact, that in the past Lombok needed to do the type inference by itself. Since Lombok 1.18.22 val is implemented by replacing it with final var. This should be a lot faster regarding the compile time.

@Accessors(chain=true), @Setter and @Getter is used to create getters and setters, in order to minimize boilerplate code and to focus on definitions. This also makes it easy to see, when only some getters or setters are overwritten with custom implementations. It is preferred but not possible to create getters without prefixes and setters with a set prefix. The get prefix is used in order to differentiate between static and not static methods. This is not required, but comes handy, in order to reason, why static getters or constructors do not use the same get prefix.

@EqualsAndHashCode and @Data are primarily used for data objects.

@ExtensionMethod would be nice, in order to extend existing classes like String, but this feature is experimental and has bugs.

@Delegate would be an excellent feature for aspects and such, but this feature does not work, if only some methods are manually overridden. Furthermore, this feature may even be removed from Lombok according to its documentation.

Do not use Java's naming convention regarding generic parameters, as this makes it hard, when the generic parameter has a special meaning, that is not easy to encode via 1 character. So, this rule can also be disabled in code scanning.