IntelliJ IDEA 2017.3 Help

Code Inspection

Code analysis basics

IntelliJ IDEA features robust, fast, and flexible static code analysis. It detects the language and runtime errors, suggests corrections and improvements before you even compile.

IntelliJ IDEA performs code analysis by applying inspections to your code. Numerous code inspections exist for Java and for the other supported languages.

The inspections detect not only compiling errors, but also different code inefficiencies. Whenever you have some unreachable code, unused code, non-localized string, unresolved method, memory leaks or even spelling problems – you'll find it very quickly.

IntelliJ IDEA's code analysis is flexibly configurable. You can enable/disable each code inspection and change its severity, create profiles with custom sets of inspections, apply inspections differently in different scopes, suppress inspections in specific pieces of code, and more.

The analysis can be performed in several ways:

  • By default, IntelliJ IDEA analyses all open files and highlights all detected code issues right in the editor. On the right side of the editor you can see the analysis status of the whole file (the icon in the top-right corner).

    When an error is detected, this icon is fail; in case of a warning, it is warning; if everything is correct, the icon is ok.

  • Alternatively, you can run code analysis in a bulk mode for the specified scope, which can be as large as the whole project.
  • If necessary, you can apply a single code inspection in a specific scope.

For the majority of the detected code issues, IntelliJ IDEA provides quick fix suggestions. You can quickly review errors in a file by navigating from one highlighted line to another by pressing F2Shift+F2.

For more information and procedural descriptions, see Configuring Inspection Severities.

Inspection profiles

When you inspect your code, you can tell IntelliJ IDEA which types of problems you would like to search for and get reports about. Such configurations can be preserved as inspection profiles.

An inspection profile defines the types of problems to be sought for, i.e. which code inspections are enabled/disabled and the severity of these inspections. Profiles are configurable in the Inspections settings page.

To set the current inspection profile (the one that is used for the on-the-fly code analysis in the editor), simply select it in the Inspections settings page and apply changes. When you perform code analysis or execute a single inspection, you can specify which profile to use for each run.

Inspection profiles can be applicable for the entire IDE or for a specific project:

  • Project profiles are shared and accessible for the team members via VCS. They are stored in the project directory: <project>/.idea/inspectionProfiles.
  • IDE profiles are intended for personal use only and are stored locally in XML files under the USER_HOME/.<IntelliJ IDEA version>/config/inspection directory.

IntelliJ IDEA comes with the following pre-defined inspection profiles:

  • Default: This local (IDE level) profile is intended for personal use, applies to all projects, and is stored locally in the Default.xml file under the USER_HOME/.<IntelliJ IDEA version>/config/inspection directory.
  • Project Default: when a new project is created, the Project Default profile is copied from the settings of a template project. This profile is shared and applies to the current project.
    After a project is created, any modifications to the project default profile will pass unnoticed to any other projects.
    When the settings of the Project Default profile are modified in the Template Project settings, the changed profile will apply to all newly created projects, but the existing projects will not be affected as they already have a copy of this profile.
    Project Default profile is stored in the Project_Default.xml file located in the <project>/.idea/inspectionProfiles directory.

One can have as many inspection profiles as required. There are two ways of creating new profiles: you can add a new profile as a copy of the Project Default profile or copy the currently selected profile. The newly created profiles are stored in XML files, located depending on the type of the base profile.

The <profile_name>.xml files representing inspection profiles appear whenever some changes to the profiles are done and applied. The files only store differences against the default profile.

In case of the file-based project format, the shared profiles are stored in the project file <project name>.ipr.

Refer to the section Customizing Profiles for details.

Synchronizing profiles between computers

If an inspection profile is made project-specific, it is synchronized with your project automatically. Each user, who opens this project after checking it out, will have the same inspection profile enabled.

If an IDE Default inspection profile is used, it can be synchronized between multiple machines via the Settings Repository plugin, bundled with IntelliJ IDEA. So doing, the file is stored in USER_HOME/.<IntelliJ IDEA version>/config/inspection/<profile_name>.xml.

Note that the Global profile may have a different name. Copy your current project profile to the Global Level (click the button Manage and choose Copy as Global) and call it as you like.

Then, on the main menu, choose File | Other Settings | Default Settings and select this global profile as the default one for all the new projects. Now all the newly-created projects will use this global profile by default and this global profile will be synchronized between the various machines via the Settings Repository plugin.

Inspection severity

Inspection severity indicates how seriously the code issues detected by the inspection impact the project and determines how the detected issues should be highlighted in the editor. By default, each inspection has one of the following severity levels:

  • Server problem server problem
  • Typo typo
  • Info info
  • Weak Warning weak warning
  • Warning warning
  • Error error

You can increase or decrease the severity level of each inspection. That is, you can force IntelliJ IDEA to display some warnings as errors or weak warnings. In a similar way, what is initially considered a weak warning can be displayed as a warning or error, or just as info.

You can also configure the color and font style used to highlight each severity level. Besides, you can create custom severity levels and set them for specific inspections.

If necessary, you can set different severity levels for the same inspection in different scopes.

All modifications to inspections mentioned above are saved in the inspection profile currently selected in the inspection settings and apply when this profile is used.

Inspection scope

By default, all enabled code inspections apply to all project files. If necessary, you can configure each code inspection (enable/disable, change its severity level and options) individually for different scopes. Such configurations, like any other inspection settings, are saved and applied as part of a specific profile.

There may be complicated cases when an inspection has different configurations associated with different scopes. When such inspection is executed in a file belonging to some or all of these scopes, the settings of the highest priority scope-specific configuration are applied. The priorities are defined by the relative position of the inspection's scope-specific configuration in inspection settings: the uppermost configuration has the highest priority. The Everywhere else configuration always has the lowest priority.

For more information and procedural descriptions, see Configuring Inspection for Different Scopes.

Examples of code inspections

In the Inspections page, all inspections are grouped into categories. The most common tasks covered by code analysis are:

  • Finding probable bugs.
  • Locating dead code.
  • Detecting performance issues.
  • Improving code structure and maintainability.
  • Conforming to coding guidelines and standards.
  • Conforming to specifications.

Finding probable bugs

IntelliJ IDEA analyzes the code you are typing and is capable of finding probable bugs as non compilation errors right on-the-fly. Below are the examples of such situations.

For example, potential NPE can be thrown at runtime:


Here the first if condition may lead to a NullPointer exception being thrown in the second if, as not all situations are covered. At this point adding an assertion in order to avoid a NullPointer being thrown during the application runtime would be a good idea.


So, this is exactly what we get from the intention action.

Locating dead code

IntelliJ IDEA highlights in the editor pieces of so-called dead code. This is the code that is never executed during the application runtime. Perhaps, you don't even need this part of code in your project. Depending on situation, such code may be treated as a bug or as a redundancy. Anyway it decreases the application performance and complicates the maintenance process. Here is an example.

So-called constant conditions - conditions that are never met or are always true, for example. In this case the responsible code is not reachable and actually is a dead code.

code locating

IntelliJ IDEA highlights the if condition as it's always true. So the part of code surrounded with else is actually a dead code because it is never executed.

Highlighting unused declarations

IntelliJ IDEA is also able to instantly highlight Java classes, methods and fields which are unused across the entire project via Unused declarations inspection. All sorts of Java EE @Inject annotations, test code entry points and other implicit dependencies configured in the Unused declarations inspection are deeply respected.

Unresolved JavaScript function or method

This inspection detects references to undefined JavaScript functions or methods.

js unresolved function or method

Examples of PHP Code Inspections

  • Unresolved Include

    This inspection detects attempts to include not actually existing files and suggests two quick fixes: to create a file with the specified name or use a PHPDOC annotation.


  • Dynamic method is called as static

    This inspection checks whether a call to a static function is actually applied to a static function.


    The function do_something() is called as static while actually it is dynamic.

  • Unimplemented abstract method in class

    This inspection checks whether classes inherited from abstract superclasses are either explicitly declared as abstract or the functions inherited from the superclass are implemented.


    The class ConcreteClass is inherited from an abstract class AbstractClass and has not been explicitly declared as abstract. At the same time, the function GetValue(), which is inherited from AbstractClass, has not been implemented.

  • Parameter type

    PHP variables do not have types, therefore basically parameter types are not specified in definitions of functions. However, if the type of a parameter is defined explicitly, the function should be called with parameters of the appropriate type.

    parameter type inspection

    The function do_something has the parameter of the type integer but is called with a string.

  • Undefined class constant

    This inspection detects references to constants that are not actually defined in the specified class.

    undefined constant in class

    The constant NotExistingConst is referenced to as a constant of the class Animal, while actually it is not defined in this class.

  • Undefined constant inspection

    This inspection detects references to constants that are not actually defined anywhere within the inspection scope.

    undefined constant in scope

    The referenced constant UndefinedConst is not defined anywhere within the inspection scope.

  • Undefined class

    This inspection detects references to classes that are not actually defined anywhere within the inspection scope.

    undefined class

    The referenced class NotExistingClass is not defined.

  • Undefined field

    This inspection detects references to fields of a class that are not actually defined in this class.

    undefined field

    The $obj variable is an instance of the class Animal. The declaration of the $var contains a reference to the field field of the class Animal, which is not defined on this class.

    To suppress reporting Undefined method errors in such cases, re-configure the inspection severity. To do that, open the Inspections page of the Settings dialog box, click the inspection name in the list and select the Downgrade severity if __magic methods are present in class checkbox in the Options area. After that undefined properties in such cases will be indicated one step lower than specified for inspections in general, by default, Info instead of Warning.

    To suppress irrelevant reporting of Undefined field errors, clear the Notify about access to a field via magic method and Notify about PHP dynamic field declaration checkboxes. When the checkboxes are selected, IntelliJ IDEA reports errors even if the class contains the __get() and __set() magic methods.

  • Call of undefined function

    This inspection detects references to functions that are not defined anywhere within the inspection scope.


    The called function undefined_function() is not defined anywhere within the inspection scope.

  • Undefined variable

    This inspection detects references to variables that are not declared and initialized anywhere within the inspection scope. PHP does not require that each variable should be declared and initialized. PHP can initialize such variable on the fly and assign it the zero value. However, this inspection allows you to detect discrepancies of this kind.

    The Undefined variable inspection can be configured through the checkboxes on the Inspections page of the Settings dialog:
    • Enable inspection in global space: select this checkbox to run the inspection against variables outside functions/methods, classes, and namespaces, that is, in the global space.
    • Report that variable might have not been defined: select this checkbox to have a warning displayed even if the definition of a variable is not definitely missing. Such situation may take place when a variable is used in several paths and some of them may never be reached, for example, in if() statements:
    • Ignore 'include' and 'require' statements Suppose the inspection scope contains an include or require statement. If this checkbox is cleared, IntelliJ IDEA treats such variable as defined in the classes referenced through these statements and no error is reported. If this checkbox is selected, an Undefined variable error is reported.
Last modified: 12 December 2017

See Also