Kotlin Style Guide vs. Android Studio Lint & Coding Style

1. source file UTF-8 encoding

Android Lint UTF-8 encoding severity error

 

2. directory structure is on source root and the location need to also match

Android Lint Packge name not match severity info

 

3. source file name should be same with single class or cover the functional purpose with PascalCase and .kt extensions(recommend avoid meaningless words lie Utils)

Anroid Lint Class name convention severity weak warning

 

4. source file size remains reasonable(not exceeding a few hundred lines) and avoid creating files just to hold all extensions of some class

 

 

5. Class layout should go in the following order 

1. Property declarations and initializer blocks
2. Secondary constructors
3. Method declarations
4. Companion object

 

6. Don't sort the moethod declarations alphabetically or by visibility and extensions function all together

 

 

7. Put nested classes next to the code that uses those classes if not put them in the end, after the Companion object

 

8. Implemetation with same order

 

9. Don't use _ in package name if needed, use CamelCase

Android Lint Pcakge name convention severity weak warning

10. Use PascalCase in class name

Android Lint Class name convention severity weak warning

 

11. Use CamelCase in functions, properties and local variables(no _, exception. factory function has same with abstract return type)

Android Lint Naming convention severity weak warning

 

12. Test methods can use spaces enclosed in backticks and underscore

Android Lint Test methods name convention severity weak warning

13. Constants, top-level, and val properties(not mutable, if not use CamelCase) should use Uppercase and underscore-seperated(ex> const val MAX_COUNT = 9)

Android Lint Constant name convention severity weak warning

14. Enum constants, singleton reference properties can use PascalCase and enum constants is also okay using Uppercase

Android Lint Enum constants name convention severity weak warning

 

15. Add _ in backing field

 

16. Class name use noun, method name use verb

 

17. Use 4 spaces for indentations(do not use tab)

Android Code Style 4 spaces for indent

18. Put open curl braces in the end of the line where the construct begins and the closing brace on a sepearte line aligned with the opening construct

Android Coding Style left brace end of the line

 

19. Put spaces around binary operators(not range to operator)

20. Don't put spaces around unary operators

21. Put spaces between control flow keywords and the coresponding opening parenthesis

22. Don't put a space before an opening parenthesis in a primary constructor declaration, method declaration or call

23. Never put a space after (, [. or before ], )

24. Never put a space around . or .?, ::

25. Put a space after //

26. Don't put spaces around angle brackets with type parameters(ex> Map<K, V>)

27. Don't put a space before ?(null type)

28. Colon in supertype(also generic), object has a sapce before but not in type declaration

 

29. Class header all in one line if short. if not, constructor parameter is in seperate line with indentation and closing parenthesis should be on new line. Superclass is also all in one line if short. If not, class first(if long, break line at :) and then interfaces on new line. 

class MyFavouriteVeryLongClassHolder :
    MyLongHolder<MyFavouriteVeryLongClass>(),
    SomeOtherInterface,
    AndAnotherOne
{
    fun foo() { /*...*/ }
}

 

30. Modifier order and place all annotation before modifier

public / protected / private / internal
expect / actual
final / open / abstract / sealed / const
external
override
lateinit
tailrec
vararg
suspend
inner
enum / annotation / fun // as a modifier in `fun interface`
companion
inline / value
infix
operator
data

 

31. Single annotation in one line with function if not only the annotation without parameter in one line

32. File annotation are palced before the package statement and are separated from package with a blank line

 

33. If function fit in one line expression body also if not, following the pattern. If expression body is too long then break after =

fun longMethodName(
    argument: ArgumentType = defaultValue,
    argument2: AnotherArgumentType,
): ReturnType {
    // body
}

 

34. Simple read only properties is in one line if not, seprate lines

 

35. Control flow statement is too long then separate after binary operator and close parenthesis in separate line of last control flow statement and always use curly braces

if (!component.isSyncing &&
    !hasAnyKotlinRuntimeInScope(module)
) {
    return createKotlinNotConfiguredPanel(module)
}

 

36. Subsequent control flow keyword is in one line of close curly braces

 

37. If when statement branch several consider separate from adjacent case with a blank line and short branch in one line without braces

 

38. When method calls, put the parameter on the same line if related than others

 

39. Wrap chain calls on the next line with a single indent

 

40. Lamda has spaces around curly braces and also arrow but when label has no space with curly braces

41. Lamda has multiple parameter line if long

 

42. Trailing comma is optional

 

43. Comments starts with /** and have separate lines starting with * and end with */(also fit in one line) and avoid @param, @return inside

 

44. Omit Unit return type

45. No semicolon in the end of the line

46. Don't use curly braces in the string templates when using simple variable

 

47. Recommend using val rather than var if no modified after initialization

48. If not mutated, using immutable collections like Collection, List, Set, Map etc.

49. Recommend using default parameter values

50. Declare typealias of functional type or simple type if using mutliple times and using import with as to avoid collision

51. In simple and single lamda, use it convetion. If not, declare parameter

52. Avoid using multiple labeled returns in lambda(recommend with single exit) and do not use labeld return in last statement

53. Use named arguments

 

54. Simple conditional statement don't need to use return keyword and newline

 

55. If binary conditions use If not When

 

56. Using higer-order functions like filter, map etc. to loop(exception forEach)

 

57. Using until with open range

 

58. Using embedded newline escape in string literals if no need indentation use tirimIndent() if need indentation use trimMargin()

 

59. Use properties than functions when not throw and cheap to calculate and returns the same result with same state

 

60. Consider extension functions

 

61. If two obejcts play similar role, declare infix like and, to, zip(add is bad case) and don't mutate the objects

 

62. Factory function name avoid giving it the same name of the class and replace overloaded constructors which can't reduced a single constructor

 

63. When get a platform type, declare type explicitly on public function and property(local value is optional)