[Development] New Qt example development guideline and revamping examples

Eike Ziller Eike.Ziller at qt.io
Fri Jan 20 09:49:10 CET 2023

> Am 19/01/2023 um 13:33 schrieb Giuseppe D'Angelo via Development <development at qt-project.org>:
> Il 19/01/23 10:27, Tor Arne Vestbø ha scritto:
>>> All the contrary, do NOT do that, as it results in 200+ lines unnamed lambdas. Strongly prefer named slots. Keep the lambdas short and to the point. Do not use unnamed lambdas.
>> No, strongly prefer lambdas if they are within a reasonable size. No-one is arguing for 200+ line lambdas.
> The reason for such a harsh rule is that "reasonable size" tends to go out of control very quickly. Is 10 lines too much? Maybe 15? Giving it a fixed size opens up the door to a sorites paradox. The point is that when you write the lambda the first time, it'll be completely obvious what it does to you, even if it's long. You'll even avoid giving it a name and connect straight to it, as it makes "perfect sense", in the context of the code surrounding the lambda.
> But on the long run, this makes the code worse to read and understand. No one will understand what the lambda is _meant_ to do without analyzing the body of the lambda, line by line (cf.: a named lambda/slot, where a proper name tells you everything). And reasoning on the code surrounding the lambda is also much harder as it's intermingled with the lambda itself.
> If anything: the fact that this is seen as _questionable_ and people disagree on it should be a good indication that examples shouldn't do it, as examples shouldn't feature _questionable_ code styles.

I think with that argument any code style fall apart. People find using "auto" questionable, and other people find _not_ using "auto" questionable. Some people find that not using braces for bodies of conditional statements, even if they are just one line, is questionable, other people find that using braces for one-line bodies would bloat the code.

I find not using unnamed lambdas at all questionable. IMO named lambdas are worse, since they are also inline inbetween other code in the function, so they need to be small too (with the same question of what "small" means), but a reader trying to figure out what happens at the place where it is used need to redirect to whereever it is defined. Names are often not good enough to convey enough meaning, often the actual details matter, and glancing on the handful of lines of code directly inline is often faster to read. And not using lambdas at all means creating lots of member functions that are only used once, bloat the class API, with the same issue of requiring redirection when read, and possibly creating class member variables just for use of single methods which could be easily solved by capturing in a lambda.

Br, Eike

More information about the Development mailing list