Re: [Development] Proposing changes to https://wiki.qt.io/Qt_Coding_Style
> On 10 May 2023, at 07:39, Marc Mutz via Development > wrote: >> >> >> That said. I find discussing style-guides in general a waste of time, and >> will >> agree to anything that make us stop wasting time on this. > > I tend to agree, but the choice is either to define it centrally, or you > repeat these discussions on Gerrit over and over again. Thanks for the proposals Marc, the list looks good to me. As for >>> - space after template and before <: >>> >>>// WRONG >>>template >>>// CORRECT: >>>template I was wondering what cppreference suggests, and was delighted to find that the first few lines of https://en.cppreference.com/w/cpp/memory/unique_ptr manage to have both :) So accepting either, and in particular the no-space form that comes out of _clang-format, is fine. Encoding this in the sanity bot and/or in _clang-format avoids that we waste time on this during code review. Volker -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposing changes to https://wiki.qt.io/Qt_Coding_Style
On 09.05.23 22:15, Allan Sandfeld Jensen wrote: > On Dienstag, 9. Mai 2023 08:51:37 CEST Marc Mutz via Development wrote: [...] >> - space after template and before <: >> >> // WRONG >> template >> // CORRECT: >> template >> > >> Rationale: We always used the latter in Qt. > > We have always used both. I prefer the first one, which also happens to be the > default by old Qt styles, but the second one is now more common in QtCore. Some historical data, mined using $ git grep --recurse-submodules -e 'template <' $version -- | \ grep -v /3rdparty/ | wc -l $ git grep --recurse-submodules -e 'template<' $version -- | \ grep -v /3rdparty/ | wc -l Qt | template < | template< | remarks | -++---+---+ 4.5 | 2037 | 606 | qt.git| 4.8 | 2440 | 796 | | -++---+---+ 5.0 | 2479 | 1429 | qt5.git (beta-1) | 5.6 | 3103 | 2040 | | 5.9 | 3315 | 2103 | | -++---+---+ (_clang-format demanding template< added here) | (existed before in qtrepotools, it seems) | -++---+---+ 5.12 | 5051 | 2637 | | 5.15 | 4989 | 2838 | | 6.0 | 5353 | 4027 | | 6.2 | 5580 | 4407 | | 6.5 | 6202 | 5395 | | -++---+---+ I think it's hopeless to convert to either over night, but it also seems clear that with-space was the preferred form until the use of the no-space form picked up dramatically following the addition, and then uptick in use, of _clang-format to qt5.git. Absent a consensus on this, I'd suggest to use whatever you find to be predominant in the file/module you're editing. > That said. I find discussing style-guides in general a waste of time, and will > agree to anything that make us stop wasting time on this. I tend to agree, but the choice is either to define it centrally, or you repeat these discussions on Gerrit over and over again. Thanks, Marc -- Marc Mutz Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposing changes to https://wiki.qt.io/Qt_Coding_Style
On Dienstag, 9. Mai 2023 08:51:37 CEST Marc Mutz via Development wrote:
> Hi,
>
> I'd like to propose the following clarifications:
>
> - no space between "operator" and it's symbol:
>
> // WRONG
> bool operator ==()
> // CORRECT
> bool operator==()
>
> Rationale: that's the style we find in all of Qt, but QtC's
> auto-completion (by default?) adds the space, so we should clarify what
> we want (and fix QtC).
>
> - exactly one space each between if and constexpr/constinit and
> following [({]:
>
> // WRONG
> if constinit(
> if constexpr(~~~) {
> // CORRECT
> if constinit {
> if constexpr (~~~) {
>
I prefer the first ones. Though it appears the second is used 75% of the time
in Qt code.
> - space after template and before <:
>
>// WRONG
>template
>// CORRECT:
>template
>
> Rationale: We always used the latter in Qt.
We have always used both. I prefer the first one, which also happens to be the
default by old Qt styles, but the second one is now more common in QtCore.
That said. I find discussing style-guides in general a waste of time, and will
agree to anything that make us stop wasting time on this.
Best regards
Allan
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Proposing changes to https://wiki.qt.io/Qt_Coding_Style
On Tue, May 09, 2023 at 06:51:37AM +, Marc Mutz via Development wrote: > Hi, > > I'd like to propose the following clarifications: > > - no space between "operator" and it's symbol: > [...] > - exactly one space each between if and constexpr/constinit and > [...] > - space after template and before <: > [...] > - drop the requirement for () in lambdas All fine from my perspective. Andre' -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposing changes to https://wiki.qt.io/Qt_Coding_Style
Hi!
+1 to all suggestions
Best regards,
Ivan
From: Development on behalf of Marc Mutz
via Development
Sent: Tuesday, May 9, 2023 8:51 AM
To: qt-dev
Subject: [Development] Proposing changes to https://wiki.qt.io/Qt_Coding_Style
Hi,
I'd like to propose the following clarifications:
- no space between "operator" and it's symbol:
// WRONG
bool operator ==()
// CORRECT
bool operator==()
Rationale: that's the style we find in all of Qt, but QtC's
auto-completion (by default?) adds the space, so we should clarify what
we want (and fix QtC).
- exactly one space each between if and constexpr/constinit and
following [({]:
// WRONG
if constinit(
if constexpr(~~~) {
// CORRECT
if constinit {
if constexpr (~~~) {
- space after template and before <:
// WRONG
template
// CORRECT:
template
Rationale: We always used the latter in Qt. Then a faulty _clang-format
that dropped the space for unknown reasons was added to qt5.git and
since then, we have a wild mix. We should fix the faulty _clang-format
file and codify just one variant in the normative document,
https://wiki.qt.io/Qt_Coding_Style.
- drop the requirement for () in lambdas
Rationale: this was a word-around for older MSVCs. The standard doesn't
require the empty parameter list (except when adorning the lambda with
noexcept etc, and then the compiler complains) and people have voted
with their feet: we now have many uses of [] {} in Qt already.
Thanks,
Marc
--
Marc Mutz
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B
--
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
Re: [Development] Proposing changes to https://wiki.qt.io/Qt_Coding_Style
On Monday, 8 May 2023 23:51:37 PDT Marc Mutz via Development wrote: >// WRONG >template >// CORRECT: >template > > Rationale: We always used the latter in Qt. Then a faulty _clang-format > that dropped the space for unknown reasons was added to qt5.git and > since then, we have a wild mix. We should fix the faulty _clang-format > file and codify just one variant in the normative document, > https://wiki.qt.io/Qt_Coding_Style. Strictly speaking, we've used both for a very long while. But I prefer with the space. I agree with the other suggestions. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposing changes to https://wiki.qt.io/Qt_Coding_Style
Hello!
> -Original Message-
> From: Development On Behalf Of
> Marc Mutz via Development
> Sent: tirsdag 9. mai 2023 08:52
> To: qt-dev
> Subject: [Development] Proposing changes to
> https://wiki.qt.io/Qt_Coding_Style
>
> Hi,
>
> I'd like to propose the following clarifications:
>
> - no space between "operator" and it's symbol:
>
> [...]
>
> - exactly one space each between if and constexpr/constinit and
> following [({]:
> [...]
Yeah, I'd +1 these.
> - space after template and before <:
>
>// WRONG
>template
>// CORRECT:
>template
>
> Rationale: We always used the latter in Qt. Then a faulty _clang-format
> that dropped the space for unknown reasons was added to qt5.git and
> since then, we have a wild mix. We should fix the faulty _clang-format
> file and codify just one variant in the normative document,
> https://wiki.qt.io/Qt_Coding_Style.
I think it was already mixed usage back then, but it's also something
I've been bothered by. I pushed this patch a while ago but never
got around to pinging anyone about it:
https://codereview.qt-project.org/c/qt/qt5/+/433720
> - drop the requirement for () in lambdas
>
> Rationale: this was a word-around for older MSVCs. The standard doesn't
> require the empty parameter list (except when adorning the lambda with
> noexcept etc, and then the compiler complains) and people have voted
> with their feet: we now have many uses of [] {} in Qt already.
I don't really see the problem with having empty parenthesis, even if
they're optional. But as long as we're not enforcing it it doesn't make
sense as a rule either.
Mårten
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Proposing changes to https://wiki.qt.io/Qt_Coding_Style
> - drop the requirement for () in lambdas
>
> Rationale: this was a word-around for older MSVCs. The standard doesn't
> require the empty parameter list (except when adorning the lambda with
> noexcept etc, and then the compiler complains) and people have voted
> with their feet: we now have many uses of [] {} in Qt already.
I support it and we have such a rule in QtC already. However, please note that
when you specify the return type of
the lambda or define it mutable, the compiler issues the following warnings
currently:
int bla = 0;
const auto foo = [] -> int { return 0; };
const auto bar = [bla] mutable { bla = 4; return 0; };
warning: parameter declaration before lambda trailing return type only optional
with ‘-std=c++2b’ or ‘-std=gnu++2b’
72 | const auto foo = [] -> int { return 0; };
| ^~
warning: parameter declaration before lambda declaration specifiers only
optional with ‘-std=c++2b’ or ‘-std=gnu++2b’
73 | const auto bar = [bla] mutable { bla = 4; return 0; };
|^~~
When you add empty (), the compiler is silent.
Jarek
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
