Thermostat/DevelopmentStyleGuide

From IcedTea

Jump to: navigation, search

Thermostat Home

Contents

1 Style Guide for Thermostat Development

1.1 General Code style

  • License header goes on top of every file
  • 4 spaces instead of tabs
  • Avoid trailing spaces
  • Thermostat source code is Java 7+ compatible with exceptions of those parts which get injected into target JVMs, which should be Java 6+ compatible.

Make sure to configure your preferred editor to use spaces over tabs. You can do this in Eclipse IDE via CTRL+3 > Type: "formatter" > select "Formatter Java/Code Style". Then edit the default profile and change the Tab policy to "Spaces only".

Image:ChangeTabPolicy.png

1.2 Maven/POM conventions

  • The version for all dependencies should be defined in the main (thermostat) pom file
  • The version should be defined as a property named project-name.version. Example: commons-cli.version
  • If the OSGi version differs from the project version, it should be defined as a separate property project-name.osgi-version. Example: commons-codec.osgi-version

1.3 Top Level Directory conventions

TODO

1.4 OSGi Conventions

  • API interacting with OSGi should be as limited as possible. Ideally, only bundle activators should be making use of it. With a few exceptions, the rest of the code must be decoupled from OSGi. Inject dependencies into Command objects from activators rather than making a Command implementation aware of OSGi.

1.5 Tests

  • Every class Foo should have a unit test in the form of a class FooTest.
  • The test should be in the same package as the class it is testing. Test-specific hooks should be package private in the original class.
  • GUI code should be unit tested using FEST and Cacio.
  • For complex features, an integeration test should also be added if possible. Integration tests go in the `integration-tests` module.

1.6 Commit message style

Commit messages are normally of the form:

Short summary of the fix

A detailed description of fix with additional details, like steps to
reproduce the problem, explanation of any subtle changes, links to
docs or anything that might help when examining this changeset in the
future to figure out why a change was done.

Also, try and keep commit message lines to under 80 characters.

You can also link a bug using the PR notation. Something like this 
commit fixes PR666, which refers to a bug with the id 666.

The last few lines are important. They list the reviewers and a link to
the mailing list thread (or the equivalent) where this patch was
reviewed.

Reviewed-by: userid1, userid2, userid3
Review-thread: http://link.to.mailing.list.discussion.example.com/
Personal tools