Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current ·  View Page History

Best practices

Developers of Sonar core should :

  • build with maven before commiting to subversion. Continuous integration watches you !
  • commit frequently into subversion
  • never commit incomplete changes (Subversion is not a backup system)
  • use meaningful comments when doing a subversion commit, always with the JIRA key and title (e.g. "SONAR-6 Apply license LGPL")
  • subscribe to both mailing-lists user@sonar.codehaus.org and scm@sonar.codehaus.org 
  • abuse of unit tests (JUnit 4), with the help of mock objects (Mockito)
  • think IoC (Inversion of Control pattern)
  • abuse of functional tests (Selenium). Tests are written in the Selenese format (HTML).
  • use comments and javadocs only when necessary
  • do not forget the license header on all Java and Ruby files
  • respect the code formatting described below

Code formatting

  • replace tabulations by 2 whitespaces
  • follow this template :
  • never do this :
  • but this :

Tips and tricks

Connect to Derby from command line

  • download derby(the same version as used by sonar)
  • set the DERBY_HOME property
  • execute the command $DERBY_HOME/bin/ij
  • connect to the database :

Compare XML files from JUnit

Use XMLUnit. The dependency is already defined into maven.

Warning : There's a bug on the similar() method. Contrary to the documentation, it fails if nodes are not in the same order.

Override Object.equals(), hashCode() and toString()

You can use EqualsBuilder and HashCodeBuilder from commons-lang to simplify. Just define the fields to compare. Example on the Rule class :

Labels
  • None