I'd love to try (1) and (2), especially the the formatting tool integrated into the IDE. The goal, I think, is to have consistency to avoid unnecessary source control diffs. and make the code look nice and clean.
-leo On Sun, Oct 23, 2011 at 10:20 AM, Matthieu Morel <[email protected]> wrote: >> >> >> * 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 > -- -leo
