Bringing this up again in light of e.g.
https://codereview.qt-project.org/#/c/235167/
When I gave my support to this I thought we were talking about global enums. I
do not think that using class enums inside existing classes is a win for code
readability/writability:
When you have
switch (point->state()) {
It's pretty obvious what case QQuickEventPoint::Pressed: refers to. being
overly explicit with case QQuickEventPoint::State::Pressed: just adds more to
type for no reason.
Or:
if (event->device()->pointerType() != QQuickPointerDevice::Finger
Gives me all the info I need, and having to type or read this instead is worse
in my opinion:
if (event->device()->pointerType() !=
QQuickPointerDevice::PointerType::Finger &&
I think we should revisit this policy, and only use it when there’s actually a
clash.
Tor Arne
> On 22 May 2018, at 10:04, Alex Blasche <[email protected]> wrote:
>
> I updated the enum section:
>
> https://wiki.qt.io/API_Design_Principles#Naming_Enum_Types_and_Values
>
> --
> Alex
>
> ________________________________________
> From: Development
> <[email protected]> on behalf of
> Lars Knoll <[email protected]>
> Sent: Tuesday, 22 May 2018 9:30:18 AM
> To: Christian Kandeler
> Cc: Qt development mailing list
> Subject: Re: [Development] Naming convention for (scoped) enums
>
>
>
>> On 17 May 2018, at 11:35, Christian Kandeler <[email protected]>
>> wrote:
>>
>> On Thu, 17 May 2018 08:14:15 +0000
>> Alex Blasche <[email protected]> wrote:
>>
>>> The naming conventions for enums state that each enum value name must
>>> repeat a part of the enum Type name (for details see
>>> https://wiki.qt.io/API_Design_Principles#Naming_Enum_Types_and_Values)
>>>
>>> In case of scoped enums this becomes a superfluous rule as the type has to
>>> be mentioned anyway. Does anybody object to modifying the above definition
>>> by adding an exception for scoped enums where you do not have to repeat a
>>> part of the enum type name?
>>
>> I would not have even assumed that the rule applies to scoped enums, but it
>> can't hurt to write it down explicitly. Perhaps the section should be
>> rewritten so that the unscoped enums are the special case rather than the
>> other way around.
>
> Agree. The default for new enums should be scoped enums.
>
> Cheers,
> Lars
>
> _______________________________________________
> Development mailing list
> [email protected]
> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> [email protected]
> http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development