incubator-s4-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Neumeyer <>
Subject Re: beautiful code
Date Sun, 23 Oct 2011 17:54:22 GMT
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.


On Sun, Oct 23, 2011 at 10:20 AM, Matthieu Morel <> 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 (
>, 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



View raw message