Kotlin 🌈

Reference Resources

• Kotlin convention (official site) and Kotlin Idioms
• Ray Wenderlich’s Kotlin Guideline

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

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