Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

What should we learn from the code of examples that shipped with QT



  • I'm always wondering about how efficient or elegant the examples that are shipped with Qt. As C++ advanced-intermediate programmer, should I spare some time to study the code of the examples from programming perspective rather than showing the functionalities of classes? What are the considerations of authors when they code these examples? I'm asking this because I don't do coding for living and it is extremely hard to go deeper in real-world problems. As a person who work in Academia (i.e. electrical engineering), I have to read books to force myself to be in touch with the programming languages. Do you think reading examples of Qt library will ameliorate my coding style?


  • Qt Champions 2019

    @CroCo said in What should we learn from the code of examples that shipped with QT:

    reading examples of Qt library will ameliorate my coding style?

    Not necessarily I would say. Qt examples are there to show how to use Qt framework, not to teach readers best coding style. But is just my opinion...


  • Moderators

    @CroCo From personal experience I would say:

    Read them if you want to use them and want a basic understanding of the class.
    That said, a lot of examples are out of date and not necessarily maintained well. So I doubt you will learn best coding practices.

    The Wiki has nice pages about Qt related conventions:

    https://wiki.qt.io/Qt_Coding_Style
    https://wiki.qt.io/Coding_Conventions

    If you're looking for a nice and simple book for good c++ practices I would suggest:
    https://leanpub.com/cppbestpractices

    Even though I do not agree with his AAA approach, it's in general a nice and good book



  • @J-Hilk said in What should we learn from the code of examples that shipped with QT:

    c++ practices

    Absolutely nice Qt Wiki pages.



  • First, let me echo and wholeheartedly agree with @jsulm and @J-Hilk .

    Qt examples show a "best" way to use the Qt framework, but such usage patterns may or may not correspond to some general idea of best way to write C++ code. Also, the age of the examples (the year they were written in) matters. C++ best practices have changed significantly as we have graduated from C++98 to C++03, C++11, C++17, etc.

    Having said that...

    If (for whatever reason!) you happen to have the Qt examples readily available to you, they certainly are not the worst place to start with C++. You could definitely do worse. So if you are comfortable with reading the Qt examples, I would encourage you to keep doing so. Most of us would be hard-pressed to name one real-world C++ codebase of moderate size and history that is a sterling example to follow without reservations.

    Something to keep in mind: "C++ is a federation of languages"

    People use C++ in many different environments and under different constraints. So depending on which environment you work in, you will get VERY DIFFERENT answers about what the best C++ usage patterns are in that setting.

    Qt code is a good (good enough) example of how to do end-user GUI application code in C++.

    I'm sure if you were using C++ for FinTech (Bjarne Stroustrup works at Morgan Stanley), those folks would use C++ very very differently :)



  • I was looking over the page on coding style mentioned by J.Hilk, and have a couple of questions:

    1. why is it better to put opening braces on the same line as the start of a statement? To me, it's considerably harder to read, particularly with nested statements.
    2. is it really better not to use braces for single-line conditionals? I realize that they're unnecessary, but they do add some visual structure to the code.

  • Lifetime Qt Champion

    1. I am personally used to it as it makes clear that what follows belong to the condition/for loop, etc. In C++ you can create local scopes anywhere by putting your code between braces.

    2. This one I personally avoid it in any code base that does not require it. Apple made a strong point against it when they broke their security validation because of the indentation of two lines of code that made them look as part of the same block but it was only a look...



  • @SGaist I don't agree with #1, but I'm clearly in the minority on this one, so I'll try to train myself into the accepted form.

    Regarding #2, what can I say except "LOL Apple people." (And I say that as a former Apple employee.)

    I guess I should participate in the original point of the thread: in my opinion, the Qt example code is written as tersely as possible, to minimize the possibility of extra code diluting or confusing the intended lesson. It also seems to be written to "extract" as easily as possible for those who need a down-and-dirty fix to something.

    The authors of Qt, and Qt documentation, aren't here to teach us good C++ coding practices; if we're here, we should know that already.

    (This discussion reminds me of a grumpy old programmer I knew ages ago, who once observed that good coding habits are overrated; if the stuff is hard to write, it should be hard to read.)


  • Moderators

    @mzimmers said in What should we learn from the code of examples that shipped with QT:

    I was looking over the page on coding style mentioned by J.Hilk, and have a couple of questions:

    1. why is it better to put opening braces on the same line as the start of a statement? To me, it's considerably harder to read, particularly with nested statements.
    2. is it really better not to use braces for single-line conditionals? I realize that they're unnecessary, but they do add some visual structure to the code.

    "Better" is hard to define and people can argue over it till the cows come home. The main purpose of specifying a coding style is to achieve consistency within a project (or a group of projects).

    When I'm writing code for my own projects, I use my own coding style where I put opening braces on a new line but I omit braces for single-line conditionals (so it sounds like I'm the complete opposite of @SGaist). When I submit patches to Qt, I use the Qt coding style.


  • Lifetime Qt Champion

    @mzimmers you do not need to change your style for the projects you are responsible for.

    I 100% agree with @JKSH: consistency is the key word here.

    As you can see, @JKSH and I are using "reverse" techniques that do not match with Qt's style, but that does not stop us from contributing to projects that are using other set of guidelines. You might also want to take a look at the Linux kernel guidelines which provides other constraints including line size and white space handling.

    The main thing is: define and use the guidelines you like for your own projects and adapt to the one of the projects your work on/contribute to.

    That grumpy old programmer you mentioned just did a good job of ruining project maintainability with that philosophy...

    As for Qt examples, they usually follow Qt's guidelines in terms of code styling however, like other already mentioned some are old and uses technique from the time they were written which does not necessarily make them "modern" however their point is usually to show how to use some classes or offer a base to extend on.



  • @JKSH said in What should we learn from the code of examples that shipped with QT:

    I put opening braces on a new line but I omit braces for single-line conditionals

    This is correct.
    Anything else is heresy. We used to burn people at the stake for less than this.

    My company's very first product was a language-independent syntax directed editor. Pascal, Modula 2, COBOL, C, other proprietary languages --- anything with a LALR(1) grammar, IIRC. Which meant, you couldn't affect the formatting, one way or another. And I could read in a saved source file and have it layout with braces, indentations, comments as I wanted them, while you could read the same file and have it all layout on one line for all I cared. Happy days :) [Except that it didn't take over the world....]


  • Lifetime Qt Champion

    Hi

    1. Don't matter just select a style and stick to it.
    2. we use brackets for single lines too as
      we have had cases where bugs sneak in due to
    if ( X ) 
      DoX();
      DoY(); 
    
    

  • Qt Champions 2017

    @mzimmers said in What should we learn from the code of examples that shipped with QT:

    (This discussion reminds me of a grumpy old programmer I knew ages ago, who once observed that good coding habits are overrated; if the stuff is hard to write, it should be hard to read.)

    @SGaist said in What should we learn from the code of examples that shipped with QT:

    That grumpy old programmer you mentioned just did a good job of ruining project maintainability with that philosophy...

    Not necessarily. One could extend the argument that if something's hard to read, it shouldn't be there to begin with. Meaning that if something reads as forced, overengineered, artifical etc. it should be rewritten in an "easier" way (thus easier to be read). Which would simply lead to you reinventing most of the "good coding habits". ;)


  • Lifetime Qt Champion

    @kshegunov said in What should we learn from the code of examples that shipped with QT:

    SGaist said in What should we learn from the code of examples that shipped with QT:

    That grumpy old programmer you mentioned just did a good job of ruining project maintainability with that philosophy...

    Not necessarily. One could extend the argument that if something's hard to read, it shouldn't be there to begin with. Meaning that if something reads as forced, overengineered, artifical etc. it should be rewritten in an "easier" way (thus easier to be read). Which would simply lead to you reinventing most of the "good coding habits". ;)

    Fair point I agree with but there's too many should for it to happen easily ;-)


Log in to reply