Why does kotlin style guide require screaming snak...

# language-evolution

[stantronic]

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)

[Javier]

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.

[stantronic]

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

[edrd]

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.

[andries.fc]

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.

[mcpiroman]

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

[mkrussel]

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.

[mcpiroman]

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.

[edrd]

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

[asdf asdf]

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)

[mkrussel]

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.

[Loney Chou]

Same concern, maybe there should be a kotlin answer.

[elizarov]

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

[Loney Chou]

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.

[edrd]

@mikhail.zarechenskiy I know this may sound minor/irrelevant compared to other things being worked on, but I think this is the best time to make this change given that 2.0 is not yet released but pretty close. It would be great to have a standard that’s consistent with Compose and Ktor.

[edrd]

My last attempt 🙃

https://github.com/JetBrains/kotlin-web-site/pull/4154

[mikhail.zarechenskiy]

Sorry for the late reply. I see it as the right direction; we're gradually moving to a uniform representation of enums and sealed hierarchies. Sealed hierarchies will get their short syntax and enum-like capabilities one day. And today, we see that sealed hierarchies look and read totally fine with PascalCase, as do enums. Well, even in our compiler we use PascalCase in the code, even in our famous LanguageVersionSettings.kt

Let me see how we could proceed

[edrd]

That’s great to hear, @mikhail.zarechenskiy. Let me know if there’s anything else I can do to help. For example, I can open a PR updating the IntelliJ inspections, if that makes sense.

[mikhail.zarechenskiy]

JFTR: We definitely cannot flip the default right away. While PascalCase seems a better option, we shouldn't bother the existing users with millions of lines of code too much. And we shouldn't forget about the Java-converted code that must require backward compatibility in many cases. That's why this new convention should be more flexible and probably start working only in new projects

[edrd]

Makes sense. If the IntelliJ inspection is updated, this can cause thousands of warnings in big projects, so definitely not desirable.

A solution would be to support a new value such as official-v2 for the kotlin.code.style property, like it was done for the first style migration. New projects bootstrapped with Gradle/Maven/IntelliJ/KMP-wizard could then have this value as default, while pre-K2.0 projects would keep official. This would ensure a smooth migration.

[Javier]

I think both can be valid, the actual problem is that PascalCase is reported with a warning. The consumer can decide what to use at the end.

[mikhail.zarechenskiy]

And this part is nicely summarized by @edrd: lack of convention leads to a mix of two worlds, even within one project—especially when we have had one convention for a pretty long time
• https://github.com/ktorio/ktor/blob/5f27f303bd26a361430b45fe173434d35986f52a/ktor-http/common/src/io/ktor/http/Cookie.kt#L45
• https://github.com/ktorio/ktor/blob/5f27f303bd26a361430b45fe173434d35986f52a/ktor-http/common/src/io/ktor/http/Ranges.kt#L16

[CLOVIS]

Hi! The linked PR has been marked as stale by GitHub, but I don't see any mention of what it is blocked on. Could someone from the team take a look?

W.r.t. migration guide, I think there's not much to say.
• Existing library code in SCREAMING_CASE cannot change, because that would require a breaking change.
• Existing application code in SCREAMKING_CASE may change if it wants, but it's probably not worth the hassle.
I don't think IntelliJ's code cleanup feature renames stuff?

So, the only thing to do, as I see it, is the change the wording of the recommendations, and maybe update relevant IntelliJ quick fixes (but I believe they already allow both naming conventions), and that's it, since changing existing code is kind of impossible.