Alex Thottunkel
- Total activity 2325
- Last activity
- Member since
- Following 0 users
- Followed by 0 users
- Votes 1
- Subscriptions 1186
Articles
Recent activity by Alex Thottunkel Sort by recent activity-
Use == instead of ?: when dealing with nullable boolean
Why you should care Nullable boolean can be null, or having a value "true" or "false". var a: Boolean? // a is a nullable boolean Before accessing the value, we should verify if the variable is...
-
The code contain too many unused private methods
Why you should care Private methods that are never executed are dead code: unnecessary, inoperative code that should be removed. Cleaning out dead code decreases the size of the maintained codebas...
-
Prefer using expression Form for ‘if’ or ‘when’ in place of statement syntax
Why you should care In Kotlin, "if" and "when" returns a value, and so can be used as expression. When possible, prefer using the expression form. How we detect CAST Highlight counts one occurren...
-
Do not use a labeled return for the last statement in a lambda
Why you should care The return keyword is relative to the nearest enclosing function (or anonymous function). So for returning from lambda, a labeled return is needed. But as recommended by offici...
-
Boolean checks should not be inverted
Why you should care It is needlessly complex to invert the result of a boolean comparison. The opposite comparison should be made instead. This is furthermore the case in compound conditions. How ...
-
Avoid using multiple labeled returns in lambda expression
Why you should care The return keyword is relative to the nearest enclosing function (or anonymous function). So for returning from lambda, a labeled return is needed. But as recommended by offici...
-
Avoid generic catch
Why you should care You should not ignore exceptions. It can be tempting to be lazy when catching exceptions and do something like this: (see example below). Developers should avoid this. In almo...
-
Use Elvis operator to avoid unclear syntax pattern
Why you should care Elvis operator ?: is an syntactic sugar for if (!x) { x=something }. Prefer Elvis notation for readability considerations. How we detect CAST Highlight counts one occurrence e...
-
Avoid undefined type on data or routines declaration
Why you should care Groovy support dynamic types, that is declarations where the type is def or unspecified. How we detect CAST Highlight counts one occurrence each time a function, method, field...
-
Avoid to update static fields from instance methods
Why you should care 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 class instances and/or multiple threads in...