[Development] Naming convention for (scoped) enums

[Allan Sandfeld Jensen]

On Dienstag, 14. August 2018 14:27:27 CEST Alex Blasche wrote:
> > -----Original Message-----
> > From: Tor Arne Vestbø
> 
> 
> 
> > > 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.
> > 
> > 
> > The policy uses a global enum as an example. Obviously we need some sort
> > of
 scoping there, either in the enum value names, or by using scoped
> > enums. We agree there, and can leave that part of the discussion as
> > solved. 
> > The discussion here is about what to do when the enum lives inside a
> > class,
 which would already solve the naming clash issue in most cases.
> 
> 
> This is not about namespace clashes or inside or outside classes. It is
> about readability. Unscoped enums don’t require the enum type to be
> mentioned although the type name tremendously helps as context info for
> enum values. Without this context the enum is harder to understand. Hence a
> more verbose name (repeating essential part of the type) is chosen.
 
> And we have not even talked about strong typing of scoped versions (see
> Eike's comment)
 
> Scoped enums have a few advantages which are sufficient for me to accept its
> use. Combine that with a naming policy that is close to what we had for
> unscoped enums and you got a winner for me 😉

I agree, at least in most cases. There are still cases where I would prefer 
unscoped enums. For instance in my recent QColorSpace patch, I ended up using 
both types of enums under QColorSpace. The enum that represented specific 
colorspaces that looked best without an extra scope I left unscoped (e.g. 
QColorSpace::SRgb as opposed to QColorSpace::PredefinedColorSpace::SRgb), 
enums that represented specific property types that couldn't be used alone to 
construct a QColorSpace, I scoped (E.g. QColorSpace::Gamut::AdobeRgb).

If we applied a policy like that to all of Qt, most enums would be scoped, but 
a few such as the special types of QJsonValue would not be.

Best regards
'Allan