[Development] Views

Tor Arne Vestbø Tor.arne.Vestbo at qt.io
Thu Jun 6 12:19:00 CEST 2019


On 6 Jun 2019, at 10:42, Mutz, Marc via Development <development at qt-project.org> wrote:
> 
> *But* it's not "hard to read" in the sense that you stare at it and can't figure out what the hell the code is doing.

You can insult my intelligence and CS credentials all you want, I’m still going to claim that the STL-code in [1] is harder to read, and obscures what the function is doing by putting the algorithm in your face first.

> Do you guys _actually_ think that readability of Qt code trumps _everything_?

Obviously not, and you know that’s not the case. It’s a balance, just like everything else.

> IMO, that hits the nail on the head: we have an obligation to our users to use the most efficient data structure (and, by extension, looping construct) we possibly can, and can't just pop in the first data structure that comes to mind.
> 
> IMNSHO, you can optimize for readability in your own app and see whether you sustain in the market. In a library, used on millions of machines every day, spending 8KiB (or 4KiB, or just 1KiB) just to use a slightly less noisy code version is - sorry - selfish. If you contribute to Qt, you should be putting yourself in the service of it's users.

The service to our users is to make Qt the best toolkit it can be across a wide set of facets and for a wide set of users and use-cases.

One of those facets is the ability to quickly fix bugs and improve on the code easily, so that Qt can move forward. Readable and well abstracted code helps in that.

In some cases performance matters, and in some cases binary size matters. Obviously we should avoid using the wrong algorithm or data structure in performance critical code, and avoid bloating the binaries for low end targets where we can, but doing so needs to be balanced with the other considerations, so that we know the tradeoff is worth it. 

> I have the feeling that some participants of these discussions thought they joined an adulation club for Qt API lovers instead.

Please consider whether statements like this, and ones you’ve made in follow-up emails, are in line with the project’s code of conduct. If that doesn’t concern you, I’m also pretty sure that leaving out this kind of language will increase the support for your case 😊

Tor Arne 

[1] https://codereview.qt-project.org/c/qt/qtwayland/+/264069


More information about the Development mailing list