[Development] White space / coding style patches welcome?
oswald.buddenhagen at digia.com
Tue Mar 12 14:11:11 CET 2013
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.
More information about the Development