[Development] White space / coding style patches welcome?

[Oswald Buddenhagen]

On Tue, Mar 12, 2013 at 01:34:54PM +0100, Axel Waggershauser wrote:
> I thought splitting by type first and potentially by directory second
> if it is too big still, would be best because it reduces the burden on
> the reviewer: only one type of change should be easier to skim over
>
the downside of doing it by type is producing a lot of history noise -
commits you need to skip over when you are researching history.

if the burden on the reviewer is too big, then you didn't split it up
according to directories/modules sufficiently well.

i did this exercise a few years ago already (just to have it discarded),
and the outcome wasn't *that* huge (though there were some problem
areas, like qtmultimedia and qt3support).

> > somebody attempted this just a few days ago, but gave up when the scope
> > of the undertaking became clear. i can't find the change now ...
> 
> I don't think the requirement to only accept a patch if it fixes
> 'every' whitespace problem in one go would be reasonable as it would
> result in exactly this situation: too much work to do/review it all at
> once so one gives up.
> 
ok, let's modify the requirement: you don't need to set out to fix every
problem. but in the lines you touch because of fixing specific problems,
i want to see the remaining issues fixed as well.
specifically, i want trailing whitespace and tabs/indentation fixed.
the issue you started with is kinda optional for me.
spaces around binary operators are kinda secondary, too. i don't even
know how big the problem is.

> >>   b) only do it in files where it is used inconsistently / where the
> >> wrong occurrences are the minority?
> >>
> > no, do it consistently - to have a good example everywhere, and no
> > excuses for messing up. then we can make the automatic checking
> > stricter, too (which lars said was a precondition for even bothering
> > with a cleanup to start with).
> 
> As a final goal, it should obviously be consistent everywhere but I
> thought it makes sense to make a difference between files where there
> are some random style issues here and there (most of the code) and
> files that are written pretty consistently but according to a
> different style guide (like the qmake generator stuff).
>
there are a few projects which have vastly different style (qlalr) or
should be excluded out of principle (anything 3rdparty). i wouldn't make
an exception for anything else, including the qmake generators (they are
seeing incremental coding style cleanups anyway). if you have specific
projects in mind, we can discuss.