cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <>
Subject Re: [c3] code style
Date Fri, 19 Aug 2011 23:38:04 GMT
Hi Steven!
sorry for the misunderstanding I made: for 'avoided' I meant that code
format (of the whole file) should be avoided in the same commit that
contains the fix of an issue or add a new feature; if the commit
includes also the code format, it's not easy IMHO understanding what
the important modifications are - that's why I suggest to split these
operations in 2 separate commits :P

We could adopt standard Sun conventions - my only disappoint is about
the rule of 80 chars each column :/ We're in the era where everybody
big LCD monitors and having a so restricted space is not comfortable,
for example in apache-commons we moved to have at least 120, that
looks better.

maven codestyle is just my preferred one - no particular reason, just
looks in the way I like :P - but I don't have any reason to convince
everybody to adopt it, my personal rule is to respect the original
codebase style - most important is IMHO every Cocoon committer doesn't
apply a different/personal style, that's why I started the thread. I
don' think we need to open a vote to chose the cocoon3 style, just see
democratically which is the preferred one and adopt it.

Gratitude for sharing your thoughts, really appreciated!!!
Have a nice weekend, all the best!!!

On Sat, Aug 20, 2011 at 12:13 AM, Steven Dolg <> wrote:
> 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.
> Steven

View raw message