Unreachable code can be safely removedKT-W1065The property can be declared as `const`KT-P1001Iterator implementation does not throw `NoSuchElementException`KT-W1033Unreachable catch blocks must be removedKT-W1064Avoid using `forEach` with rangesKT-P1000Non-compliant class/object name detectedKT-C1000Checked cast can be replaced with a safe castKT-E1004Catch block should not require to check or cast the type of exception via `is` or `as`KT-W1000The range specified for iteration is emptyKT-W1031Calling `hasNext()` on an `Iterator` should not have any side-effectsKT-W1032Declaration of `serialVersionUID` not foundKT-W1060The class overrides `equals` but not `hashCode`KT-W1028`null` comparison using `equals` methodKT-W1049Map values fetched with not-null assertion operatorKT-W1034Non-compliant enum variant name detectedKT-C1001Exceptions should not be rethrown after being wrapped in a new instance of the same typeKT-W1008Avoid explicitly triggering garbage collectionKT-W1029Avoid using `GlobalScope` to launch coroutinesKT-E1001Avoid casting to nullable types using `as`KT-E1002`equals` should be overridden correctlyKT-E1003Proper logging should be preferred over printing stack trace of exceptionsKT-W1002Caught exceptions must not be rethrownKT-W1003Ensure exceptions that are caught are actually handledKT-W1005Avoid catching overly generic exceptionsKT-W1009`equals` method always returns the same resultKT-W1027Loop with unconditional jump statementsKT-W1035File location does not match the declared packageKT-W1044Found shadowed variable declarationKT-W1045Found usages of `lateinit` modifierKT-W1047Method should not throw exceptionsKT-W1056Don't throw `IllegalArgumentException` manually, use `require()` insteadKT-W1057The class can be declared as a data classKT-W1058Unused parameters should be removedKT-W1061Avoid casting nullable types to non-null typesKT-E1006Avoid casting immutable collection types to mutable collection typesKT-E1007Avoid not-null assertions with `!!`KT-E1010Inner class can be a static nested classKT-R1001Variables that can be non-nullable should not be marked as nullableKT-W1070Found type cast that will never succeedKT-E1011Blocking operations should be avoided in coroutinesKT-E1012Redundant `filter()` calls should be removedKT-W1073Abstract class should be refactored into either an interface or concrete classKT-R1000Avoid suspend function calls in `runCatching`KT-W1066Function must not return from a `finally` blockKT-W1069Prefer usage of `Unit` over `Void`KT-W1071Redundant `map()` calls should be removedKT-W1072Extensive `let` usage should be replaced with ordinary method or extension function callKT-W1074Functions with only the `return` statement should be rewritten with expression body syntaxKT-W1051Found `if` statements that can be collapsed into oneKT-W1048Unnecessary `abstract` modifier in interface detectedKT-W1054Found function that only returns a constantKT-W1052Redundant use of `?.` detectedKT-W1063Found duplicate condition in binary expressionKT-W1043Detected member with `protected` visibility in `final` classKT-W1055Multiple occurrences of the same string literal within a single file detectedKT-W1042Declaring lambda parameters as `it` is redundantKT-W1050Array literals must be used instead of `arrayOf()`KT-W1059Return values must not be ignoredKT-E1008Explicit `public` modifiers on nested classes have no effectKT-W1053Redundant use of `!!` detectedKT-W1062Avoid referential equality test for stringsKT-E1005Prefer `to` over `Pair` syntaxKT-C1002`toString()` must not be called on a nullable objectKT-E1009Detected `?: emptyList()` that can be replaced with `orEmpty()` callKT-R1004Detected `require` calls for not-null check that can be replaced with `requireNotNull`KT-R1005Functions that return a Flow instance should not be marked as `suspend`KT-W1068Detected `isEmpty` or `isBlank` calls to assign a default valueKT-R1002Detected null or empty check that can be replaced with `isNullOrEmpty()`KT-R1003Functions that have `CoroutineScope` as receiver should not be marked as `suspend`KT-W1067Ensure all APIs are implementedKT-W1001Avoid throwing exceptions within `finally` blocksKT-W1010Method should not return from finally blocksKT-W1004The main method should not throw exceptionsKT-W1007The result of increment/decrement operation is unusedKT-W1036Array constructors should be preferred over the spread operatorKT-P1004Creation of temporary objects when converting primitive types to `String`KT-P1002Detected the use of forbidden commentsKT-D1000Having empty blocks in the code is redundantKT-W1012Implicit default locale used for string processingKT-W1030Function with cyclomatic complexity higher than threshold foundKT-R1006Specialized primitive array classes should be preferred over `Array<Primitive>`KT-P1003
Kotlin logoKotlin/
KT-W1045

Found shadowed variable declarationKT-W1045

Major severityMajor
Anti-pattern categoryAnti-pattern

Name shadowing in software development is considered bad practice in programming. Firstly, it hampers readability and understandability of the code, as it introduces ambiguity and confusion. When a variable or identifier is shadowed, it becomes unclear which one is being referenced, especially in nested scopes or complex code.

Secondly, name shadowing can lead to maintenance and debugging difficulties. Unintentional or undocumented shadowing can cause unexpected behavior or incorrect results. Identifying and fixing such issues becomes challenging, as the code may appear correct but is affected by hidden shadowed variables.

To write clean and maintainable code, it is advisable to avoid name shadowing. Choosing distinct and descriptive names for variables and identifiers, along with proper scoping, enhances code readability, reduces bugs, and facilitates easier maintenance and debugging.

Bad Practice

// Parameters to the function `test` are named `i`, `j`, and `k`.
// But these names are used again in the body of the function for other variables.
fun test(i: Int, j: Int, k: Int) {
    val i = 1
    val (j, _) = 1 to 2
    listOf(1).map { k -> println(k) }
    listOf(1).forEach {
        listOf(2).forEach {
        }
    }
}

Rename variables that shadow other variables.

fun test(i: Int, j: Int, k: Int) {
    val x = 1
    val (y, _) = 1 to 2
    listOf(1).map { z -> println(z) }
    listOf(1).forEach {
        listOf(2).forEach { x ->
        }
    }
}

References