Re: Hadoop coding style guideline
Aaron Kimball wrote:
First, I've been picked on by others for using this brace style:
if (foo) {
stmt;
} else {
otherstmt;
}
and have been told to drop the braces because they look ugly if stmt or
otherstmt are only one line.
In http://java.sun.com/docs/codeconv/html/CodeConventions.doc6.html#449though,
the sun coding conventions *clearly* say that braces are always to
be used. Can we get a ruling here?
My preference is to permit both. I like to maximize the amount of
readable logic per screen, and find that close braces around one-line
expressions don't improve readability (since indentation already
indicates the nesting) and decrease the amount of per-screen logic.
However I know reasonable people who prefer to always fully-bracket
their code. I see no strong reason to force one style over the other.
And second, what's our story on tabs vs. spaces?
Spaces are preferred, since tabs are inconsistently interpreted. The
correct interpretation of a tab is to move to the next column evenly
divisible by 8, but many editors are configured differently, so tabs are
best avoided.
Doug
Re: Hadoop coding style guideline
My preference is to permit both. I like to maximize the amount of readable logic per screen, and find that close braces around one-line expressions don't improve readability (since indentation already indicates the nesting) and decrease the amount of per-screen logic. However I know reasonable people who prefer to always fully-bracket their code. I see no strong reason to force one style over the other. I see a couple benefits to choosing one and being consistent: consistency makes code more readable (the main motivation for a style guide) and works well with automated tools (eg would be nice if checkstyle didn't generate huge diffs). Would also be nice to follow the Sun convention since that's what Hadoop claims it does. Thanks, Eli
Re: Hadoop coding style guideline
I have to weigh in strongly on the pro-braces side. I've seen too many
instances (not necessarily in Hadoop) where there was something like:
if (foo)
stmt;
otherstmt;
It's not about readability. It's about maintainability.
Daniel
Doug Cutting wrote:
Aaron Kimball wrote:
First, I've been picked on by others for using this brace style:
if (foo) {
stmt;
} else {
otherstmt;
}
and have been told to drop the braces because they look ugly if
stmt or
otherstmt are only one line.
In
http://java.sun.com/docs/codeconv/html/CodeConventions.doc6.html#449though,
the sun coding conventions *clearly* say that braces are always to
be used. Can we get a ruling here?
My preference is to permit both. I like to maximize the amount of
readable logic per screen, and find that close braces around one-line
expressions don't improve readability (since indentation already
indicates the nesting) and decrease the amount of per-screen logic.
However I know reasonable people who prefer to always fully-bracket
their code. I see no strong reason to force one style over the other.
And second, what's our story on tabs vs. spaces?
Spaces are preferred, since tabs are inconsistently interpreted. The
correct interpretation of a tab is to move to the next column evenly
divisible by 8, but many editors are configured differently, so tabs
are best avoided.
Doug
Hadoop coding style guideline
Hi, I was trying to make a patch and looking over the Hadoop guidelines for code at http://wiki.apache.org/hadoop/CodeReviewChecklist, trying to follow the conventions. Looking through code I found a few patterns, however, these differ even in the same class sometimes. Here's a collection of method declaration styles I gathered from 2 or 3 files: http://pastie.org/707389 I have to admit Sun's code conventions are a bit unclear too, so maybe a list of settings for the IDE like tab size, indent, continuation indent, exceptions to the rule, etc. would help. Cosmin
Re: Hadoop coding style guideline
So, IMO, the goal should be the examples on 10-24 or 31-36. +1 I agree with Todd: the highlighted snippets are most appropriate as Java coding style. On 11/20/09 10:54 , Todd Lipcon wrote: My opinions on the groups of line numbers from that pastebin: 1-3: Definitely not - no reason for ) on its own line 5-8: no, throws should be indented 10-13: I think this is acceptable 15-19: also acceptable IMO 22-24: acceptable - lines wrapped due to column limit should indent their wrappings 26-29: bad 31-36: seems the same as 16-19, so OK 39-47: bad - bizarre 50-53: bad - seems like a mistaken space 56-59: same as 1-3, seems bizarre 62-66: also bizarre like 50-53 So, IMO, the goal should be the examples on 10-24 or 31-36. If others agree, perhaps we should put some of these examples on the wiki? -Todd On Fri, Nov 20, 2009 at 9:04 AM, Cosmin Lehenecleh...@adobe.com wrote: Hi, I was trying to make a patch and looking over the Hadoop guidelines for code at http://wiki.apache.org/hadoop/CodeReviewChecklist, trying to follow the conventions. Looking through code I found a few patterns, however, these differ even in the same class sometimes. Here's a collection of method declaration styles I gathered from 2 or 3 files: http://pastie.org/707389 I have to admit Sun's code conventions are a bit unclear too, so maybe a list of settings for the IDE like tab size, indent, continuation indent, exceptions to the rule, etc. would help. Cosmin
