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.


  • Comment should follow the Java docs comment style guide, example:

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