[Development] Naming convention for (scoped) enums

[Alex Blasche]

> -----Original Message-----
> From: Tor Arne Vestbø
> 1. Scoped enums (enum class) for the sake of avoiding name clashes is useful for
> global enums, but when the enum lives inside a class, the chance that we’ll see a
> naming clash is minor, and using scoped enums in that case arguably has
> negative effects on code writability/readability. As a result, we should update
> the policy to not mandate scoped enums when the enum lives inside a class.

I don't think we have ever not permitted exceptions to official policy. Therefore, take it for granted that the policy can be ignored such as in the case presented by Allan. Having said that the default should be the use of scoped enums even inside of classes. 

I don't consider the longer names detrimental for writability and usability. Writability is easily solved with code completion and readability is actually better because the type adds additional context info. To cite an example from Shawn's patch:

QQuickPointerDevice::Finger
QQuickPointerDevice::Mouse

is far less descriptive than (and not compliant to current naming convention)

QQuickPointerDevice::PointerType::Finger
QQuickPointerDevice::DeviceType::Mouse. 

The uninitiated reader of the code cannot see the additional type context when reading code and therefore someone might interpret Finger as a device type too. That's exactly what the existing unscoped enum policy tries to fix. Scoped enums provide this feature out of the box. Another example of a good naming policy (IMO) is QAbstractSocket (never mind the technical limitations). Here we could shorten the enum names using scoped enums:

QAbstractSocket::SocketError::ConnectionRefusedError -> QAbstractSocket::SocketError::ConnectionRefused (or even QAbstractSocket::Error::ConnectionRefused)

Name clash prevention was only ever secondary to readability.


> 2. Scoped enums for the sake of type safety is a valid use case, but can be solved
> by promoting a warning to an error, and as such shouldn’t block us moving
> forward with #1.

I don't see how a policy of elevating warnings to errors is better that using a language inbuilt error due to strong type safety.
--
Alex