https://kotlinlang.org logo
Title
s

stantronic

03/20/2023, 5:17 PM
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)
j

Javier

03/20/2023, 6:09 PM
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.
s

stantronic

03/20/2023, 6:33 PM
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
e

edrd

03/20/2023, 6:44 PM
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.
a

andries.fc

03/21/2023, 10:03 AM
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.
m

mkrussel

03/21/2023, 1:40 PM
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.
m

mcpiroman

03/22/2023, 9:21 AM
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.
e

edrd

03/22/2023, 5:18 PM
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
a

asdf asdf

03/22/2023, 5:51 PM
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)
m

mkrussel

03/22/2023, 5:54 PM
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.
e

edrd

05/16/2023, 4:32 PM
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
l

Loney Chou

05/16/2023, 4:42 PM
Same concern, maybe there should be a kotlin answer.
e

elizarov

05/17/2023, 7:08 AM
Can you give an example of which particular declarations with different style in the same code are confusing?
l

Loney Chou

05/17/2023, 10:36 AM
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.