ContributorGuidelines

#Great code is the base for a great project.

We are trying to make Wise a great project and to make it possible we agreed about some guideline and tools to write better, easy to read and with an uniform style. We are using eclipse as IDE, and we are using some good stuffs it (and some plugins) drive to us to achieve our goals. Would you like to contribute, but you are using another IDE? Well enrich this page describing how to get same goals with IDE xyz would be a first contribution

##Code Style

We have defined a code style profile for eclipse. You can find it on the subversion on the file named testedby-code-formatter-profile.xml

Please use it setting your Project properties "Java CodeStyle/Formatter". Please set also on "Java Editor/Save Actions" the preference to format code (all lines) on save. Use the same style make code easier to read and don't generated false difference on SCM due to different formatting.

##eclipse-preferences.epf

You will find in svn also an Eclipse preference file. Import it into your workspace (may I suggest you to use a dedicated workspace if you don't want to mix preference for different project area?). What is it supposed to do? It change some standard preference for workspace (you can take a look to it, it isn't hard to read). Some example: force to add our licence header on new created classes, make easier some static import useful for our tests, mark as error some situation normally marked as warning (remember great code?).

##Javadoc

Well, what we think about is simple: if you provide a Javadoc provide it something useful and maintain it. For this reason our Eclipse preference mark as error Javadoc out of synch with the code. More General our policy about Javadoc is to always provide them on public interface, and limit this kind of documentation to its purpose: document the API usage. Don't put user manual in Javadoc, keep this kind of docs in dedicated documents, external of code

##Concurrency annotation

We are using jcip annotation to mark concurrency contract of classes. They help a lot during interfaces/classes design forcing programmers to careful think about, and help a lot us to communicate clearly our intention about concurrency each other. Moreover they are exposed in JavaDoc enriching them of Thread safe information. And last but not least they are used by findbugs (see after on this page) to verify some concurrency correctness compile time.

##Findbugs

Findbugs is "a program which uses static analysis to look for bugs in Java code". We are using its Eclipse plugin that show during normal works possible bugs in your code. In our experience it helps a lot to write better code, not only in terms of bugs, but also readability and efficiency. In the svn you will find .fbprefs file with our findbugs preference

##Test: Unit test Of course we are using TestedBy for this area ;)

##Test coverage

We are using emma as coverage tool. It is included in our ant's build file under "coverage" target. Ideally when you contribute with some code you shouldn't get a lower coverage than before you contribution. IOW for each code added, please add tests to verify it.

##Isuue tracking We are using google code issue tracking to track issues and fix our roadmap. We always try to define next scheduled versions and the succeeding one, fixing for them release date. Any contributor who would take over a issue would ideally define or update evaluated complexity and mark issue resolved when he have implemented solution and provided a unit test for it. Please have a look to "Subversion commit messages" paragraph too. We try to use subtask to split issues in shorter and easier to track steps.

##Subversion commit messages

To make work easier for all commit messages should contain the name of the issues resolved in that commit. For example "issue 1". Any other descriptive text is welcome, but not strictly necessary. Ideally a commit would be referred to a single issue, even if sometimes it isn't possible or good