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:

Formatting

  • 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)
    doSomething();

// Good
if (conditionPassed) {
    doSomething();
}
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:

SomeClass.Builder.with(context)
        .setAlpha("1")
        .setCancelable(false)
        .setExtras(bundle)
        .build();
  • RxJava chaining style:
public Observable<Location> syncLocations() {
    return mLocationHelper.getAllLocations()
            .concatMap(new Func1<Location, Observable<? extends Location>>() {
                @Override
                 public Observable<? extends Location> call(Location location) {
                     return mLocationService.getLocation(location.id);
                 }
            })
            .retry(new Func2<Integer, Throwable, Boolean>() {
                 @Override
                 public Boolean call(Integer numRetries, Throwable throwable) {
                     return throwable instanceof Error;
                 }
            });
}

Naming

Packages

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

// Bad
com.nimble.android_demo

// Good
com.nimble.androiddemo

Variables

BAD:

// 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
BaseACTIVITY

// Good
BaseActivity

Methods

  • Written in lowerCamelCase.
// Bad
setvalue

// Good
setValue

Fields

  • 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
XMLHTTPRequest
String URL
findPostByID

// Good
XmlHttpRequest
String url
findPostById
  • 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

Declaration

  • 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.

Comments

// 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
  */