On 1 July 2016 at 20:36, Thiago Macieira <thiago.macie...@intel.com> 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.
>
[..]
Thanks for raising this topic, Thiago.
The topic resonates for me in the following way (as just a reader of the
code):
1. No doubt the algorithms and such improve our programming experience and
the simplifies activity that costs us most: reading/understanding the code
and intents. I'd applaud having the Option 3 and see Option 2 as nice to
have for future Qt.
Moreover I would happily consider using the wrappers (once stabilized
enough, they would be inline anyway?) in my projects out of the Qt source
tree. Sometimes I do consider adding that myself and like many others
probably already have a tiny bit of buried in my "utility" codes. That
would be no longer so much a necessity.
2. A mature C++ engineer shall not forget that the market average is way
below that level. I think it's not our intent to build a barrier for
contributors this way. I've seen a few projects that use no single
algorithm constructs, yet these are successful and mature projects. It's
unscientific but I recognize average level for a C/C++ programmer is way
below of level represented on this mailing list or boost/STL lists.
People have chosen Qt for simplicity _and_ consistency (no particular
order). Before knowing one or more typical profile of Qt contributors (like
personal in UX design?) it's too easy to assume everyone is so clever or on
its way to awesomeness.
3. I think it would be a good signal to the user base if Option 3 (or/and
then Option 2) would be communicated publicly that the Qt-ifed container
extensions will come to the public API. Not tomorrow but one day, like it
was the case with the QtJSEngine feature that started as a private
component. A next small-big thing from the Qt team.
4. I perceive *consistency in naming* as a higher value for a project than
potentially encouraging or winking at some "other" sub-communities to get
more people on board. A building block of a project is its internal coding
guideline. Qt is known from promoting consistency. I remember the
guidelines were used as a template in my professional work while creating
similar guidelines for others.
After all it's even a bit poisonous to compare release dates of projects.
E.g. Fortran or Visual Basic 1.0 predates HP's STL. Despite different
markets addressed, all of them are potentially interesting to build
contributor base; would it be sane to propose allowing for VB naming
schemes inside Qt? Or Fortran's?
Even if I am repeating someone else's observation, let's not forget: even
if a fraction of Qt's source code would contain bits familiar for
programmers thinking the "STL" way and having "STL" muscle memory, the
rest, the majority of the code follows the Qt guidelines. It's easy to
imagine single expressions or a simple code block that uses two naming
guidelines, usage of verbs/nouns, camel case, underscores. Some of that is
an aesthetic layer, some of that is more like provoking human errors. I bet
it can be independently measured how much effort it costs to switch between
naming while reading a single C++ block with mixed naming.[*]
And such code could not be too easily rejected in a code review.
Engineers are good at switching context once a while, but I am not sure
they are good at switching it every few seconds. Pros can cope with that,
75% of their efficiency is still very good, but that's just it.
I am afraid we would move to discussions about where the borders are, how
to change our (currently) very good guideline document to address the
change. We would enter area where this (specific, dedicated) project has
not even two two approaches but a mix that's hard to clean up, and with no
way to undo.
[*] Extreme example of the mix is having HTML/JS/CSS/CSSS/PHP/Perl blocks
in one file.
>
> 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());
>
> The use of the Standard Library member "empty" is highly confusing at first
> sight because it does not follow the Qt naming guidelines. It's even more
> confusing because the next line has "isEmpty". When I read this code, I
> had to
> wonder if that "empty" was a verb in the imperative, meaning the author was
> trying to remove all elements from the container.
>
> I had to look up the definition of readHeaders in the review and note that
> it
> was a std::deque, not a Qt container.
>
> What do we do?
>
> Option 1:
> Not use Standard Library containers, just use the Qt containers as they
> exist.
>
> Option 2:
> Create new Qt containers to have the same complexity as Standard Library
> containers, but following the Qt naming conventions. Possibly with implicit
> sharing.
>
> Option 3:
> Create Qt API wrappers for those containers like std::deque, adding only a
> few
> inline functions to match the Qt-style API where the Standard Library API
> deviates. Examples are:
> empty -> isEmpty
> push_back -> append
> front -> first
> pop_front -> takeFirst
> cbegin -> constBegin
> cfind -> constFind
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
