> > > * Good design will make the code easy to understand but eventually we > need to implement complex logic. For those cases write very detailed > comments to help other people read your code. >
>From the oracle/sun java code conventions ( http://www.oracle.com/technetwork/java/codeconventions-150003.pdf), I like the following recommendation: --> "Note: The frequency of comments sometimes reflects poor quality of code. When you feel compelled to add a comment, consider rewriting the code to make it clearer." We should set up a wiki page for these guidelines... Another related thing: formatting. We don't have a strict formatting policy, that can be enforced automatically. Many projects don't either, but unfortunately it leads to some really annoying merge operations, or diffs hard to understand. In addition, taking care of manually enforcing formatting standards really gets in the way of productivity. The best approach would be to only think once about that, in order to establish a standard, then just let the editing environment apply the standard for us! I've seen for instance that in some places, the length of the line is limited to 80. I much prefer 120, that's easier to read and it takes advantage of the higher resolution in modern computers. What should we go for? In other projects, I used, with very good results, a mechanism to enforce strict code formatting (that can be applied automatically upon every save action in modern IDEs). It can be added to continuous integration, so that any divergence is immediately detected. If other committers are interested, we could : 1. establish strict standards and 2. I could look at how to set up a validation mechanism in continuous integration for the 0.5 release. Matthieu
