Starting with version 2 of SCM-Manager we have decided to change the code style and conform to more common rules. Furthermore we abandon the rule, that everything needs to have a javadoc description. Nonetheless we have decided against a \"big bang\" adaption of the new rule, because this would have lead to enourmous problems for merges from 1.x to 2.x.
\nSo whenever touching 1.x code you have to make the decision, whether it is appropriate to migrate some of the code you touch to the new style. Always keep in mind, that even slight changes may be dangerous becaus old code might not have a good test coverage.
\nAlso it is a good guide line to adapt Postel's law: Be conservative in what you do, be liberal in what you accept from others. So do not be the wise guy changing everything that does not fit to the rules below just because.
\nPlease mind the EditorConfig file .editorconfig in the root of the SCM-Manager and the configuration guide for IntelliJ IDEA. There are plugins for a lot of IDEs and text editors.
In the following, there are some rules we have come to value and that we would like to follow. Some are simple, others might need\nmore skill. If you feel overwhelmed by them, do not let them deter you. We love to support you in keeping these rules.
\nimport java.util.*if, else, for, while, try, and catch, between closing and opening parens after\nconditions and after semicolons, like this\nif (someCondition()) {\n thisShouldBeDone();\n} else {\n somethingOtherCanHappen();\n}for (int i = 0; i < some.length(); ++i) {\n doSomethingWith(i);\n}LoggerFactory with the class name you are in to create the Logger as a static final constant and\nnamed LOG or simply use the Slf4j annotation by Lombok (but not both in one class)error for failures an administrator should take care of immediatelywarn for failed processes that might lead to inconsistencies or unexpected behaviour like errors accessing external\nsystems or other servicesinfo for events that might be of interest in a daily business (like a user that has been blocked, a new access token\nthat has been created, a long running task that has been started or finished)debug for coarse information about internal processes (a pull request that has been closed, an event that has been\ntriggered, a mail that has been sent)trace to reproduce workflowsmyCollection.stream()\n .filter(item::isApplicable)\n .map(this::transform)\n .forEach(\n item -> processThisItem(item, some, more, input)\n );interface MyReceiver {\n ComputationResult compute(ComputationInput input);\n}\n\n@Data\nclass ComputationInput {\n private String textInput;\n private int numberInput;\n}\n\n@Value\nclass ComputationResult {\n private String textOutput;\n}this should only be used if necessary (that is, if the field has to be distinguished from another variable\nin the current scope with the same name, which should be avoided apart from constructors)final (mind, this does not account to fields; these should\nbe marked final if it is not explicitly intended otherwise)Take a look at our styleguide using yarn serve in /scm-ui/ui-styles directory.