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.
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.
3) We should not change the indentation / code writing style (brackets etc.) of a file when making a minor change to it.
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.
WDYT?
Big +1, even if I find myself guilty of this.
The benefit of clean style is not enough to pay the collective price of the reduced signal/noise ratio of the CVS diff knowledge broadcast.
If people start considering that channel to be too noisy, less people will take a look at it, thus killing our feedback loop that stabilizes our system.
I think that once you realize the danger of doing so, you also realize why you shouldn't do it.
So, thanks Bertrand for keeping it up!
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
