Am 19.08.2011 22:29, schrieb Simone Tripodi:
Hi all guys,
I noticed some code format during commits: please avoid it or do at
least in a separate commit, otherwise it makes not easy to understand
which are real changes and which are formats in the diff.
Moreover, code format in C3 is now inconsistent; we should choose IMHO
a common style and apply it as a general accepted "rule"; I personally
like the Maven one[1] but please share which are your preferences and
let choose together how the C3 code style shall look like :)
Many thanks in advance, all the best!!!
Simo
[1] http://maven.apache.org/developers/conventions/code.html
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
I'm pretty sure I can live with whatever decision will be made.
However, some of the things in the maven style strike me as odd.
They advocate not adding documentation for trivial things yet they
encourage people to add comments like
// ----------------------------------------------------------------------
// Public methods
// ----------------------------------------------------------------------
Which is probably the most trivial thing of them all (it's the first
word of the method signature and there's no cheating about that).
I'm also more and more becoming a fan of longer names for everything.
Short and descriptive sounds almost mutually exclusive, unless you think
"s","re" and "list" are particularly descriptive names.
I like Robert C. Martin's approach in "Clean Code", but it's too long to
explain here.
Blanks after opening parentheses and before closing parentheses is
probably my biggest pet peeve.
Especially when also allowing "myMethod()" <-- where's the space here?!
Are there really people who think "format( ( int ) file.length( ) )" is
any more readable than "format((int) file.length())"?
I think that's inflationary use of whitespace and bad.
I can understand the desire to be able to read diffs and understand
exactly and completely what changed.
OTOH I think the number of restrictions inversely correlates with the
likelihood that a "good yet not required" change is actually made.
And I believe that those "good yet not required" changes are the essence
of craftmanship. "it's good" vs "it's working"
The difference between "pat" and "pattern" is negligible - but there is one.
Same with formatting, spelling, comments and anything else.
But as I said at the beginning:
If we decide that formatting is something special, that must happen in a
separate commit or even be avoided (really?!), then I will stick to that
rule, of course.
Steven
