incubator-s4-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Neumeyer <leoneume...@gmail.com>
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.

-leo

On Sun, Oct 23, 2011 at 10:20 AM, Matthieu Morel <mmorel@apache.org> 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

Mime
View raw message