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:
On 13 Aug 2018, at 18:12, Giuseppe D'Angelo via Development
<development@qt-project.org> wrote:
>> This is actually against the old "non-enum class" coding standards:
>> one must repeat the enumeration name in the enumerators.
... and yet we have violations of that in public APIs.
e.g. QValidator::State, with values { Invalid, Intermediate, Acceptable }
Tor Arne Vestbø (13 August 2018 18:19)
> 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.
and the rationale for the rule doesn't really need it applied except to
global enums (and, rarely, within a class if there's a clash).
>>> 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.
including the ones set in stone that violate the policy we've not been
rigorous abut following. Meanwhile, when it comes to adding *new*
enums, do we really want to continue following this rule ?
> 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.
+1
>> 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.
... and avoid pointless duplication.
Yes please,
Eddy.
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
