Rule Description KPI url
ClassNaming Reports when class names which do not follow the specified naming convention are used.
CollapsibleIfStatements This rule detects if statements which can be collapsed. This can reduce nesting and help improve readability. However it should be carefully considered if merging the if statements actually does improve readability or if it hides some edge-cases from the reader. Understandability
CommentOverPrivateFunction This rule reports comments and documentation that has been added to private functions. These comments get reported because they probably explain the functionality of the private function. However private functions should be small enough and have an understandable name so that they are self-explanatory and do not need this comment in the first

Instead of simply removing this comment to solve this issue prefer to split up the function into smaller functions with better names if necessary. Giving the function a better, more descriptive name can also help in solving this issue.
CommentOverPrivateProperty This rule reports comments and documentation above private properties. This can indicate that the property has a confusing name or is not in a small enough context to be understood.
Private properties should be named in a self-explanatory way and readers of the code should be able to understand why the property exists and what purpose it solves without the comment.

Instead of simply removing the comment to solve this issue prefer renaming the property to a more self-explanatory name. If this property is inside a bigger class it could make senes to refactor and split up the class. This can increase readability and make the documentation obsolete.
ComplexCondition Complex conditions make it hard to understand which cases lead to the condition being true or false. To improve readability and understanding of complex conditions consider extracting them into well-named functions or variables and call those instead. Understandability
ComplexInterface Complex interfaces which contain too many functions and/or properties indicate that this interface is handling too many things at once. Interfaces should follow the single-responsibility principle to also encourage implementations of this interface to not handle too many things at once. Threshold for complex interface is 10. Large interfaces should be split into smaller interfaces which have a clear responsibility and are easier to understand and implement. Maintainability
ComplexMethod Complex methods are hard to understand and read. It might not be obvious what side-effects a complex method has. Prefer splitting up complex methods into smaller methods that are in turn easier to understand. Smaller methods can also be named much clearer which leads to improved readability of the code. Threadhold is 10 Maintainability
DataClassContainsFunctions This rule reports functions inside data classes which have not been whitelisted as a conversion function. Data classes should mainly be used to store data. This rule assumes that they should not contain any extra functions aside functions that help with converting objects from/to one another. Data classes will automatically have a generated equals, toString and hashCode function by the compiler.
DuplicateCaseInWhenExpression Flags duplicate case statements in when expressions. If a when expression contains the same case statement multiple times they should be merged. Otherwise it might be easy to miss one of the cases when reading the code, leading to unwanted side effects. Robustness
EmptyCatchBlock Reports empty catch blocks. Empty blocks of code serve no purpose and should be removed. Analyzability
EmptyClassBlock Reports empty classes. Empty blocks of code serve no purpose and should be removed. Maintainability
EmptyDefaultConstructor Reports empty default constructors. Empty blocks of code serve no purpose and should be removed. Maintainability
EmptyDoWhileBlock Reports empty do/while loops. Empty blocks of code serve no purpose and should be removed. Maintainability
EmptyElseBlock Reports empty else blocks. Empty blocks of code serve no purpose and should be removed. Maintainability
EmptyFinallyBlock Reports empty finally blocks. Empty blocks of code serve no purpose and should be removed. Maintainability
EmptyForBlock Reports empty for loops. Empty blocks of code serve no purpose and should be removed. Maintainability
EmptyFunctionBlock Reports empty functions. Empty blocks of code serve no purpose and should be removed. This rule will not report functions overriding others. Maintainability
EmptyIfBlock Reports empty if blocks. Empty blocks of code serve no purpose and should be removed. Maintainability
EmptyInitBlock Reports empty init expressions. Empty blocks of code serve no purpose and should be removed. Maintainability
EmptyKtFile Reports empty Kotlin (.kt) files. Empty blocks of code serve no purpose and should be removed. Maintainability
EmptySecondaryConstructor Reports empty secondary constructors. Empty blocks of code serve no purpose and should be removed. Maintainability
EmptyWhenBlock Reports empty when expressions. Empty blocks of code serve no purpose and should be removed. Maintainability
EmptyWhileBlock Reports empty while expressions. Empty blocks of code serve no purpose and should be removed. Maintainability
EndOfSentenceFormat This rule validates the end of the first sentence of a KDoc comment. It should end with proper punctuation or with a correct URL.
EnumNaming Reports when enum names which do not follow the specified naming convention are used.
EqualsAlwaysReturnsTrueOrFalse Reports equals() methods which will always return true or false. Equals methods should always report if some other object is equal to the current object. See the Kotlin documentation for Any.equals(other: Any?): Accuracy
EqualsNullCall To compare an object with null prefer using ==. This rule detects and reports instances in the code where the equals() method is used to compare a value with null. Robustness
EqualsWithHashCodeExist When a class overrides the equals() method it should also override the hashCode() method. All hash-based collections depend on objects meeting the equals-contract. Two equal objects must produce the same hashcode. When inheriting equals or hashcode, override the inherited and call the super method for Clarification. Accuracy
ExceptionRaisedInUnexpectedLocation This rule allows to define functions which should never throw an exception. If a function exists that does throw an exception it will be reported. By default this rule is checking for toString, hashCode, equals and finalize. This rule is configurable via the methodNames configuration to change the list of functions which should not throw any exceptions. Robustness
ExplicitGarbageCollectionCall Reports all calls to explicitly trigger the Garbage Collector. Code should work independently of the garbage collector and should not require the GC to be triggered in certain points in time. Resource Utilization
ExpressionBodySyntax Functions which only contain a return statement can be collapsed to an expression body. This shortens and cleans up the code.
ForbiddenClassName Reports class names which are forbidden per configuration. By default this rule does not report any classes. Examples for forbidden names might be too generic class names like …Manager.
ForbiddenComment This rule allows to set a list of comments which are forbidden in the codebase and should only be used during development. Offending code comments will then be reported.
ForbiddenImport This rule allows to set a list of forbidden imports. This can be used to discourage the use of unstable, experimental or deprecated APIs. Detekt will then report all imports that are forbidden.
ForEachOnRange Using the forEach method on ranges has a heavy performance cost. Prefer using simple for loops. Benchmarks have shown that using forEach on a range can have a huge performance cost in comparison to simple for loops. Hence in most contexts a simple for loop should be used instead. See more details here: To solve this CodeSmell, the forEach usage should be replaced by a for loop. Efficiency
FunctionMaxLength Reports when very long function names are used.
FunctionMinLength Reports when very short function names are used.
FunctionNaming Reports when function names which do not follow the specified naming convention are used.
FunctionOnlyReturningConstant A function that only returns a single constant can be misleading. Instead prefer to define the constant directly as a const val. Understandability
InvalidRange Reports ranges which are empty. This might be a bug if it is used for instance as a loop condition. This loop will never be triggered then. This might be due to invalid ranges like (10..9) which will cause the loop to never be entered. Robustness
IteratorNotThrowingNoSuchElementException Reports implementations of the Iterator interface which do not throw a NoSuchElementException in the implementation of the next() method. When there are no more elements to return an Iterator should throw a NoSuchElementException.


LabeledExpression This rule reports labeled expressions. Expressions with labels generally increase complexity and worsen the maintainability of the code. Refactor the violating code to not use labels instead. Understandability
LargeClass This rule reports large classes. Classes should generally have one responsibility. Large classes can indicate that the class does instead handle multiple responsibilities. Instead of doing many things at once prefer to split up large classes into smaller classes. These smaller classes are then easier to understand and handle less Things.
LateinitUsage Turn on this rule to flag usages of the lateinit modifier. Using lateinit for property initialization can be error prone and the actual initialization is not guaranteed. Try using constructor injection or delegation to initialize properties. Accuracy
LongMethod Methods should have one responsibility. Long methods can indicate that a method handles too many cases at once. Prefer smaller methods with clear names that describe their functionality clearly. Extract parts of the functionality of long methods into separate, smaller methods.
LongParameterList Reports functions which have more parameters than a certain threshold (default: 6).
LoopWithTooManyJumpStatements Loops which contain multiple break or continue statements are hard to read and understand. To increase readability they should be refactored into simpler loops.
MagicNumber This rule detects and reports usages of magic numbers in the code. Prefer defining constants with clear names describing what the magic number means.
MandatoryBracesIfStatements This rule detects multi-line if statements which do not have braces. Adding braces would improve readability and avoid possible errors.
MatchingDeclarationName If a Kotlin file contains a single non-private class (potentially with related top-level declarations), its name should be the same as the name of the class, with the .kt extension appended. If a file contains multiple classes, or only top-level declarations, choose a name describing what the file contains, and name the file accordingly. Use camel humps with an uppercase first letter (e.g. ProcessDeclarations.kt).

The name of the file should describe what the code in the file does. Therefore, you should avoid using meaningless words such as “Util” in file names.” – Official Kotlin Style Guide

More information at:
MaxLineLength This rule reports lines of code which exceed a defined maximum line length. Long lines might be hard to read on smaller screens or printouts. Additionally having a maximum line length in the codebase will help make the code more uniform.
MayBeConst This rule identifies and reports properties (val) that may be const val instead. Using const val can lead to better performance of the resulting bytecode as well as better interoperability with Java.
MemberNameEqualsClassName This rule reports a member that has the same as the containing class or object. This might result in confusion. The member should either be renamed or changed to a constructor. Factory functions that create an instance of the class are exempt from this rule.
MethodOverloading This rule reports methods which have many versions of the same method with different parameter overloading. Method overloading tightly couples these methods together which might make the code harder to understand.

Refactor these methods and try to use optional parameters instead to prevent some of the overloading.
ModifierOrder This rule reports cases in the code where modifiers are not in the correct order. The default modifier order is taken from:
NestedBlockDepth This rule reports excessive nesting depth in functions. Excessively nested code becomes harder to read and increases its hidden complexity. It might become harder to understand edge-cases of the function. Prefer extracting the nested code into well-named functions to make it easier to understand.
NewLineAtEndOfFile This rule reports files which do not end with a line separator.
NoTabs This rule reports if tabs are used in Kotlin files. According to Google’s Kotlin style guide the only whitespace chars that are allowed in a source file are the line terminator sequence and the ASCII horizontal space character (0x20).
NotImplementedDeclaration This rule reports all exceptions of the type NotImplementedError that are thrown. It also reports all TODO(..) functions. These indicate that functionality is still under development and will not work properly. Both of these should only serve as temporary declarations and should not be put into production environments.
ObjectPropertyNaming Reports when property names inside objects which do not follow the specified naming convention are used.
OptionalAbstractKeyword This rule reports abstract modifiers which are unnecessary and can be removed. Understandability
OptionalUnit It is not necessary to define a return type of Unit on functions. This rule detects and reports instances where the Unit return type is specified on functions. Maintainability
OptionalWhenBraces This rule reports unnecessary braces in when expressions. These optional braces should be removed.
PackageNaming Reports when package names which do not follow the specified naming convention are used.
PreferToOverPairSyntax This rule detects the usage of the Pair constructor to create pairs of values. Using to is preferred. Understandability
ProtectedMemberInFinalClass Kotlin classes are final by default. Thus classes which are not marked as open should not contain any protected members. Consider using private or internal modifiers instead. Understandability
RedundantVisibilityModifierRule This rule checks for redundant visibility modifiers.
ReturnCount Restrict the number of return methods allowed in methods. Having many exit points in a function can be confusing and impacts readability of the Code.
ReturnFromFinally Reports all return statements in finally blocks. Using return statements in finally blocks can discard and hide exceptions that are thrown in the try block. Robustness
SafeCast This rule inspects casts and reports casts which could be replaced with safe casts instead.
SerialVersionUIDInSerializableClass Classes which implement the Serializable interface should also correctly declare a serialVersionUID. This rule verifies that a serialVersionUID was correctly defined. Understandability
SpacingBetweenPackageAndImports This rule verifies spacing between package and import statements as well as between import statements and class Declarations.
StringLiteralDuplication This rule detects and reports duplicated String literals. Repeatedly typing out the same String literal across the codebase makes it harder to change and maintain. Instead, prefer extracting the String literal into a property or constant. Maintainability
ThrowingExceptionsWithoutMessageOrCause This rule reports all exceptions which are thrown without arguments or further description. Exceptions should always call one of the constructor overloads to provide a message or a cause. Exceptions should be meaningful and contain as much detail about the error case as possible. This will help to track down an underlying issue in a better way. Maintainability
ThrowingNewInstanceOfSameException Exceptions should not be wrapped inside the same exception type and then rethrown. Prefer wrapping exceptions in more meaningful exception types. Analyzability
ThrowsCount Functions should have clear throw statements. Functions with many throw statements can be harder to read and lead to confusion. Instead prefer to limit the amount of throw statements in a function.
TooGenericExceptionCaught This rule reports catch blocks for exceptions that have a type that is too generic. It should be preferred to catch specific exceptions to the case that is currently handled. If the scope of the caught exception is too broad it can lead to unintended exceptions being caught. Robustness
TooManyFunctions This rule reports files, classes, interfaces, objects and enums which contain too many functions. Each element can be configured with different thresholds. Too many functions indicate a violation of the single responsibility principle. Prefer extracting functionality which clearly belongs together in separate parts of the code.
TopLevelPropertyNaming Reports when top level constant names which do not follow the specified naming convention are used.
TrailingWhitespace This rule reports lines that end with a whitespace.
UnconditionalJumpStatementInLoop Reports loops which contain jump statements that jump regardless of any conditions. This implies that the loop is only executed once and thus could be rewritten without a loop altogether.
UndocumentedPublicClass This rule reports public classes, objects and interfaces which do not have the required documentation. Enable this rule if the codebase should have documentation on every public class, interface and object. By default this rule also searches for nested and inner classes and objects. This default behavior can be changed with the configuration options of this rule.
UndocumentedPublicFunction This rule will report any public function which does not have the required documentation.
If the codebase should have documentation on all public functions enable this rule to enforce this.
UnnecessaryAbstractClass This rule inspects abstract classes. In case an abstract class does not have any concrete members it should be refactored into an interfacse. Abstract classes which do not define any abstract members should instead be refactored into concrete classes. Understandability
UnnecessaryInheritance This rule reports unnecessary super types. Inheriting from Any or Object is unnecessary and should simply be removed. Maintainability
UnnecessaryParentheses This rule reports unnecessary parentheses around expressions. These unnecessary parentheses can safely be removed. Added in v1.0.0.RC4
UnnecessaryTemporaryInstantiation Avoid temporary objects when converting primitive types to String. This has a performance penalty when compared to using primitive types directly. To solve this issue, remove the wrapping type. Efficiency
UnsafeCallOnNullableType Reports unsafe calls on nullable types. These calls will throw a NullPointerException in case the nullable value is null. Kotlin provides many ways to work with nullable types to increase null safety. Guard the code appropriately to prevent NullPointerExceptions. Robustness
UnsafeCast Reports casts which are unsafe. In case the cast is not possible it will throw an exception. Robustness
UntilInsteadOfRangeTo Reports calls to ‘…’ operator instead of calls to ‘until’. ‘unti’ is applicable in cases where the upper range value is described as some value subtracted by 1. ‘until’ helps to prevent off-by-one errors.
UnusedImports This rule reports unused imports. Unused imports are dead code and should be removed.
UnusedPrivateMember Reports unused private properties, function parameters and functions. If private properties are unused they should be removed. Otherwise this dead code can lead to confusion and potential bugs.
UseDataClass Classes that simply hold data should be refactored into a data class. Data classes are specialized to hold data and generate hashCode, equals and toString implementations as well.

Read more about data class:
UselessPostfixExpression This rule reports postfix expressions (++, -) which are unused and thus unnecessary. This leads to confusion as a reader of the code might think the value will be incremented/decremented. However the value is replaced with the original value which might lead to bugs. Understandability
UtilityClassWithPublicConstructor A class which only contains utility functions and no concrete implementation can be refactored into an object.
VariableMaxLength Reports when very long variable names are used.
VariableMinLength Reports when very short variable names are used.
VariableNaming Reports when variable names which do not follow the specified naming convention are used.
WildcardImport Wildcard imports should be replaced with imports using fully qualified class names. This helps increase clarity of which classes are imported and helps prevent naming conflicts. Library updates can introduce naming clashes with your own classes which might result in compilation errors.
WrongEqualsTypeParameter Reports equals() methods which take in a wrongly typed parameter. Correct implementations of the equals() method should only take in a parameter of type Any?