> 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.solo...@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-boun...@qt-project.org> on behalf of Ulf Hermann via Development <development@qt-project.org> Sent: Wednesday, September 13, 2023 8:54 AM To: development@qt-project.org <development@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@qt-project.org https://lists.qt-project.org/listinfo/development
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
