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-E1010

Avoid not-null assertions with `!!`KT-E1010

Major severityMajor
Bug Risk categoryBug Risk

Using the non-null assertion operator (!!) on a nullable value may throw a NullPointerException at runtime. When it is used, the compiler is forced to assume that the target value is non-null, and will thus allow operations that may throw NPEs.

Sometimes, it is possible for a value to definitely be non-null, even if the compiler does not think so. This can happen when you are working with mutable variables in single threaded code, where the compiler is unable to assume that a variable's value has not changed between any null checks and any subsequent accesses.

If you are absolutely sure that a variable will never be null at some point, consider adding a skipcq comment on the specified line, like below:

`something!! // skipcq: KT-E1010

Bad Practice

fun myFunction(str: String?) {
    println(str!!.length) // Bad!!
}

Use the safe call operator ?., the Elvis operator ?:, or conditional expressions to handle nullable values in a more controlled manner without risking runtime exceptions.

fun myFunction(str: String?) {
    println(str?.length)
}