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!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sat, Aug 20, 2011 at 12:13 AM, Steven Dolg <steven.d...@indoqa.com> 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] 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 >
