cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Collen <>
Subject Re: [POLL] don't edit files just for style changes?
Date Sat, 17 Apr 2004 19:39:42 GMT
Bertrand Delacretaz wrote:
> Lately there have been several hints that people are annoyed by commits 
> consisting only of style changes (rearranging imports, "cleaning up" 
> indents) etc.
> Of course, there are always good intentions behind such changes, but 
> IMHO changes which make no difference to the actual code, are:
> a) risky, because every time one edits a file there's a small risk of 
> making a change to the code without meaning it
> b) a waste of our collective energy, as (hopefully) many of us are 
> regularly scanning CVS diff mails, and if it's just to find out that two 
> brackets have been moved it's not very useful.
> I have three suggestions:
> 1) As a general rule, we should refrain from making such changes to our 
> code, unless there is a good reason (code change for example) to edit 
> the file in question.

+1 on condition [a], below

> 2) When editing a file for a good reason, we should look for such 
> "style" problems and fix them at the same time, or as a separate commit, 
> but before testing our changes.

+1 as a separate commit, per Joerg's message about "losing" changes. 
Then again, the commit message should clearly say what is going on.

> 3) We should not change the indentation / code writing style (brackets 
> etc.) of a file when making a minor change to it.

+.75, what consists of a minor change? Little one-line bugfixes?

> The idea is to keep the flow of CVS diff messages as low as possible, to 
> save our neuronal bandwidth for more important things than the placement 
> of brackets or the order of imports.

At first I was a little dumbfounded by the proposition, but now that I 
think of it, it makes more sense, especially for people who are either 
getting paid to work on Cocoon full-time, or people who are taking time 
out of their busy day to contribute to the project when they could be 
earning money in other ways (i.e. consulting).

My condition [a] on the item above was that we should try to eliminate 
people from having to make these code changes in the first place.  We 
should be following the standard Java style, and most IDEs can help 
enforce this.

Likewise, we could also make a run through all our code with something 
as a once-over to fix most of the problems and then "highly encourage" 
people to follow the Java style guidelines. I know it's probably 
micromanaging people by enforcing a code convention, but I would also 
like to argue that readable code which is consistently formatted is 
easier to read (and maintain), and thus costs less time than wasting 
scanning CVS commit messages for code which was reformatted.  Remember, 
a lot of work goes into maintaining a project than actually creating new 

Is it possible to fit a code reformatting filter between our cvs commit 
and the repository?

> -Bertrand


View raw message