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

mzimmers

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

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.
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.

SGaist

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.
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...

mzimmers

@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.)

JKSH

@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:

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.

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.

SGaist

@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.

JonB

@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....]

mrjj

Hi

Don't matter just select a style and stick to it.
we use brackets for single lines too as
we have had cases where bugs sneak in due to

if ( X ) 
  DoX();
  DoY();

kshegunov

@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". ;)

SGaist

@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 ;-)

Molino147

This post is deleted!