incubator-s4-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kishore g <>
Subject Re: beautiful code
Date Sun, 23 Oct 2011 17:27:18 GMT
For coding convention, we should use checkstyle plugin and use the
checkstyle eclipse workspace. This way we can use eclipse formatter so that
we keep don't create any diffs during merge.

Going one step forward we can fail the build if the checkstyle restrictions
are violated. This will ensure one to use checkstyle plugin. Findbugs plugin
is quite useful as well.

Kishore G

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message