Proposal: adopt <Compose conventions for enums, si...

# language-proposals

[edrd]

Proposal: adopt Compose conventions for enums, singletons and constants.

Why? There's no need to call the developer attention SCREAMING_ON_CODE_THAT_CANNOT_CHANGE. A const val will never change. An enum member will never change. There's nothing to pay more attention here than any other symbol (maybe it should actually be the opposite, a top-level var should have this convention because that can lead to issues -- although I think in this case it should also be prefixed with CODESMELL_ 😁).

My guess is this convention came from Java, which came from C/C++, where developers reading macro usages should immediately know it would expand to arbitrary code, but this is not the case in Kotlin.

[ephemient]

for enum values, https://kotlinlang.org/docs/coding-conventions.html#property-names already says

For enum constants, it's OK to use either uppercase underscore-separated names (screaming snake case) (enum class Color { RED, GREEN }) or upper camel case names, depending on the usage.

[edrd]

Yeah, but I think it should also be changed to be strict on using PascalCase.

[jw]

Nothing else is strict on case

[louiscad]

Screaming case constants might communicate the fact that something is hardcoded, that's the only, very small benefit I found.

[Richard Gomez]

Screaming case constants might communicate the fact that something is hardcoded, that's the only, very small benefit I found.

It's also differentiated from Kotlin's convention of using PascalCase for functions and builders. e.g. interface CoroutineScope vs fun CoroutineScope.
https://github.com/Kotlin/kotlinx.coroutines/blob/4724523601237c8a02abcbf337f5a13d934599c5/kotlinx-coroutines-core/common/src/CoroutineScope.kt#[…]7