Kotlin 🌈

Hero image for Kotlin 🌈

Reference Resources

When it comes to Java most conventions are shared with Kotlin. But when there are differences, specific examples for Java are added. For more generic conventions, we follow:


  • Indentation:
    • Only using spaces * never tabs.
    • Use 4 space indents for blocks and 8 space indents for line wraps.
    • It’s also flexible to change the rules too, as there is a recommendation from Google to use 2 space for blocks and 4 space for line wraps too, so, depending on the start of the project, we should always follow the base structure.
  • Line length: it shouldn’t exceed the screen width, ideally should be no longer than 100 characters.

  • Line amount per class: should be no longer than 600 lines per class.

  • Vertical spacing: it’s very important that you should keep alignment on your new lines to code to be consistent with the current code base in order to have a good experience when doing code reviews.

  • Brace style:
// Bad
public void main()
    // Not this

// Good
public void main() {
    // Your code goes here
  • Conditional statements are always required to be enclosed with braces:
// Bad
if (conditionPassed)

// Good
if (conditionPassed) {
if (someTest) { doSomethingElse(); }

if (someTest) doSomethingElse(); // Still acceptable
  • Method chain case:

When multiple methods are chained in the same line * for example when using Builders * every call to a method should go in its own line, breaking the line before the .. For example:

  • RxJava chaining style:
public Observable<Location> syncLocations() {
    return mLocationHelper.getAllLocations()
            .concatMap(new Func1<Location, Observable<? extends Location>>() {
                 public Observable<? extends Location> call(Location location) {
                     return mLocationService.getLocation(location.id);
            .retry(new Func2<Integer, Throwable, Boolean>() {
                 public Boolean call(Integer numRetries, Throwable throwable) {
                     return throwable instanceof Error;



Package names are all lower-case, multiple words concatenated together, without hypens or underscores:

// Bad

// Good



// Bad
private int mTemp;
private boolean mA;

private void check() {
    // Do a bunch of logics here

// Good
private int mTemporary;
private boolean mIsValid;

private void checkStyle() {
    // or private void validateStyle() and do your logics here

Classes and Interfaces

  • Written in UpperCamelCase.
// Bad

// Good


  • Written in lowerCamelCase.
// Bad

// Good


  • Normally be written in lowerCamelCase.
  • Non-public, non-static field names start with an m.
  • Static field names start with an s.
// Bad
private int Value //or anything else.
public static Singleton singleTon;

// Good
private int mValue; // Note: in Kotlin it could be different.
public static Singleton sSingleton;
  • Static final fields should be written in uppercase:
// Bad
public static final int extra_value = 42;

// Good
public static final int EXTRA_VALUE = 42;
  • Acronyms should be treated as words:
// Bad
String URL

// Good
String url
  • Example:
public class ExampleClass {
    public static final int SOME_CONSTANT = 42;
    public int publicField;
    protected int mProtected;
    private String mUrl;

    private int findRateById() {
        // Your code goes here
class ExampleClass {
    val publicFinalField: Int
    var publicField: Int = 0
    protected val protectedField: Int
    private val url: String

    private fun findRateById(): Int {
        // Your code goes here

const val SOME_CONSTANT = 42


  • Access level modifiers should be explicitly defined for classes, methods and member variables:
// Bad
boolean isValid;
void method() {
    // Nope

// Good
private boolean isValid;
public void method() {
    // Your code
  • Classes should be one class per source file, although inner classes are still encouraged in some situations.

  • Enum: should be avoided where possible, due to a large memory overhead. Static constants are preferred. See more or here.


// Bad

// Two line
// comments

  * Block comment but mis-aligned

// Good

// One line comment

 * Block comment
 * that is longer than 2 lines

  * Class/method description (Javadoc)
  * @param  url  an absolute URL giving the base location of the image
  * @param  name the location of the image, relative to the url argument
  * @return      the image at the specified URL
  * @see         Image