Why does kotlin style guide require screaming snake case for const vals? Is there any hope that this might be relaxed to allow PascalCase? (more readable and makes me feel less like I’m being shouted at)

convention guides indeed says you can use

PascalCase

too, if not, they are doing that already on Ktor and Compose official repositories, so they should add it.

yeah, i thought so too, but the official docs still recommend the shouty style for compile-time primitive constants - https://kotlinlang.org/docs/coding-conventions.html#property-names

Yeah, I don’t understand the point of using a convention that calls the reader’s attention for something that won’t change. Classes are also immutable and use

PascalCase

. To me, it looks like something inherited from Java.

I treat constants/objects as just another type. Even Enums I rather prefer to something like Status.Inactive vs Status.INACTIVE. Especially as both are classes and should have been treated to the same naming standards. I agree with @edrd that this just an legacy of Java. If I’m not mistaken, Java did not have any Enum support originally.

https://youtrack.jetbrains.com/issue/KT-48496/Top-level-name-of-constants-convention.

It doesn't make a lot of sense to change a coding convention after this much time. You will then be consuming APIs each of which use a different convention, defeating the point in having a convention. I'm sure that also influenced having the current convention match Java, so that calling Java code looks the same as calling Kotlin code.

You will then be consuming APIs each of which use a different convention

Thing is that's already the case. And while I have no idea how could that happen, I'd very like to see some a unification in this regard, hopefully into CamelCase.

Yeah, and happening with very popular libraries (Ktor and Compose), so code bases using them and official Kotlin libraries like coroutines are already mixing the code styles

I also find it much more preferable to use pascal for constants as then you don’t have to make sealed object types screaming, which goes against class naming convention (ie: objects in screaming case in kotlinx serialization SerialKind)

Object classes should use PascalCase because they are classes. Not sure why serialization library went with screaming. My guess is that it was an enum before becoming a sealed class. Or not to conflict with primitive class names.

I’d like to bring up this subject again. Right now, code using Ktor/Compose + other libraries (even stdlib) is mixing the code styles and the resulting code looks messy and creates confusion because one convention calls the readers’ attention way more than the other. Is there any chance that this can be changed in Kotlin 2.0, which will be a major release? cc @elizarov

Same concern, maybe there should be a kotlin answer.

Can you give an example of which particular declarations with different style in the same code are confusing?

For example, in compose enum entries and constants (or equivalent constants) are named PascalCase, such as FocusStateImpl.Active (in FocusState.kt), DefaultDensity (in LayoutNode.kt), whereas in most other places these are named SCREAMING_CASE, like CoroutineStart.LAZY, SerialKind.INT. This is not about confusion, but inconsistency.