cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Dolg <>
Subject Re: [c3] code style
Date Fri, 19 Aug 2011 22:13:29 GMT
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]
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.


View raw message