Archive
Michael MULLER
-
The code contain too many unused private methods
Private methods that are never executed are dead code: unnecessary, inoperative code that should be removed. Cleaning out dead code decreases the size of…
-
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…
-
Boolean checks should not be inverted
is needlessly complex to invert the result of a boolean comparison. The opposite comparison should be made instead. This is furthermore the case in…
-
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…
-
Avoid generic catch
You should not ignore exceptions. It can be tempting to be lazy when catching exceptions and do something like this: (see example below).
-
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 undefined type on data or routines declaration
Groovy support dynamic types, that is declarations where the type is def or unspecified.
-
Avoid to update static fields from instance methods
Correctly updating a static field from a non-static method is tricky to get right and could easily lead to bugs if there are multiple…
-
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…