Skip to content

Code style rules — missing

Andrey Shcheglov edited this page Jul 5, 2022 · 1 revision
  1. Concatenation of Strings instead of Kotlin strings (added)

  2. need to put a space after and before braces { x -> x } (kumar to check) alreay exists in WhitespaceRule

  3. creating methods for getters and setters in cases where properties would be more appropriate - is a bad style implemented in chapter 6

  4. rules for labeling https://kotlinlang.org/docs/reference/returns.html #697

  5. data classes - suggest to use them (added)

  6. Chapter 5: need to add rules related to goto: https://kotlinlang.org/docs/reference/returns.html #697

  7. Do not use !isEmpty - use isNotEmpty instead #692

  8. try not to use nested and inner classes in your code - WHY NOT??? At least because of this stuff: https://kotlinlang.org/docs/reference/classes.html#calling-the-superclass-implementation

  9. Avoid if-null Checks implemented as AVOID_NULL_CHECKS

  10. use inline classes (https://kotlinlang.org/docs/reference/inline-classes.html) #698

  11. Companion objects and interfaces. https://stackoverflow.com/questions/35327443/companion-objects-in-kotlin-interfaces Usage in interfaces and implementing interfaces. (What exactly can be checked here? Should we forbid companion objects in interfaces?)

  12. Shadowing: Static analysis in Idea does not treat companion object and init blocks as shadowing

class BB(var a: String) { // parameters[3]
    init {
        var a = 0 // properties[1]
        a = 5
    }

    companion object {
        var a = 0 // properties[2]
    }

    fun foo(a: Int) { // parameters[4]
        val a = 1 // properties[3]
    }
}
  1. Check Java Optional used in Kotlin: if Optional is used - then need to have proper construction with Kotlin: like Optional.orElse(null) ?: {} or Optional.orElse(null)?.let {}

  2. there is difference between .let and .also - static analyzer should check that the proper method is used. For example, if simple "print" is used - then no need for using also - should use let. https://kotlinlang.org/docs/reference/scope-functions.html - can be used as reference for describing the rule. (can't be done without type resolution? if returned value is unused, can be also, otherwise - let?)

  3. missing rules about ===

  4. missing rules about !(a == 5) - it should be replaced with a != 5

  5. Long lambdas should have a parameter name instead of it #695

  6. (not sure) Avoid using Boolean variable names with negative meaning: isNotError, conflicts with 7. Need to decide

  7. long x = y = 5 + 5; assignment in assignment (WTF, this is Java, this code doesn't compile in kotlin. var x = 2; val y = x = 2 + 2 doesn't compile too)

  8. simplification of logical conditions (general form of 17)

  9. nested scope functions with receiver (run, with, apply) and this resolution - kotlin lets implicitly access outer this if there is no name clash, but it reduces readability

  10. allow return from first quarter (preconditions) or last quarter (return values) of function

  11. IMPORTANT: check for assignment in if statements! (same as 20 - kotlin says assignments are not expressions and only expressions are allowed in this context?)

25) Unused imports: if imports is w/o * we can search for imported names in code. #710

  1. What's with Kotlin JS?

  2. What's with Kotlin Script