Kotlin code style

For one and a half years of working with the Kotlin language, we transferred all our projects and frameworks to it. So that the developers could quickly get involved in the work on the project, and the review code did not turn into an endless dispute, we decided to formalize the accumulated experience and developed our own code-style.

Go!

Each developer writes code based on their own experience and habits. If on the project one developer or the code is written for itself, it is not a problem. But in large teams working on several projects, problems inevitably arise:

• it takes a lot of time and nerves to review a code - one can argue ad infinitum without a single standard;
• you need a lot more time and effort to dive a new person into the code;
• more difficult to concentrate on the function that the code performs;
• as a result, the project looks like an imprint of all the specialists who took part in it.

And even if now you are the only developer on the project, do not forget - someday it will end. And it depends only on you whether the new person in the team will be grateful to you or will first try to find out your address.

Having a single style of writing code allows solves all these problems.

Why now and why we

Kotlin is quite popular in the community of Android developers, and every day it gathers more and more supporters . But finding a code-writing style that can be guided is still a problem, and agreements published on the official language website do not provide exhaustive answers, since the number of rules that are present there can hardly cover most of the team’s needs. For example, do not contain rules for formatting functions, their call and descriptions.

At the time of writing, an official guide from Google came out with answers to questions about writing code on Kotlin, which to some extent influenced the article. It was interesting for us to compare the results and analyze what our opinions agreed on and what we found out to disagree with.

About the rule development process

The process of developing a unified style with which such a large team as ours would agree is not simple: to collect ideas and suggestions, take into account everyone's opinion, remember what moments cause controversy on the review code. It is expected that a single verdict on all issues will be practically impossible to achieve, but it is important that everyone recognizes the importance and benefits of the process, be ready to make concessions and abide by the decisions made.

Of course, over time, the set of rules may be reviewed and supplemented - we plan to keep our set of agreements up to date.

Controversial moments

With our understanding of how the code should look, you can familiarize yourself with the link at the end of the article, and below we would like to present particularly controversial and controversial points.

1. Field Names View and Kotlin Android Extensions

In developing the standard, we tried to abstract away from external dependencies or the possibilities of using the IDE and would focus on the language in its purest form. But still made an exception for the Kotlin Android Extensions. Since we most often use Kotlin in Android development, and applications cannot do without the use of XML, since most of the resources are described in this format in the lower_snake_case style. Thus, we made an exception for View identifiers (we describe them just in this style) and calls to these fields (although if you look at how this magic works in runtime, it turns out that these are not variables, but keys to get values ​​from HashMap) . From the code it looks like a reference to a field written in the style of lower_snake_case, but it is always clear in the code that the View field is being accessed.

2. The order of private methods

Another controversial point was the location of private methods. There are two common options: write them immediately after the method, where they were used, or in the class structure after all the methods. We agreed on the second version. Since we consider a class as some kind of interface, it is first of all interesting to know what it does - due to the fact that all private methods are located at the very end, you can quickly understand the responsibility of this class by its interface. Private methods, as a rule, already contain specific implementations, and we often turn to them only if we want to make changes. And in this case, the structure of any class will always remain consistent.

3. Constants

The question of naming constants entails another important problem: what now is a constant in Kotlin? The language provides a keyword to denote compile-time constants, but compile-time constants can only be of the primitive type and String. As constants, I would like to use other immutable variables located in the Object block - for such cases we have expanded the understanding of the constants in naming, including such unchangeable variables as well. It is interesting that in this our opinion coincided with the position of Google.

4. Package Names

In the process of work, we often had a problem with naming packages: different features may not be so obvious that when creating a new package for them, you need to use two or more words to accurately reflect the meaning. In the package naming rules for Java from Oracle, packages are proposed to be combined without separators, which in our projects could lead to the appearance of packages with difficult to read names. Therefore, we added the ability to separate packages with the underscore symbol. It is worth emphasizing that the use of such a style should be the enforced exception rather than the rule, and it should be avoided as much as possible.

5. Annotations

Another point where our vision differs from the common one turned out to be the use of single annotations: in some recommendations it is allowed to write several annotations without parameters on one line or even leave one annotation without parameters on one line with the described method / field. This approach, in our opinion, does not have any particular benefit (unless space is saved), and the code due to such exceptions becomes less consistent, so we decided to leave a single rule for all annotations: always specify them with a new line.

6. Functions as expressions

We also limited the ability to use function expression - to describe a function as an expression is allowed only if it fits on a single line (for this, by the way, we increased the maximum string length to 120 characters). If the expression does not fit on a single line, it is likely that with further changes it may be necessary to translate this function into the normal spelling, and even this expression will not be any easier.

What we have

In the end, I would like to indicate why even despite the fact that Google has released its style guide, we still publish our presentation. As already mentioned above, a set of agreements from the developer of the language itself - JetBrains, because of its brevity, hardly covers all the needs of the team, I really hope that the Kotlin development team will not stand aside and will further develop this list. After a closer look, you notice that most of Google’s rules were copied or reformulated from their style guide on Java, we tried to take into account the experience of other related programming languages ​​as well, but to a greater extent we relied on using different approaches to styles, and just such an approach allowed we reveal some points (class structure, description, function call, and other rules).

What's next

Even after adopting a common standard for writing code, problems may arise: someone may forget the rules, or worse, start sabotaging them. It is good if this code is rejected at the code review stage, but the reviewer may not notice these errors or even engage in subversion. Despite the youth of Kotlin, there are already static code analysis tools for it, for which it is possible to describe all the rules and track any violation automatically, which is already on the way in our backlog. The service will help developers be more disciplined and free Reviewer from having to check the code's compliance with the accepted standard, and then these tools will become helpers in maintaining cleanliness on the project.

References:

1. Redmadrobot Kotlin Style Guide
2. Coding Conventions from the official site of Kotlin-a
3. Style Guide in the repository of Dmitry Zhemerov
4. Google's Style Guide for Kotlin