※Notes記事では、英語のセッション動画やポッドキャストの内容を(雑に)英語でメモに書き残すことを行っています。本記事は、あくまで動画を見ながら、参考程度に読んでいただくことを想定しています。Notes記事には雑メモ程度のものだったり、書き起こしのようなものもあります。これから実際の動画を見る際には、本記事の内容が少しでもお役に立てば幸いです。（内容において不備、誤字脱字等ありましたら気軽にご連絡いただけると嬉しいです。)
本記事は、Fragmented Podcast: 105: Jake Wharton on the Android Kotlin Guidesの記事です。
TL;DR
- Jake Wharton working on android/kotlin-guides on github
- Style guide to provide a set of rules to follow, and Interop guide to provide practices and things to care for those developers who ..
105: Jake Wharton on the Android Kotlin Guides http://fragmentedpodcast.com/episodes/105/
About android/kotlin-guides
Q. Is this the defacto style guide for Kotlin? What was the reason for it?
There are two guides: Style guide and Interop guide
- Style guide for regular Android app developers to style..
- code structure, and
- new Kotlin files
- Interop guide for developers to easily co-exist both Kotlin and Java code without feeling awkward especially when calling codes from one language to the other.
Reasons:
- Android has never had a style guide for non-Google developers
- There was AOSP style guide but it was only for developers of ASOP. And, Android has been around for 10 years; Most apps have Java code so there needs to be something that people can follow to feel natural when introducing Kotlin code into existing Java code base or consuming APIs of Kotlin language from Java code base.
Q. Why NOT Google Kotlin Guide, and Android specific?
- Currently Google makes use of Kotlin language for Android platform, so we want something tailored for it, fairly quickly, rather than something very general.
- It is influenced by Google Java style guide
Q. What about current JetBrains' style guide?
android/kotlin-guides is consciously made not to have conflict with the guide from JetBrains. However, following JetBrains' Kotlin style guide does not mean it is 100% valid for android/kotlin-guides because JetBrains' kotlin-guide is more focused on Kotlin language itself and its future, but android/kotlin-guides cares about natural, comfortable interaction between Java and Kotlin languages as well.
IntelliJ platform does not support code formatting exactly as style guide recommends. (Information from KotlinConf)
Q. How did you start making android/kotlin-gudes?
Goal: - Easy to access - Easy to contribute
Docs on android.developer.com are difficult to contribute for developers.
- Started with Google doc -> internal review -> API counsel ..etc.. Eventually to github.com with Jekyll
Q. How did you decide what to put in kotlin-guides, especially controversial ones as personal preference or something with non-logical reasons?
- Looking up
- Feedback from people from JetBrains who are making their guide in parallel
Q. One of the difficult choices? - for example, 2 spaces -> 1 tab(4 spaces)
- Google Java style guide specify 2 spaces
- JetBrains' kotlin guide specifies 1 tab
- The almost all codebase at Square was also 2 spaces when Jake joined
- "It seems everything is so far a part"
Q. Why "Style Guide" and "Interop Guide"?
Style Guide
Style guide aims to have rules that are unambiguous and can potentially be enforced or even formatted by an automated tool. - Meant to be 'Hard rules' - Everything should be deterministic, unambiguous just single way of doing something
Interop Guide
- 'Rules but a bit of interpretation'
- Something you need to think a bit
- For people to have mixed (Java & Kotlin) sources
Eventually adding something more subjective.. - Design patterns - Best practices or patterns - Something people can decide whether or not they apply
Highlights of the guides
Style guide: Use-Site Targets
- https://android.github.io/kotlin-guides/style.html#file-level-annotations
https://kotlinlang.org/docs/reference/annotations.html#annotation-use-site-targets
File use-site targets allow you to control the name of the Kotlin classes Java references.
- Kotlin file names may become public API for Java sources (e.g. static extension function referenced from Java source code)
Style guide: Logical Ordering
Q. What is a good logical ordering?
- The most important part of the guide is there is no "One true order"
- The rule here is that "there is no rule"
- Too strict ordering may harm the ability to understand what is going on.
Q. Why is the column limit 100 characters?
- It is already being used
- It is what Google Java style guide is using too
- It is not considered as something that needs to be changed
Q. About "Higher syntactic level"
- Stolen from Java style guide
- When performing line breaking, you do not want to break
- If you perform line breaking, you want to keep the inner function calls and their arguments together
Q. Expression Functions
- Sometimes it is easier to have normal function body that have multiple expression bodies
- By having expression functions it is tempting to delcare all functions as expression functions but sometimes it makes harder to read or understand the body of the function.
For contribution
The reason the guide is on GitHub is because we want people to contribute If there is ambiguity, wording miss, incorrect or not conveying the right thing please please contribute. - Already bunch of fixes and so on - Contents from KotlinConf - Thinking to release once every 2 or 3 weeks until the guide stabilizes - Do not want to overwhelm people with changes - Going to provide change logs to easily figure out what is changes
Use of annotations recommended by the style guide
- You don't have to follow the every single rules but if you start writing codes from the scratch
Q. Do we / should we use Hungarian notations?
- The language itself actively discourages you from using any kind of prefix.
e.g. Kotlin property delcaration which is consumed from Java
val mName: String = ...
pubic String getMName() { // Super weird!
return ...;
}
Q. Interop Guide
Java (for Kotlin consumption)
The motivating factor here is that every new API that is added to Android Framework itself or support libraries are consumed from both languages by developers, so there is a strong need to have a set of rules that you can follow or interpret when you are writing these APIs to make sure that they actually feels nice from both languages.
Kotlin (for Java consumption)
We assume that in the near future, more libraries will be written in Kotlin first and those APIs may be consumed from people using Java, so the API Kotlin code needs to be feel idiomatic for them as well. That is the rason why there is a separation.
About "No hard keyword"
- Kotlin has a notion of both "hard" and "soft" keyword
- class
- if
- else
- try
- class
- when
For example, You can't name a class 'name' or 'if'.
- Keywords for Kotlin uses are different from keywords for Java uses.
- If you were to write a new API the style guide strongly recommends not to use those keywords.
Q. Defensive copies
- Kotlin does have a notion of 'read only' property
- 2 parts of this:
val(= read only), two versions ofCollections
Whenever you return a list in a public API where you are sure or there is a possibility that the value will be refenced from Java then it should wrap it or make a defensive copy from Java
- Guava has it's own version of immutable list
- JetBrains is also working on Kotlinx.collection.immutable.
