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