Archive
Code Readability
-
Variables should not be shadowed
Overriding a variable declared in an outer scope can strongly impact the readability, and therefore the maintainability, of a piece of code. Further, it…
-
In switch ‘default’ clauses should be last
Switch can contain a default clause for various reasons: to handle unexpected values, to show that all the cases were properly considered. For code…
-
A field should not duplicate the name of its containing class
It can be confusing to have a class member with the same name (case differences aside) as its enclosing class, especialy when considering the…
-
Use == instead of ?: when dealing with nullable boolean
USE == INSTEAD OF ?: WHEN DEALING WITH NULLABLE BOOLEAN
-
Prefer using expression Form for ‘if’ or ‘when’ in place of statement syntax
In Kotlin, “if” and “when” returns a value, and so can be used as expression. When possible, prefer using the expression form.
-
Do not use a labeled return for the last statement in a lambda
The return keyword is relative to the nearest enclosing function (or anonymous function). So for returning from lambda, a labeled return is needed. But…
-
Avoid using multiple labeled returns in lambda expression
The return keyword is relative to the nearest enclosing function (or anonymous function). So for returning from lambda, a labeled return is needed. But…
-
Use Elvis operator to avoid unclear syntax pattern
Elvis operator ?: is an syntactic sugar for if (!x) { x=something }. Prefer Elvis notation for readability considerations.
-
Avoid to update parameters inside routine’s bodies
Reassigning parameter of function to a new value within the body of the method/closure, is a confusing and questionable practice. Use a temporary variable…
-
Avoid unexpected closure inside parentheses call
If a method is called and the last parameter is an inline closure then it can be declared outside of the method call parentheses,…