Update Coding Conventions to match Compose conventions

[edrd-f]

While discussing on Slack, there was an overall consensus that the current SCREAMING_SNAKE_CASE convention is inconsistent for a few reasons:

1. It shouts at the readers and calls their attention first thing for things that shouldn't get more attention than other parts of the code. Enums, singletons, and constants do not hold any special characteristic that would require the reader to inspect the value of the variable or where it's being used. They don't represent unsafe, sensitive, or experimental code*.
2. Compose, along with most of their plugins, libraries, and extensions, use the PascalCase convention. They have their own convention and reasoning for it written down here.
   • Given that Compose is one of the most-used frameworks, it fragments the community towards either their or Kotlin's official convention, which is bad.
3. Having either PascalCase and SCREAMING_SNAKE_CASE allowed for enums isn't a good convention because it allows developers to make individual decisions on which style to pick and leads the project to a mixed (or no?) convention (Ktor's public enums are an example), defeating the purpose of a convention, which is to standardize the way developers write code and eliminate bike-shedding.

Given that Kotlin 2.0 is about to be released, this is the perfect time to make this change, and the community, as well as some JetBrains team members, have voted in favor of this change. I will be linking the PR on the Slack thread so the community and the Kotlin team are up-to-date and can add feedback.

---

* On a side note, the current convention is likely inherited from Java, which in turn inherited it from the C/C++ convention for macros, as they were used for constants. However, macros indeed require more attention because of arbitrary code expansion, so the shouting makes sense.

[brighthr-stanton]

I'm really in favour of this. Pascal case is much more readable.

[github-actions]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[edrd-f]

Update: the proposal got a green light from the Kotlin team (see the Slack thread), but the migration process to the new convention still needs to be figured out.

[github-actions]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[CLOVIS-AI]

What are the next steps needed for this to be merged? I don't see any obvious marker of required future work, is this just waiting for a reviewer?

[edrd-f]

@CLOVIS-AI I believe there needs to be a migration plan first. I suggested one on the Slack thread but I think the team was very busy at the time due to KotlinConf, so we didn't discuss further. Feel free to bump the thread – it's linked in the PR description.
Also, it would make sense to update the code samples to use the new convention. I'll work on that in the meantime.

[github-actions]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[CLOVIS-AI]

Bump.

[github-actions]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[CLOVIS-AI]

Bump.

[qwwdfsad]

Hey!

We are still not sure how to proceed with that because the change is beyond technical -- we have to revisit all our educational materials (as well as, potentially, books, StackOverflow answers, our own libraries and recommendations), update the toolchain (e.g. the default IDEA settings) and, what's the most important, make an assertive decision that this is the way and adopt it everywhere. Basically, we are changing an invariant and coding practice that was held true for 10-29 years.

The best way here is to lay out your arguments in https://youtrack.jetbrains.com/issue/KT-48496/Top-level-name-of-constants-convention in a structured manner