Page History

...

SonarQube checks the openmrs-core code once a day. You can find the issues it found here

Read FindBugs to see where the rules come from.

...

• System.out.println(). Do not use System.out.println() in your code; instead log
• ex.printStackTrace(). Do not use ex.printStackTrace() in your code; instead log

Modifier order

Modifiers should follow the order suggested by the Java Language specification, sections 8.1.1, 8.3.1, 8.4.3 and 9.4:

...

• (expression false). Do not test equality with true or false; rather, simplify the boolean expression by removing the comparison and, if necessary, adding a leading exclamation mark (!) if you are testing for false expressions.
• if Statements. If statements should always be enclosed in braces. Always write "if (expr) {doSomething();}", never write "if (expr) doSomething();"
• Loop Braces. There should be braces for the in the the  case of any loop even there is only one statement.  Always Always write "while (condition) {doSomething();}", never write "while (condition) doSomething();"

...

• We deprecate methods that are part of our external public interface, instead of changing/deleting them in order to preserve backwards compatibility
  • External, public methods include:
    • service methods
    • public interface methods
    • domain object methods
  • Internal methods are not considered public, and therefore do not have to go through a deprecation cycle, and can be changed/deleted outright. These include:
    • DAO methods
• We will delete all deprecated methods when we make a new version (eg e.g from 1.x to 2.0)
• Use both the @Deprecated annotation and the @deprecated javadoc comment
• The @deprecated javadoc annotation should point to the new method that is replacing the current one
• The @deprecated javadoc annotation should also mention the version when the deprecation happened. e.g: @deprecated As of 2.0, replaced by {@link #getEncounters(EncounterSearchCriteria)}

...