[Development] Naming convention for (scoped) enums

[Alex Blasche]

> -----Original Message-----
> From: Tor Arne Vestbø
> Sent: Monday, 13 August 2018 16:40
> To: Alex Blasche <alexander.blasche at qt.io>
> Cc: development at qt-project.org; Simon Hausmann <Simon.Hausmann at qt.io>
> Subject: Re: [Development] Naming convention for (scoped) enums
> 
> 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 was certainly not limiting myself to those only. That's just a coincidence that I chose a global enum for the policy.


> 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.

Similar to Guiseppe, I would argue that the above enum does not comply with the convention for unscoped enums either. The enum value would have to repeat at least some part of the enum type. That's a rule that has existed for decades now. Therefore QQuickEventPoint::State::Pressed is no more verbose than QQuickEventPoint::PressedState. 

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. 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.

--
Alex