On Mon, Feb 09, 2015 at 09:05:09PM +0100, Marc Mutz wrote: > On Monday 09 February 2015 20:10:44 André Pönitz wrote: > > On Mon, Feb 09, 2015 at 09:36:46AM +0100, Marc Mutz wrote: > > > I find Q_NULLPTR *beautiful* (bautyful is deeper than pretty), because I > > > know at some point we will be able to just s/Q_NULLPTR/nullptr/. That's > > > not possible with 0 (not even with NULL (could be C code)), so I don't > > > see the point in continuing to use 0. > > > > At some time you will be able to ran clang-modernize with the Use-Nullptr > > transformation or something similar. > > > > Until then your attempts your tic to replace 0 by Q_NULLPTR as "white space > > fixes" will only convert a tiny fraction of the code base, introduce > > yet-another-non-uniformly-used-idiom. > > > > Diversity is good in biology. Less so in code. > > By the same token, we should stop fixing code formatting "mistakes" in > passing, since we could just run clang-format.
Incidently, that is something I think should be done and also something that's at least conceptually and partially done in the Qt Creator code base. Code style changes there tend to start with a "allowed to be fixed in passing", only to be followed up with a few "now all-in" dedicated changes after a while. "In passing" alone never worked sufficiently well, not even within single plugins. A currently ongoing example of such activities is conversion of Qt4-style connects to Qt5-style. I don't think the argument of whitespace changes making the history hard to read carries a lot of weight in a git world. Andre' _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
