[Development] Proposal: (re)move qt5.git/_clang-format

[Ivan Solovev]

> I would therefore propose to remove the file from qt5.git:

+1 from my side.
I believe I simply do not have the clang-format tool installed on my system,
because it usually breaks the formatting of the patches, not improves them.

> One way to address these problems, especially for new devs or drive-by
> contributions, is stating clearly in the wiki page:
> "use clang-format, it should get you at least half way there, but you still
> should/must also override it to match the style of surrounding code, as much as
> possible, in the file(s) you're editing, that's kinder to reviewers".

The problem is that we have a pre-commit (I believe) git-hook, which checks the
formatting and nags if it does not match to what we have in the _clang-format file.
This basically forces​ the new or drive-by contributors to submit the patch with an
incorrect formatting, which then leads to a bunch of review comments about code-style.

I think that it's better to give no hints, rather than misleading hints.

Best regards,
Ivan

------------------------------

Ivan Solovev
Senior Software Engineer

The Qt Company GmbH
Erich-Thilo-Str. 10
12489 Berlin, Germany
ivan.solovev at qt.io
www.qt.io

Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
________________________________
From: Development <development-bounces at qt-project.org> on behalf of Ulf Hermann via Development <development at qt-project.org>
Sent: Wednesday, September 13, 2023 8:54 AM
To: development at qt-project.org <development at qt-project.org>
Subject: Re: [Development] Proposal: (re)move qt5.git/_clang-format

> There _is_ consensus. It's in the wiki. And in older modules not
> infected by the _clang-format file. Discussions arise because
> of .clang-format, not despite it. Afaict, there never was a discussion
> about how faithful the _clang-format represents the Qt style before it
> was added. If there was _any_ attempt at the above-mentioned litmus
> test, the template<> issue and others would have been detected immediately.

Unfortunately the consensus is weak on the most jarring problem, and
that happens to be one that the automatic formatters I know are utter
rubbish at:

Where do you break the line and how much white space do you indent in
various situations? For example:

* long lists of arguments list to a function (call or declaration)
* nested template parameters, possibly with defaults
* template arguments
* lists of partially specialized template parameters
* initializer lists (possibly nested)
* ternary operators with outsized "hands"
* constructor-initializers
* lambdas, potentially nested
* nested boolean or arithmetic expressions with or without parentheses
* and then combine all of those

I find myself constantly re-indenting things based on some unwritten
rules I make up myself. I would be fine with an automatic indentation
that produces somewhat readable code, but what I get is frequently an
indentation to column 205 or similar for no obvious reason.

Yes, it often helps to use additional temporaries so that your lines are
not as large to begin with. However, that also increases the cognitive
load when reading it as you then have to carefully determine if the
introduction of the temporary changes semantics. For example, is the
temporary moved or copied? Does the extracted template construction
allow things the inline one was not meant to allow? etc.

All the other stuff you may format for is trivial in comparison because
it only involves adding or removing few characters here or there. With
some practice it takes up rather little time, even when done manually.
The indentation, however, requires shifting around large bodies of white
space, which is quite annoying in the editors I know.

best regards,
Ulf
--
Development mailing list
Development at qt-project.org
https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20230913/bc66e54d/attachment-0001.htm>