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 <alexander.blas...@qt.io> wrote: > > I updated the enum section: > > https://wiki.qt.io/API_Design_Principles#Naming_Enum_Types_and_Values > > -- > Alex > > ________________________________________ > From: Development > <development-bounces+alexander.blasche=qt...@qt-project.org> on behalf of > Lars Knoll <lars.kn...@qt.io> > 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 <christian.kande...@qt.io> >> wrote: >> >> On Thu, 17 May 2018 08:14:15 +0000 >> Alex Blasche <alexander.blas...@qt.io> 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 > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development