On Friday, 1 July 2016 11:36:56 WEST Thiago Macieira wrote:
> Premises not under discussion:
>
> Qt source code is product and meant to be read by our users
> Qt source code must be clean and readable
> The above is not up for debate.
>
> For some time now, we've had a flurry of changes to Qt source code that uses
> the Standard Library's containers and algorithms, in the name of
> performance and often code size gains.
and in some cases better readability too. For example, whenever you use
cbegin, cfind, push_back you're writing code that's not only understandable by
Qt developers but also C++ developers.
Lowering the bar for C++ developers to start contributing is important.
I agree that STL also has many examples of worse readability, like very
verbose algorithms. We should tackle this on a case by case basis.
>
> I'm not disputing that there is a gain. But I am wondering about the
> trade-off we're making with regards to readability. For example, I was just
> reviewing this code:
>
> if (d->currentReadChannel >= d->readHeaders.size()
>
> || d->readHeaders[d->currentReadChannel].empty()) {
>
> Q_ASSERT(d->buffer.isEmpty());
>
"empty" is evil, I've fixed many places where the developer meant "clear()":
https://quickgit.kde.org/?
p=kdelibs4support.git&a=commit&h=c27b851e62307dd16780bf94aff8e6c650ac8dc7
I think we should even remove QList::empty() in Qt6, we want STL compat with
the good things, not the bad things.
> What do we do?
What do we do to fix what ? First state the problem.
You made a case against "empty" and then extrapolated to STL, as if you had a
3rd premise "STL is always less readable".
> empty -> isEmpty
Agreed, it's error prone.
> push_back -> append
> front -> first
> pop_front -> takeFirst
> cbegin -> constBegin
> cfind -> constFind
Disagreed, the later form is the common denominator between C++ and Qt
developers.
Regards,
Sérgio Martins
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
