[Development] Naming convention for (scoped) enums
Alex Blasche
alexander.blasche at qt.io
Tue Aug 14 12:13:14 CEST 2018
> -----Original Message-----
> From: Tor Arne Vestbø
> That circular logic 😊 Or at least arguing that we should maintain the policy not
> because it makes sense, but just because we’ve done so in the past.
>
> You are not questioning _why_ we have done so in the past (for decades as you
> say), which should be the input to whether or not we want to maintain the policy
> as is, or update it to match the current landscape of Qt and C++.
>
> The mere fact that we’ve had a policy does not have any value.
Well, so far you only questioned the scoped enum case and making an argument for the scoped enum case based on so far accepted rules for unscoped ones is valid.
> > Therefore QQuickEventPoint::State::Pressed is no more verbose than
> QQuickEventPoint::PressedState.
>
> Again, the policy does not mandate that in it’s current form in my reading of it,
> and even if it did, that would be a bad policy and we should fix it, not just blindly
> accept it as set in stone, because we’ve followed it "for decades".
To quote the policy:
"By comparison the following example illustrates the dangers of missing type safety and giving general names to conventional enum values:"
...
" One guideline for naming enum types is to repeat at least one element of the enum type name in each of the enum values"
I think the policy is explicit. Whether you think it is bad is a different kind of thing. Please don't mix that. Personally, I think this naming rule has served us well and although it is not consistently applied the majority of enums does follow them.
> > In summary, there is very little verbosity added even by existing rules. Mind
> you, Qt has always favoured readability and accepted verbosity as a
> consequence in times of code completion.
>
> Code completion (for those that use it), only helps with writing code, and as we
> all know, most time is spent reading code 😊
>
> > There is one more very important aspect. Scoped enums can have dedicated
> types and are type safe. This could have easily caught issues like (which
> coincidently was pointed out to me this morning):
> >
> > https://codereview.qt-project.org/#/c/236736/
> >
> > And I believe that is a very good reason to still prefer scoped enums.
>
> How frequent is this class of bugs?
Frequent enough for it being the primary driver behind the introduction of scoped enums?!? Mind you even our own policies state this limitation of unscoped enums.
--
Alex
More information about the Development
mailing list