On Jul 16, 2026, at 11:14, Marc Mutz via Development
<[email protected]> wrote:
Hi,
The current style guide¹ asks for attached braces on if statements, incl. when
the if condition spans multiple lines (#6):
// Correct
if (address.isEmpty() || !isValid()
|| !codec) {
return false;
}
I've been bothered by this for years, since I think this is totally unreadable.
In particular, if the last line of the if is on the longer side, the body of
the then branch is almost impossible to distinguish from a continuation of the
condition.
Braces at the right are already harder to find. Before I joined Qt, I used to
always put braces on the left, in all languages. It used to be normal at all
the places where I worked. Then I tried writing Scheme that way and got
lambasted: you just have to get used to great piles of parentheses (although
some people use square brackets to disambiguate some cases: they are
interchangeable). Then I joined Qt and had to switch style anyway, because the
company likes the opening braces on the right for some reason. I suppose the
advantage is less vertical space is wasted this way (same reason as for Lisp
dialects: all those indented blocks and wasting a whole line for one
parenthesis were unreasonable after all. I got used to brace-matching; but I
still like using real tabs whenever I can get away with it, and that’s also
unpopular in most circles for some reason.)
You probably have a brace-matcher in your editor. Hopefully it makes them
stand out enough to find the other end when you need to. For some languages
it’s more mandatory than others. C++ lambdas and QML nested-ternaries are
getting there too.
Another workaround you could use here is to indent the second line of the if.
I don’t like having it lined up with the body in such a case, and you can
indent it more without violating the coding style rules.
if (address.isEmpty() || !isValid() ||
!codec) {
return false;
}
Or
if ( address.isEmpty() || !isValid() ||
!codec ) {
return false;
}
Let’s not split the cases for brace alignment. It will tend to result in even
more review nitpicking, and make it harder to write reformatting rules for
clang-format and such.
--
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
