[Development] Naming convention for (scoped) enums
Tor Arne Vestbø
Tor.arne.Vestbo at qt.io
Mon Aug 13 18:19:30 CEST 2018
On 13 Aug 2018, at 18:12, Giuseppe D'Angelo via Development <development at qt-project.org> wrote:
>
> Il 13/08/2018 16:40, Tor Arne Vestbø ha scritto:
>> 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:
>
> This is actually against the old "non-enum class" coding standards: one must repeat the enumeration name in the enumerators.
Just because the old standard was also promoting less readable/writable code doesn’t make it a good thing that we should keep 😊
The coding standard was likely based on global enums, and somehow we didn’t account for enums inside classes. Even today https://wiki.qt.io/API_Design_Principles#Naming_Enum_Types_and_Values doesn’t mention enums inside classes, and the example only shows global enums.
>> if (event->device()->pointerType() != QQuickPointerDevice::PointerType::Finger &&
>> I think we should revisit this policy, and only use it when there’s actually a clash.
>
> Which is always "too late" if we're talking about public APIs, as they're set in stone.
Of course. I’m just arguing that we shouldn’t continue down this road now that we’ve learned that the coding standard produces worse results for the specific case of enums inside classes.
> In the meanwhile, I would not work around it -- we need *some* enum scoping anyhow, and enum classes are the simplest way possible to not forget about it.
Enum scoping is already achieved by the enum living inside a class. You already have your goal met 😊 If it’s a global enum, sure, make it a class enum instead of QQuickPointerDevice::FingerPointerType. And if it’s inside a class, and clashes, sure, make it a class enum. But for the common case, let’s prioritise readability/writability.
Tor Arne
More information about the Development
mailing list