Loading...
Scope
<html>
<body>
Reports issues essential to this file (e.g., syntax errors) in the result of a batch code inspection run.
These issues are usually always highlighted in the editor and can't be configured, unlike inspections.
These options control the scope of checks performed by this inspection:
<ul>
<li>Option "<b>Report syntax errors</b>": report parser-related issues.</li>
<li>Option "<b>Report issues from language-specific annotators</b>": report issues found by annotators configured for the relevant language.
See <a href="https://plugins.jetbrains.com/docs/intellij/annotator.html">Custom Language Support: Annotators</a> for details.</li>
<li>Option "<b>Report other highlighting problems</b>": report issues specific to the language of the current file (e.g., type mismatches or unreported exceptions).
See <a href="https://plugins.jetbrains.com/docs/intellij/syntax-highlighting-and-error-highlighting.html#semantic-highlighting">Custom Language Support: Highlighting</a> for details.</li>
</ul>
<!-- tooltip end --></body>
</html>
Reports duplicated blocks of code from the selected scope: the same file, same module, dependent modules or the entire project.<!-- tooltip end --> <p>The inspection features quick-fixes that help you to set the size of detected duplicates, navigate to repetitive code fragments, and compare them in a tool window.When possible, the inspection provides a quick-fix to extract a method from the duplicated code.<p>The inspection options allow you to select the scope of the reported duplicated fragments and set the initial size for the duplicated language constructs.
<html>
<body>
Reports usages of the following elements that can be safely removed because the inspection they affect is no longer applicable in this context:
<ul>
<li><code>@SuppressWarning</code> annotation, or</li>
<li><code>// noinspection</code> line comment, or</li>
<li><code>/** noinspection */</code> JavaDoc comment</li>
</ul>
<p>Example:</p>
<pre><code lang="java">
public class C {
// symbol is already private,
// but annotation is still around
@SuppressWarnings({"WeakerAccess"})
private boolean CONST = true;
void f() {
CONST = false;
}
}
</code></pre>
<!-- tooltip end --></body>
</html>
<html>
<body>
<p>(Gradle 4.9+) Detects usage of API that interacts with tasks eagerly.</p>
<p>Eager interaction with tasks implies some inconveniences:</p>
<ul>
<li>The user should manually set up all dependencies between tasks;</li>
<li>In the <a href="https://docs.gradle.org/current/userguide/build_lifecycle.html#sec:build_phases">configuration phase</a>,
all the tasks accessed via the eager API become configured, even if they are not executed afterwards.
It results in performance degradation.
</li>
</ul>
<p>Eventually, the eager API will be deprecated in favor of the lazy one.</p>
<p>For a migration guide, see the
<a href="https://docs.gradle.org/current/userguide/task_configuration_avoidance.html">Gradle documentation</a>.</p>
<p><b>Example:</b></p>
<pre><code>task foo { // reports 'task', suggests replacing it with 'task.register'
// ...
}
</code></pre>
<!-- tooltip end --></body>
</html>
<html>
<body>
<p>Detects unused keys in TOML descriptors of version catalogs. </p>
<p><b>Example:</b></p>
<pre><code lang="groovy">
// build.gradle
dependencies {
implementation libs.foo.bar
}
</code></pre>
<pre><code lang="toml">
# libs.versions.toml
[libraries]
foo-bar = "com.gradle:example:1.0.0"
bar-baz = "com.gradle:example:2.0.0" # highlights bar-baz
</code></pre>
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports assignments with incompatible types.
<p>Such assignments might result in various runtime exceptions.</p>
<p><b>Example:</b></p>
<pre><code>
class A {}
class B {}
// incompatible assignment
A a = new B()
</code></pre>
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports assignments with incompatible types.
<p>Such assignments might result in various runtime exceptions.</p>
<p><b>Example:</b></p>
<pre><code>
class A {}
class B {}
// incompatible assignment
A a = new B()
</code></pre>
<!-- tooltip end --></body>
</html>
<html>
<body>
<p>Reports the cases where a variable is redundant as its value is never used after its assignment.</p>
<p>If the variable is unused, we recommend removing it to shorten the code and to avoid redundant allocations.</p>
<p>The following cases are reported:</p>
<ul>
<li>the variable never gets read after assignment</li>
<li>the value is always overwritten with another assignment before the next variable read</li>
<li>the variable initializer is redundant (for one of the above two reasons)</li>
</ul>
<!-- tooltip end -->
<p> For more info see the same inspection in Java.</p>
</body>
</html>
<html>
<body>
Reports methods which may safely be made <code>static</code>.
<p>
A method may be <code>static</code> if it is not <code>synchronized</code>,
it does not reference any of its class' instance methods and instance fields,
and it is not overridden in a subclass.
</p>
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports references to deprecated classes, fields, and methods.
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports files with a declared package that does not match the package expected. Also, reports files without <code>package</code> statements if the class is not located directly in
the source root directory.
<!-- tooltip end --></body>
</html>
<html>
<body>
<p>Reports reference expressions which cannot be resolved.</p>
<!-- tooltip end --></body>
</html>
<html>
<body>
<p>Reports unnecessary semicolons.</p>
<p><b>Example:</b></p>
<pre><code>
print 2; print 3 // semicolon is required
print 2; // semicolon is unnecessary
</code></pre>
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports an obsolete HTML5 attribute.
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports a missing <code>lang</code> (or <code>xml:lang</code>) attribute in a <code>html</code> tag. Suggests adding a required attribute to state the default language of the document. Based on WCAG 2.0: <a href="https://www.w3.org/TR/WCAG20-TECHS/H57.html">H57</a>.
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports redundant class fields that can be replaced with local variables.
<p>If all local usages of a field are preceded by assignments to that field, the
field can be removed, and its usages can be replaced with local variables.</p>
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports usages of deprecated classes, fields, and methods.
A quick-fix is available to automatically convert the deprecated usage,
when the necessary information can be extracted from the Javadoc of the deprecated member.
<p><b>Example:</b></p>
<pre><code lang="java">
class Interesting {
/**
* @deprecated Use {@link #newHotness()} instead
*/
@Deprecated
public void oldAndBusted() {}
public void newHotness() {}
}
class ElseWhere {
void x(Interesting i) {
i.oldAndBusted(); // deprecated warning here
}
}
</code></pre>
<p>After the quick-fix is applied:</p>
<pre><code lang="java">
class Interesting {
/**
* @deprecated Use {@link #newHotness()} instead
*/
@Deprecated
public void oldAndBusted() {}
public void newHotness() {}
}
class ElseWhere {
void x(Interesting i) {
i.newHotness();
}
}
</code></pre>
<p>By default, the inspection doesn't produce a warning if it's impossible or hard to avoid it. For example,
the following code won't be reported:</p>
<pre><code lang="java">
abstract class A { //library code
@Deprecated
abstract void m();
}
class B extends A { //project code
@Override
void m() {
//doSmth;
}
}
</code></pre>
<!-- tooltip end -->
<p>Configure the inspection:</p>
<p>
Use the options to disable this inspection inside deprecated members,
overrides of abstract deprecated methods, non-static import statements, methods of deprecated classes, or same top-level classes.
</p>
</body>
</html>
<html>
<body>
Reports fields that can be safely made <code>final</code>.
All <code>final</code> fields have a value and this value does not change, which can make the code easier to reason about.
<p>To avoid too expensive analysis, this inspection only reports if the field has a <code>private</code> modifier
or it is defined in a local or anonymous class.
A field can be <code>final</code> if:
<ul>
<li>It is <code>static</code> and initialized once in its declaration or in one <code>static</code> initializer.</li>
<li>It is non-<code>static</code> and initialized once in its declaration, in one instance initializer or in every constructor</li>
</ul>
And it is not modified anywhere else.
<p><b>Example:</b></p>
<pre><code>
public class Person {
private String name; // can be final
Person(String name) {
this.name = name;
}
public String getName() {
return name;
}
}
</code></pre>
<p>After the quick-fix is applied:</p>
<pre><code>
public class Person {
private final String name;
Person(String name) {
this.name = name;
}
public String getName() {
return name;
}
}
</code></pre>
<!-- tooltip end -->
<p>
Use the "Annotations" button to modify the list of annotations that assume implicit field write.
</p>
</body>
</html>
<html>
<body>
Reports empty class initializer blocks.
<!-- tooltip end -->
<p>
</body>
</html>
<html>
<body>
Reports methods and method hierarchies that always return the same constant.
<p>
The inspection works differently in batch-mode
(from <b>Code | Inspect Code</b> or <b>Code | Analyze Code | Run Inspection by Name</b>)
and on-the-fly in the editor:
<ul>
<li>In batch-mode, the inspection reports methods and method hierarchies that always
return the same constant.</li>
<li>In the editor, the inspection only reports methods that have more than one <code>return</code>
statement, do not have super methods, and cannot be overridden. If a method overrides or
implements a method, a contract may require it to return a specific constant, but at the
same time, we may want to have several exit points. If a method can be overridden, it is
possible that a different value will be returned in subclasses.
</li>
</ul>
<p><b>Example:</b></p>
<pre><code>
class X {
// Warn only in batch-mode:
int xxx() { // Method 'xxx()' and all its overriding methods always return '0'
return 0;
}
}
class Y extends X {
@Override
int xxx() {
return 0;
}
// Warn only in batch-mode:
int yyy() { // Method 'yyy()' always returns '0'
return 0;
}
// Warn both in batch-mode and on-the-fly:
final int zzz(boolean flag) { // Method 'zzz()' always returns '0'
if (Math.random() > 0.5) {
return 0;
}
return 0;
}
}
</code></pre>
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports method parameters that always have the same constant value.
<p>Example:</p>
<pre><code>
static void printPoint(int x, int y) { // x is always 0
System.out.println(x + ", " + y);
}
public static void main(String[] args) {
printPoint(0, 1);
printPoint(0, 2);
}
</code></pre>
<p>The quick-fix inlines the constant value. This may simplify the method implementation.</p>
<!-- tooltip end -->
<p>
Use the <b>Ignore when a quick-fix can not be provided</b> option to suppress the inspections when:
</p>
<ul>
<li>the parameter is modified inside the method</li>
<li>the parameter value that is being passed is a reference to an inaccessible field (Java ony)</li>
<li>the parameter is a vararg (Java only)</li>
</ul>
<p>
Use the <b>Maximal method visibility</b> option to control the maximum visibility of methods to be reported.
</p>
<p>
Use the <b>Minimal method usage count to report parameter</b> field to specify the minimal number of method usages with the same parameter value.
</p>
</body>
</html>
<html>
<body>
Reports dependencies on modules that are not used. The quick-fix safely removes such unused dependencies.
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports classes, methods, or fields that are not used or unreachable from the entry points.
<p> An entry point can be a main method, tests, classes from outside the specified scope, classes accessible from
<code>module-info.java</code>, and so on. It is possible to configure custom entry points by using name patterns or annotations.
</p>
<p><b>Example:</b></p>
<pre><code>
public class Department {
private Organization myOrganization;
}
</code></pre>
<p>In this example, <code>Department</code> explicitly references <code>Organization</code> but if <code>Department</code> class itself is unused, then inspection will report both classes. </p>
<p>
The inspection also reports parameters that are not used by their methods and all method implementations and overriders, as well as local
variables that are declared but not used.
</p>
<p>
<b>Note:</b> Some unused members may not be reported during in-editor code highlighting. For performance reasons, a non-private member is
checked only when its name rarely occurs in the project.
To see all results, run the inspection by selecting <b>Code | Inspect Code</b> or <b>Code | Analyze Code | Run Inspection by Name</b> from the main menu.
</p>
<!-- tooltip end -->
<p>Use the visibility settings below to configure members to be reported. For example, configuring report <code>private</code> methods only means
that <code>public</code> methods of <code>private</code> inner class will be reported but <code>protected</code> methods of top level class
will be ignored.</p>
<p>
Use the <b>entry points</b> tab to configure entry points to be considered during the inspection run.</p>
<p> You can add entry points manually when inspection results are ready.</p>
<p> If your code uses unsupported frameworks, there are several options:</p>
<ul>
<li>If the framework relies on annotations, use the <b>Annotations...</b> button to configure the framework's annotations.</li>
<li>If the framework doesn't rely on annotations, try to configure class name patterns that are expected by the framework.</li>
</ul>
<p>This way the annotated code accessible by the framework internals will be treated as used.</p>
</body>
</html>
<html>
<body>
Reports assignments of a variable to itself.
<p><b>Example:</b></p>
<pre><code>
a = a;
</code></pre>
<p>The quick-fix removes the assigment.</p>
<!-- tooltip end --></body>
</html>
<html><body>
Reports strings in method parameters and return values annotated with <code>@Nls</code> and having the capitalization parameter
to conform to capitalization rules existing in most platform UI guidelines.
<p><b>Example:</b></p>
<pre><code>
void setTitle(@NlsContexts.DialogTitle String title) {}
setTitle("This is sentence capitalization but should be title");
</code></pre>
<p>After the quick-fix is applied:</p>
<pre><code>
setTitle("This Is Sentence Capitalization but Should Be Title");
</code></pre>
<!-- tooltip end --></body></html>
<html>
<body>
Reports Java code constructs that may fail to compile in future Java versions.
<p>The following problems are reported:</p>
<ul>
<li>Uses of <code>assert</code>, <code>enum</code> or <code>_</code> as an identifier</li>
<li>Uses of the <code>var</code>, <code>yield</code>, or <code>record</code> restricted identifier as a type name</li>
<li>Unqualified calls to methods named <code>yield</code></li>
<li>Modifiers on the <code>requires java.base</code> statement inside of <code>module-info.java</code></li>
<li>Redundant semicolons between import statements</li>
</ul>
<p><b>Example:</b></p>
<pre><code>
// This previously legal class does not compile with Java 14,
// as 'yield' became a restricted identifier.
public class yield {}
</code></pre>
<p>Fixing these issues timely may simplify migration to future Java versions.</p>
<!-- tooltip end -->
</body>
</html>
<html>
<body>
Reports inner classes that can be made <code>static</code>.
<p>A <code>static</code> inner class does not keep an implicit reference to its enclosing instance.
This prevents a common cause of memory leaks and uses less memory per instance of the class.</p>
<p><b>Example:</b></p>
<pre><code>
<b>public class</b> Outer {
<b>class</b> Inner { // not static
<b>public void</b> foo() {
bar("x");
}
<b>private void</b> bar(String string) {}
}
}
</code></pre>
<p>After the quick-fix is applied:</p>
<pre><code>
<b>public class</b> Outer {
<b>static class</b> Inner {
<b>public void</b> foo() {
bar("x");
}
<b>private void</b> bar(String string) {}
}
}
</code></pre>
<!-- tooltip end -->
</body>
</html>
<html>
<body>
Reports instance initializers which may be made <code>static</code>.
<p>
An instance initializer may be static if it does not reference any of its class' non-static members.
Static initializers are executed once the class is resolved,
while instance initializers are executed on each instantiation of the class.</p>
<p>This inspection doesn't report instance empty initializers and initializers in anonymous classes.
<p><b>Example:</b></p>
<pre><code>
class A {
public static String CONSTANT;
{
CONSTANT = "Hello";
}
}
</code></pre>
<p>After the quick-fix is applied:</p>
<pre><code>
class A {
public static String CONSTANT;
static {
CONSTANT = "Hello"; //now initialized only once per class
}
}
</code></pre>
<!-- tooltip end -->
</body>
</html>
<html>
<body>
Reports expressions and conditions that always produce the same result, like true, false, null, or zero.
Such expressions could be replaced with the corresponding constant value. Very often though they signal about a bug
in the code.
<p>Examples:</p>
<pre><code> // always true
// root cause: || is used instead of &&
if (x > 0 || x < 10) {}
System.out.println(str.trim());
// always false
// root cause: variable was dereferenced before null-check
if (str == null) {}
</code></pre>
<p>
The inspection behavior may be controlled by a number of annotations, such as
<a href="https://www.jetbrains.com/help/idea/nullable-and-notnull-annotations.html">nullability</a> annotations,
<code><a href="https://www.jetbrains.com/help/idea/contract-annotations.html">@Contract</a></code> annotation,
<code>@Range</code> annotation and so on.
</p>
<!-- tooltip end -->
<p>Configure the inspection:</p>
<ul>
<li>Use the <b>Don't report assertions with condition statically proven to be always true</b> option to avoid reporting assertions that were
statically proven to be always true. This also includes conditions like <code>if (alwaysFalseCondition) throw new IllegalArgumentException();</code>.</li>
<li>Use the <b>Ignore assert statements</b> option to control how the inspection treats <code>assert</code> statements. By default, the option
is disabled, which means that the assertions are assumed to be executed (-ea mode). If the option is enabled, the assertions will be completely ignored
(-da mode).</li>
<li>Use the <b>Warn when constant is stored in variable</b> option to display warnings when variable is used, whose value is known to be a constant.</li>
</ul>
<p>
Before IntelliJ IDEA 2022.3, this inspection was part of "Constant Conditions & Exceptions" inspection. Now, it split into two inspections:
"Constant Values" and "Nullability and data flow problems".
</p>
</body>
</html>
<html>
<body>
Reports code constructs that always violate nullability contracts, may throw exceptions, or are just redundant, based on data flow analysis.
<p>Examples:</p>
<pre><code>if (array.length < index) {
System.out.println(array[index]);
} // Array index is always out of bounds
if (str == null) System.out.println("str is null");
System.out.println(str.trim());
// the last statement may throw an NPE
@NotNull
Integer square(@Nullable Integer input) {
// the method contract is violated
return input == null ? null : input * input;
}</code></pre>
<p>
The inspection behavior may be controlled by a number of annotations, such as
<a href="https://www.jetbrains.com/help/idea/nullable-and-notnull-annotations.html">nullability</a> annotations,
<code><a href="https://www.jetbrains.com/help/idea/contract-annotations.html">@Contract</a></code> annotation,
<code>@Range</code> annotation and so on.
</p>
<!-- tooltip end -->
<p>Configure the inspection:</p>
<ul>
<li>Use the <b>Suggest @Nullable annotation for methods/fields/parameters where nullable values are used</b> option to warn when a
nullable value is passed as an argument to a method with a non-annotated parameter,
stored into non-annotated field, or returned from a non-annotated method. In this case, the inspection will suggest propagating
the <code>@Nullable</code> annotation. You can also configure nullability annotations using the <b>Configure Annotations</b> button.</li>
<li>Use the <b>Treat non-annotated members and parameters as @Nullable</b> option to assume that non-annotated members can be null,
so they must not be used in non-null context.</li>
<li>Use the <b>Report not-null required parameter with null-literal argument usages</b> option to report method parameters that cannot be
null (e.g. immediately dereferenced in the method body), but there are call sites where a <code>null</code> literal is passed.</li>
<li>Use the <b>Report nullable methods that always return a non-null value</b> option to report methods that are annotated as
<code>@Nullable</code>, but always return non-null value. In this case, it's suggested that you change the annotation to <code>@NotNull</code>.</li>
<li>Use the <b>Ignore assert statements</b> option to control how the inspection treats <code>assert</code> statements. By default, the option
is disabled, which means that the assertions are assumed to be executed (-ea mode). If the option is enabled, the assertions will be completely ignored
(-da mode).</li>
<li>Use the <b>Report problems that happen only on some code paths</b> option to control whether to report problems that may happen only
on some code path. If this option is disabled, warnings like <i>exception is possible</i> will not be reported. The inspection will report
only warnings like <i>exception will definitely occur</i>. This mode may greatly reduce the number of false-positives, especially if the code
is not consistently annotated with nullability and contract annotations. That is why it can be useful for finding the most
important problems in legacy code bases.
</li>
</ul>
<p>
Before IntelliJ IDEA 2022.3, this inspection was part of the "Constant Conditions & Exceptions" inspection.
Now, it is split into two inspections:
"Constant Values" and "Nullability and data flow problems".
</p>
</body>
</html>
<html>
<body>
Reports the code which is never reached according to data flow analysis.
It can be the result of previous always-true or always-false condition, unreachable loop body or
catch section. Usually (though not always) unreachable code is a consequence of a previous warning,
so check inspection warnings form "Nullability and data flow problems", "Constant values", or
"Redundant operation on empty container" to better understand the cause.
<p>Example:</p>
<pre><code>
void finishApplication() {
System.exit(0);
System.out.println("Application is terminated"); // Unreachable code
}
</code></pre>
<!-- tooltip end --><p><small>New in 2024.1</small></p>
</body>
</html>
<html>
<body>
Detects <code>package</code> statements that do not correspond to the project directory structure.
Also, reports classes without <code>package</code> statements if the class is not located directly in
source root directory.
<p>While it's not strictly mandated by Java language, it's good practise to keep classes
from package <code>com.example.myapp</code> inside a <code>com/example/myapp</code> directory directly under
a source root. Failure to do this may confuse code readers and make some tools work incorrectly.</p>
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports the following discrepancies of a JSON file with <a href="https://tools.ietf.org/html/rfc7159">the language specification</a>:
<ul>
<li>A line or block comment (configurable).</li>
<li>Multiple top-level values (expect for JSON Lines files, configurable for others).</li>
<li>A trailing comma in an object or array (configurable).</li>
<li>A single quoted string.</li>
<li>A property key is a not a double quoted strings.</li>
<li>A NaN or Infinity/-Infinity numeric value as a floating point literal (configurable).</li>
</ul>
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports a duplicate key in an object literal.
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports JUnit annotated methods when used in a test case from a different JUnit version. To determine the framework version for a test case
the inspection checks the framework version of the super class when available. When a super class is not available it will use the most used
framework in the test case.
<p>Example (JUnit 4 annotation in JUnit 3 test case):</p>
<pre><code lang="java">
public class MyTest extends TestCase {
@Test
public void foo() { }
@Test
@Ignore
public void testBar() { }
}
</code></pre>
<p>After the quick-fix is applied:</p>
<pre><code lang="java">
public class MyTest extends TestCase {
public void testFoo() {}
public void _testBar() {}
}
</code></pre>
<p>Example (JUnit 5 annotation in JUnit 4 test case):</p>
<pre><code lang="java">
public class MyTest {
@BeforeAll // JUnit 5 lifecycle method
public void initialize() { }
@org.junit.Test // JUnit 4 test annotation
public void test() {}
@org.junit.Test // JUnit 4 test annotation
public void testWouldBeExecuted() {}
}
</code></pre>
<p>After the quick-fix is applied:</p>
<pre><code lang="java">
public class MyTest {
@BeforeClass // JUnit 4 lifecycle method
public void initialize() { }
@org.junit.Test // JUnit 4 test annotation
public void test() {}
@org.junit.Test // JUnit 4 test annotation
public void testWouldBeExecuted() {}
}
</code></pre>
<!-- tooltip end -->
</body>
</html>
<html>
<body>
Reports empty methods that can be removed.
<p>Methods are considered empty if they are empty themselves and if they are overridden or
implemented by empty methods only. Note that methods containing only comments and the <code>super()</code> call with own parameters are
also considered empty.</p>
<p>The inspection ignores methods with special annotations, for example, the <code>javax.ejb.Init</code> and <code>javax.ejb.Remove</code> EJB annotations .</p>
<p>The quick-fix safely removes unnecessary methods.</p>
<!-- tooltip end -->
<p>Configure the inspection:</p>
<ul>
<li>Use the <b>Comments and javadoc count as content</b> option to select whether methods with comments should be treated as non-empty.</li>
<li>Use the <b>Additional special annotations</b> option to configure additional annotations that should be ignored by this inspection.</li>
</ul>
</body>
</html>
<html>
<body>
Reports usages of an API marked with one of the annotations as unstable. Such an API may be changed or removed in future versions, breaking
the code that uses it.
<!-- tooltip end -->
<p>The annotations which are used to mark unstable APIs are shown in the list below.</p>
<p>By default, the inspection ignores usages of unstable APIs
if their declarations are located in sources of the same project. In such cases it'll be possible to update the usages when you change APIs.
However, it may be inconvenient if the project is big, so one can switch off the <b>Ignore API declared in this project</b> option to report
the usages of unstable APIs declared in both the project sources and libraries.
</p>
</body>
</html>
<html>
<body>
Reports <code>package</code> directives that do not match the location of the file.
<p>
When applying fixes, "Move refactoring" defaults are used to update usages of changed declarations, namely:
</p>
<ul>
<li>"Search in comments and strings"</li>
<li>"Search for text occurrences"</li>
</ul>
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports <code>const</code> property names that do not follow the recommended naming conventions.
<p>
Consistent naming allows for easier code reading and understanding.
According to the <a href="https://kotlinlang.org/docs/coding-conventions.html#property-names">Kotlin official style guide</a>,
<code>const</code> properties should use uppercase underscore-separated names.
</p>
<p><b>Example:</b></p>
<pre><code>
const val Planck: Double = 6.62607015E-34
</code></pre>
<p>The quick-fix renames the property:</p>
<pre><code>
const val PLANCK: Double = 6.62607015E-34
</code></pre>
<!-- tooltip end -->
</body>
</html>
<html>
<body>
Reports calls from Kotlin to <code>values()</code> method in enum classes that can be replaced with <code>entries</code> property read.
<p>
Use of <code>Enum.entries</code> may improve performance of your code.
</p>
<p>
The quick-fix replaces <code>values()</code> with <code>entries</code>.
</p>
<p>
<b>More details:</b> <a href="https://youtrack.jetbrains.com/issue/KT-48872">
KT-48872 Provide modern and performant replacement for Enum.values()</a>
</p>
<p>
<b>Note:</b> <code>entries</code> property type is different from the return type of <code>values()</code> method
(<code>EnumEntries<T></code> which inherits from <code>List<T></code> instead of <code>Array<T></code>).
Due to this in some cases quick fix inserts extra <code>.toTypedArray()</code> conversion to not break the code, but
for most common cases replacement will be done without it (e.g. in <code>for</code> loop).
</p>
<p><b>Example:</b></p>
<pre><code>
enum class Version {
V1, V2
}
Version.<b>values()</b>.forEach { /* .. */ }
val firstVersion = Version.<b>values()</b>[0]
functionExpectingArray(Version.<b>values()</b>)
</code></pre>
<p>After the quick-fix is applied:</p>
<pre><code>
enum class Version {
V1, V2
}
Version.<b>entries</b>.forEach { /* .. */ }
val firstVersion = Version.<b>entries</b>[0]
functionExpectingArray(Version.<b>entries.toTypedArray()</b>)
</code></pre>
<!-- tooltip end --></body>
</html>
<html>
<body>
<p>Reports <code>object</code> that can be converted to <code>data object</code></p>
<p><code>data object</code> auto-generates <code>toString</code>, <code>equals</code> and <code>hashCode</code></p>
<p>The inspection suggests to convert <code>object</code> to <code>data object</code> in 2 cases:</p>
<ul>
<li>When custom <code>toString</code> returns name of the class</li>
<li>When <code>object</code> inherits sealed <code>class</code>/<code>interface</code></li>
</ul>
<p><b>Example:</b></p>
<pre><code>
object Foo {
override fun toString(): String = "Foo"
}
</code></pre>
<p>After the quick-fix is applied:</p>
<pre><code>
data object Foo
</code></pre>
<!-- tooltip end -->
<p>This inspection only reports if the Kotlin language level of the project or module is 1.9 or higher</p>
</body>
</html>
<html>
<body>
<p>
Reports <code>object</code>s (<code>data object</code> including) that implement <code>java.io.Serializable</code> but don't implement
<a href="https://docs.oracle.com/en/java/javase/11/docs/specs/serialization/input.html#the-readresolve-method">readResolve</a>
</p>
<p><b>Example:</b></p>
<pre><code>
import java.io.Serializable
object Foo : Serializable
</code></pre>
<p>The quick fix implements <code>readResolve</code> method:</p>
<pre><code>
import java.io.Serializable
object Foo : Serializable {
private fun readResolve() = Foo
}
</code></pre>
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports unresolved references in KDoc comments.
<p><b>Example:</b></p>
<pre><code>
/**
* [unresolvedLink]
*/
fun foo() {}
</code></pre>
<p>To fix the problem make the link valid.</p>
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports calls on not-null receiver that make sense only for nullable receiver.
<p>Several functions from the standard library such as <code>orEmpty()</code> or <code>isNullOrEmpty</code>
have sense only when they are called on receivers of nullable types. Otherwise, they can be omitted or simplified as the result will be the same.</p>
<p><b>Remove redundant call</b> and <b>Change call to …</b> quick-fixes can be used to amend the code automatically.</p>
<p>Examples:</p>
<pre><code>
fun test(s: String) {
val x = s.orEmpty() // quick-fix simplifies to 's'
val y = s.isNullOrEmpty() // quick-fix simplifies to 's.isEmpty()'
}
</code></pre>
<!-- tooltip end --></body>
</html>
<html>
<body>
<p>Reports <code>if</code> statements which can be simplified to a single statement.</p>
<p><b>Example:</b></p>
<pre><code>
fun test(): Boolean {
if (foo()) {
return true
} else {
return false
}
}
</code></pre>
<p>After the quick-fix is applied:</p>
<pre><code>
fun test(): Boolean {
return foo()
}
</code></pre>
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports a redundant <code>Unit</code> return type which can be omitted.
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports usages of <code>@Suppress</code> annotations that can be safely removed because the compiler diagnostic they affect is no longer applicable in this context.
<p><b>Example:</b></p>
<pre><code>
fun doSmth(@Suppress("UNUSED_PARAMETER") used: Int) {
println(used)
}
</code></pre>
<p>After the quick-fix is applied:</p>
<pre><code>
fun doSmth(used: Int) {
println(used)
}
</code></pre>
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports functions and variables with nullable return type which never return or become <code>null</code>.
<p><b>Example:</b></p>
<pre><code>
fun greeting(user: String): String? = "Hello, $user!"
</code></pre>
<p>After the quick-fix is applied:</p>
<pre><code>
fun greeting(user: String): String = "Hello, $user!"
</code></pre>
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports redundant qualifiers (or their parts) on class names, functions, and properties.
<p>
A fully qualified name is an unambiguous identifier that specifies which object, function, or property a call refers to.
In the contexts where the name can be shortened, the inspection informs on the opportunity and the associated
'Remove redundant qualifier name' quick-fix allows amending the code.
</p>
<p><b>Examples:</b></p>
<pre><code>
package my.simple.name
import kotlin.Int.Companion.MAX_VALUE
class Foo
fun main() {
val a = my.simple.name.Foo() // 'Foo' resides in the declared 'my.simple.name' package, qualifier is redundant
val b = kotlin.Int.MAX_VALUE // Can be replaced with 'MAX_VALUE' since it's imported
val c = kotlin.Double.MAX_VALUE // Can be replaced with 'Double.MAX_VALUE' since built-in types are imported automatically
}
</code></pre>
<p>After the quick-fix is applied:</p>
<pre><code>
package my.simple.name
import kotlin.Int.Companion.MAX_VALUE
class Foo
fun main() {
val a = Foo()
val b = MAX_VALUE
val c = Double.MAX_VALUE
}
</code></pre>
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports SAM (Single Abstract Method) constructor usages which can be replaced with lambdas.
<p><b>Example:</b></p>
<pre><code>
fun main() {
foo(<b>Runnable</b> { println("Hi!") })
}
fun foo(other: Runnable) {}
</code></pre>
<p>After the quick-fix is applied:</p>
<pre><code>
fun main() {
foo( { println("Hi!") })
}
fun foo(other: Runnable) {}
</code></pre>
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports visibility modifiers that match the default visibility of an element
(<code>public</code> for most elements, <code>protected</code> for members that override a protected member).
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports redundant <code>import</code> statements.
<p>Default and unused imports can be safely removed.</p>
<p><b>Example:</b></p>
<pre><code>
import kotlin.*
import kotlin.collections.*
import kotlin.comparisons.*
import kotlin.io.*
import kotlin.ranges.*
import kotlin.sequences.*
import kotlin.text.*
// jvm specific
import java.lang.*
import kotlin.jvm.*
// js specific
import kotlin.js.*
import java.io.* // this import is unused and could be removed
import java.util.*
fun foo(list: ArrayList<String>) {
list.add("")
}
</code></pre>
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports symbols that are not used or not reachable from entry points.
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports call arguments with <code>Boolean</code> type without explicit parameter names specified.
<p>
When multiple boolean literals are passed sequentially, it's easy to forget parameter ordering that could lead to mistakes.
Explicit parameter names allow for easier code reading and understanding.
</p>
<p><b>Example:</b></p>
<pre><code>
fun check(checkName: Boolean, checkAddress: Boolean, checkPhone: Boolean) {}
fun usage() {
check(true, false, true) // What does this mean?
}
</code></pre>
<p>The quick-fix adds missing parameter names:</p>
<pre><code>
fun check(checkName: Boolean, checkAddress: Boolean, checkPhone: Boolean) {}
fun usage() {
check(checkName = true, checkAddress = false, checkPhone = true)
}
</code></pre>
<!-- tooltip end -->
</body>
</html>
<html>
<body>
Reports declarations that can be made <code>private</code> to follow the encapsulation principle.
<p><b>Example:</b></p>
<pre><code>
class Service(val url: String) {
fun connect(): URLConnection = URL(url).openConnection()
}
</code></pre>
<p>After the quick-fix is applied (considering there are no usages of <code>url</code> outside of <code>Service</code> class):</p>
<pre><code>
class Service(private val url: String) {
fun connect(): URLConnection = URL(url).openConnection()
}
</code></pre>
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports explicit calls to <code>get</code> or <code>set</code> functions which can be replaced by an indexing operator <code>[]</code>.
<p>
Kotlin allows custom implementations for the predefined set of operators on types.
To overload an operator, you can mark the corresponding function with the <code>operator</code> modifier:
<pre><code>
operator fun get(index: Int) {}
operator fun set(index: Int, value: Int) {}
</code></pre>
The functions above correspond to the indexing operator.
<p><b>Example:</b></p>
<pre><code> class Test {
operator fun get(i: Int): Int = 0
}
fun test() {
Test().get(0) // replaceable 'get()'
}
</code></pre>
<p>After the quick-fix is applied:</p>
<pre><code> class Test {
operator fun get(i: Int): Int = 0
}
fun test() {
Test()[0]
}
</code></pre>
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports property declarations that can be joined with the following assignment.
<p><b>Example:</b></p>
<pre><code>
val x: String
x = System.getProperty("")
</code></pre>
<p>The quick fix joins the declaration with the assignment:</p>
<pre><code>
val x = System.getProperty("")
</code></pre>
<!-- tooltip end -->
<p>Configure the inspection:</p>
<p>You can disable the option <b>Report with complex initialization of member properties</b> to skip properties with complex initialization. This covers two cases:</p>
<ol>
<li>The property initializer is complex (it is a multiline or a compound/control-flow expression)</li>
<li>The property is first initialized and then immediately used in subsequent code (for example, to call additional initialization methods)</li>
</ol>
</body>
</html>
<html>
<body>
Reports trailing commas that do not follow the recommended <a href="https://kotlinlang.org/docs/coding-conventions.html#trailing-commas">style guide</a>.
<!-- tooltip end --></body>
</html>
<html>
<body>
<p>Reports resolution problems in a Maven model</p>
<!-- tooltip end --></body>
</html>
<html lang="en"><body>
Reports grammar mistakes in your text. You can configure the inspection in
<a href="settings://reference.settingsdialog.project.grazie">Settings | Editor | Natural Languages | Grammar</a>.
<!-- tooltip end --></body></html>
<html><body>Reports typos and misspellings in your code, comments, and literals and fixes them with one click.<!-- tooltip end --></body></html>
<html>
<body>
Reports problems in the properties files contained in the resource bundle.
<ul>
<li><b>Report missing translations</b> <br><br>
Use this option to report properties contained in the parent properties file that are missing in inherited ones (unless it's a language dialect).
<br><br> <p>Example:</p>
<pre><code>
# messages.properties
abc=xxx
# messages_fr.properties
# Empty file
</code></pre>
Property <code>abc</code> will be reported as untranslated.
<br><br><br> </li>
<li><b>Report inconsistent properties</b> <br><br>
Use this option to report properties contained in inherited properties file that are missing in the parent one (or in siblings if there is no parent).
<br><br> <p>Example:</p>
<pre><code>
# messages.properties
# Empty file
# messages_fr.properties
abc=xxx
</code></pre>
Property <code>abc</code> translation is not available here for any language except French,
and, thus, will be reported as missing in the (default) properties file <code>messages.properties</code>.
<br><br><br> </li>
<li><b>Report properties overridden with the same value</b> <br><br>
Use this option to report properties copy-pasted into several properties files verbatim. <br>
<br><br> <p>Example:</p>
<pre><code>
# messages.properties
abc=xxx
# messages_fr.properties
abc=xxx
</code></pre>
Property <code>abc</code> will be reported as unnecessarily inherited in the file <code>messages_fr.properties</code> .
<br><br><br> </li>
<li><b>Report properties overridden with different placeholders</b> <br><br>
Use this option to check for placeholder consistency in overridden properties.
<br><br> <p>Example:</p>
<pre><code>
# messages.properties
qwe={0}xxx{1}
abc={0}yyy{1}
# messages_fr.properties
qwe={0}xxx{0}xxx{1}
abc={0}yyy
</code></pre>
Property <code>abc</code> will be reported as a property containing message format placeholders
not corresponding to <code>messages.properties</code>.
<br><br><br> </li>
<li><b>Report properties overridden with different values endings</b> <br><br>
Use this option to check for ending consistency in overridden properties.
<br><br> <p>Example:</p>
<pre><code>
# messages.properties
abc=xxxzzz
# messages_fr.properties
abc=xxx;
</code></pre>
Property <code>abc</code> will be reported as ending with special signs
(<code>!</code> / <code>?</code> / <code>.</code> / <code>:</code> / <code>;</code>) whereas
the parent value in <code>messages.properties</code> doesn't.
</li>
</ul>
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports properties whose keys or values end with a whitespace.
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports properties that are not referenced outside of the .properties file they are contained in.
<!-- tooltip end --></body>
</html>
<html>
<body>
<p>Reports the links that use unencrypted protocols (such as HTTP), which can expose your data to man-in-the-middle attacks. These attacks
are dangerous in general and may be especially harmful for artifact repositories. Use protocols with encryption, such as HTTPS,
instead.</p>
<p>See <a href="https://en.wikipedia.org/wiki/HTTPS#Difference_from_HTTP">HTTPS: Difference from HTTP (wikipedia.org)</a>.</p>
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports any instances of hardcoded strings in your UI forms.
<p>Hardcoded string literals are usually errors in
an internationalized environment.
This inspection does not report empty strings and strings consisting of only whitespace.</p>
<p>The quick-fix transforms a string literal
into a reference to a property in a resource bundle.</p>
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports focusable components with the
<code>text</code> property or labels with the assigned
<code>labelFor</code> property that do not have a mnemonic
character. The quick-fix assigns a unique mnemonic to such a component.
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports components that do not have any static
text and do not have any label marked with <code>setLabelFor</code>
for this component.
<p>Components that do not have static text include edit fields and combo boxes.
Such components cannot be activated with a keyboard shortcut. The quick-fix for this inspection
allows you to automatically associate an adjacent label with the problematic component.</p>
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports
<code>Scrollable</code> components,
except for <code>JTextField</code>, that are not placed in
<code>JScrollPane</code>. The quick-fix surrounds the problematic
component with a scroll pane.
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports if Velocity file references in <code>#include</code> and <code>#parse</code> directives are resolved incorrectly.
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports if Velocity references are resolved incorrectly.
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports XML elements without contents.
<p><b>Example:</b></p>
<pre><code>
<user>
<name></name>
</user>
</code></pre>
<p>After the quick-fix is applied:</p>
<pre><code>
<user>
<name/>
</user>
</code></pre>
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports an unused namespace declaration or location hint in XML.
<!-- tooltip end --></body>
</html>
<html>
<body>
Reports XML validation problems in the results of a batch code inspection.
<!-- tooltip end --></body>
</html>
Build was successful
Build agent: teamcity_teamcity-agent-2_1
Build agent: teamcity_teamcity-agent-2_1