Official Kotlin style guide?

1

Are there any plans for a JetBrains Manual of Style for Kotlin code?

I ask because I often find myself unsure what the best, most Kotlish way to write things would be. For example:

fun doSomething(): Thing? = try {
  blah blah blah
} catch (e: Exception) {
  null
}

Imagine for a second that swallowing the exception in this case is the right thing to do - but is the multi-line expression good style, or does it make more sense to make a proper surrounding function body for that?

What about the right way to indent long constructor lists?

When is it better to use the forEach method, vs a regular for loop?

What about use of “it” - when is a named lambda argument more or less appropriate?

You can imagine many more.

Some languages such as Go practically require a specific style and it’s all expected to be entirely the same everywhere. I don’t know if Kotlin needs to be so picky, as the answers are often arbitrary. But as the creators of the language it’d be nice if JetBrains could do what Sun did with the original Java and write a style guide to keep things consistent.

2 Likes
2

I agree this would be nice to have especially now the language is settling down...

3

The Kotlin reference documentation has a section for coding conventions, if this is what you are looking for.

http://kotlinlang.org/docs/reference/coding-conventions.html

There is also a collection of idioms at http://kotlinlang.org/docs/reference/idioms.html.

Both documents are editable and extendable via GitHub editor or Pull Requests.

–Benjamin

1 Like
4

>Some languages such as Go practically require a specific style and it's all expected to be entirely the same everywhere.

A tool like gofmt would be really great. Other languages like Rust and JavaScript (JavaScript Standard Style [1]) have also a formatter or linter, respectively.

I guess IntelliJ has a menu item for code formatting of Kotlin code. I don’t know which is the best way, some people use formatters, that automatically format the code, others use linters that only report for invalid code conventions.

[1] https://github.com/feross/standard

1 Like
5

Yes, we do plan to provide such a style guide, and to make sure that the default formatter and inspecition settings match the style guide.

6

Yes, IntelliJ IDEA does have a built-in formatter for Kotlin code, and we plan to improve it significantly before the release. We do not have any plans to provide any kind of tool that would complain about "incorrect" formatting, for any definition of "incorrect".

8

I hope JetBrains develop an aggressive kotlin formatter, just like google-java-format. It’s good for team work.

9

A while back I discovered this Kotlin style guide on GitHub which is much more extensive than the one published on the Kotlin website and has helped me a lot.

Hopefully, it will be merged into the master before too long.

One thing I was relieved about is that there is no explicit ruling that one should always use ‘cuddled’ else, catch, finally or do/while which I’ve always hated (it looks too squashed to me) even though I recognize that most folk seem to prefer it.

10

I want to throw in some unconventional suggestions, not conforming to Java:

Some research has shown, that names with underscores are easier to read than camelCase. So, a coding convention could consider this:

fun find_user_by_email(email: String): User?

Constants like MAX_COUNT with all upper cases names are bit like hungarian notation. Scala has already abandoned this convention.

However, I don’t follow these conventions myself, since it is neither common in Java nor in Kotlin, but at least the Kotlin part could be changed.

11

Underscores are bad.

  1. Classes names begin with capital letter. It is important convention and underscore breaks it. There is also Java beans convention which is used a lot in kotlin.
  2. All JVM languages use camel case and to introduce something completely different is strange. Using two different conventions is impossible since people accustomed to one convention will have problems reading with another one (C/C++ ecosystem is a mess).
  3. Once you start to use underscores in names, sooner or later someone starts to use names beginning and ending with underscores, double underscores, etc. It breaks readability and gives people some wrong ideas.

I do not think that 20% of read speed is an issue. Code readability is not how fast you can read the code, it is how comprehensible the code is. If you want reading speed, you can just use short names like in C/Fortran (but I hope you won’t since it leads to disaster).

12

Fair points. However class names beginning with capital letters and underscores are independent. Here is the proof: Bean_Factory :wink: But you are right: introducing such a change in an existing ecosystem would be strange.

Avoiding all uppercase constants wouldn’t be as strange.

13

I think that uppercase constants are optional. But they do increase readability in many cases. In kotlin constants have their own keywords, so they could be marked by IDE, but if you just read the text, it is in many cases easier if you can immediately know if some value is just a compile-time constant and you do not need to search for it.

14

Yes, I remember reading about the ‘camelCase versus underscores’ research favouring the latter though there’s not a lot of difference and I think a more important consideration when using a particular language is to use the naming style which is conventional or prevalent in that language.

Having said all that, I personally much prefer camelCase to underscores and so I’m pleased that this is the convention in Kotlin as it is in Java. I do however agree with @darksnake that it’s sensible to make an exception for compile time constants where ‘shouted snake case’ is the usual convention.

Kotlin Native has a bit of a problem here with C interop where most native libraries (though by no means all) stick to the C convention of using snake case. Consequently, code which calls C functions tends to be an uneasy mix between the two systems.

It might be possible for the CInterop tool which automatically translates C header files to Kotlin ‘klib’ files - and must be very complex internally - to change the C names to Kotlin style names at the same time. However, even this wouldn’t be an ideal solution, because if you were trying to convert C code examples to Kotlin you’d need to mentally adjust to the changes.

15

C does not have any standard code conventions so there are a lot of libraries with camel case. Furthermore there are a lot of libraries with Fortran-77 8-symbol names and a lot of C libraries that use short function names just out of laziness.

I think that could be only solved with some kind of aliases for native functions.

16 
inline fun aBetterNameForACFunction() = pf_acf()

:wink:

17

That\s what I am talking about :slight_smile: