Intellij Code Inspections

0 views

Skip to first unread message

Jesper Sahu

unread,

Aug 3, 2024, 5:54:18 PM8/3/24

to rrorexratinc

The IntelliJ Platform provides tools designed for static code analysis called code inspections, which help the user maintain and clean up code without actually executing it.Custom code inspections can be implemented as IntelliJ Platform plugins.Examples of the plugin approach are the IntelliJ Platform SDK code samples inspection_basics and comparing_references_inspection.In addition, the comparing_references_inspection code sample demonstrates implementing a unit test.

The comparing_references_inspection code sample adds a new inspection to the Java Probable Bugs group in the Inspections list.The inspection reports when the == or != operator is used between Java expressions of reference types.
It illustrates the components for a custom inspection plugin:

Although the IntelliJ Platform SDK code samples illustrate implementations of these components, it is often useful to see examples of inspections implemented in the intellij_community code base.This process can help find inspection descriptions and implementations based on what is visible in the IDE UI.The overall approach works for inspections aimed at other languages as well.

The comparing_references_inspection is described as a type within the elements in the comparing_references_inspection plugin configuration (plugin.xml) file.Under the hood, inspection types are described as an in LangExtensionPoints.xml:

The minimum inspection description must contain the implementationClass attribute.As shown in the comparing_references_inspection plugin configuration file, other attributes can be defined in the localInspection element, either with or without localization. In most cases, it is simplest to define the attributes in the plugin configuration file because the underlying parent classes handle most of the class responsibilities based on the configuration file description.Note that some attributes are not displayed to the user, so they are never localized.

Inspection implementations for Java files, like ComparingReferencesInspection, are often based on the Java class AbstractBaseJavaLocalInspectionTool.The AbstractBaseJavaLocalInspectionTool implementation class offers methods to inspect Java classes, fields, and methods.

More generally, localInspection types are based on the class LocalInspectionTool.Examining the class hierarchy for LocalInspectionTool shows that the IntelliJ Platform provides many child inspection classes for a variety of languages and frameworks.One of these classes is a good basis for a new inspection implementation, but a bespoke implementation can also be based directly on LocalInspectionTool.

The ComparingReferencesInspection.createOptionsPanel() method creates an anonymous visitor class based on JavaElementVisitor to traverse the PsiTree of the Java file being edited, inspecting for suspect syntax.The anonymous class overrides three methods in particular.

The quick fix class acts much like an intention, allowing the user to change the portion of PsiTree highlighted by the inspection.A quick fix is invoked when the inspection highlights a PsiElement of interest and the user elects to make a change.

The ComparingReferencesInspection implementation uses the nested class CriQuickFix to implement a quick fix based on LocalQuickFix.The CriQuickFix class gives a user the option to change the use of a == b and a != b expression to a.equals(b) and !a.equals(b) respectively.

The panel created by ComparingReferencesInspection.createOptionsPanel() just defines a single JTextField to display in a JPanel.This JPanel gets added to the default IntelliJ Platform Inspections Preferences dialog when the comparing_references_inspection short name is selected.The JTextField allows editing of the CHECKED_CLASSES field while displayed in the panel.

Note that the IntelliJ Platform provides most of the UI displayed in the Inspections Preferences panel.As long as the inspection attributes and inspection description are defined correctly, the IntelliJ Platform displays the information in the Inspections Preferences UI.

The plugin inspects your code opened in the IntelliJ IDEA editor or the code you are typing. The plugin highlights the code fragments where two variables of the reference type are separated by == or != and proposes to replace this code fragment with .equals():

A plugin for the IntelliJ platform (IntelliJ IDEA, RubyMine, and PhpStorm, etc.) that provides support for the AsciiDoc markup language. It also supports Antora, the documentation CMS build with AsciiDoc.

Now, on their own, these are some pretty awesome features.However, when you consider that the functionality of the plugin is combined with all of the pre-existing functionality available in IntelliJ IDEs, and with the functionality of any additional you may add, I hope that you start to see just how powerful a technical writing setup it presents.

So imagine my surprise as I was setting the source language type in a source code block recently, and witnessed beautiful syntax highlighting take hold.I was stunned!Take a look at the screenshot below.Perhaps you will be too.

Sure, by storing source code in external files, it can be linted as part of the build process, by git hooks, and manually by me, which will ensure that the code is bug-free.However, editing the code directly in the AsciiDoc file sure can be convenient at times.

The next AsciiDoc file that you open, and the next time you reopen IntelliJ, the default configuration will be back.So, to configure the setup permanently, first navigate to Settings Languages & Frameworks AsciiDoc.

If I were to rename or move modules/ROOT/pages/reference/how-to-install-debian.adoc any cross-references to it, throughout every page in any of the content sources, and in the navigation file will be updated.

In addition to the toolbar, if you right-click or context-click on a section (or selection) of text, all of these items are available under the AsciiDoc option at the top of the dialogue that pops up.

As I mentioned earlier, the last item in the toolbar helps create tables.If you click on it, you can then create up to a 10-row x 10 column table by mousing over the grid in the popup, and clicking when the desired number of rows and columns are highlighted.

In IntelliJ IDEA, there is a set of code inspections that detect and correct anomalous code in your project before you compile it. The IDE can find and highlight various problems, locate dead code, find probable bugs, spelling problems, and improve the overall code structure.

This intention encourages you to follow a best practice of not letting a document grow too large. It can create a new include file from one of the currently selected text, the current block, or the current section.

IntelliJ IDEA comes with a series of inspections that are responsible for highlighting issues in your code, and often times give way to Intentions (i.e. Alt+Enter and try and resolve the issue). Examples include unused variables, invalid property keys, etc.

We need to provide the name of the build step and the type of project. In the case of it being Maven or Gradle, we also indicate the path to the build file. As soon as we enable this, we can get the same inspections we have in the IDE, running on the server.

With the plugin installed, set up correctly (i.e. configure the login to the right TeamCity server) and the project open, clicking on the inspection in TeamCity will take us directly to the issue in our project

We now have inspections running on the server, but what happens if we want to react to this, like for instance failing the build. TeamCity allows us to do just this. Under Failure Conditions in the build configuration, we can add a new condition based on the results of the inspections

By default, TeamCity will run all the inspections that IntelliJ IDEA provides, but we can fine-tune this and specify exactly which ones we want run. This can be useful in scenarios where we want a different set of inspections to be run team-wide versus locally. The way to go about defining the inspections is to specify a profile name. In IntelliJ IDEA we can do this using the Profile option under Inspections

When we specify the profile name, it will then only run those specific inspections. By default, the inspection configuration is located under the .idea/inspectionProfiles folder of the project. We can use this location, or optionally export the profiles via IntelliJ IDEA Profile export option to a different locationand indicate this in the configuration in TeamCity. If you want to keep profiles editable easily and in sync using the IDE, the former option is recommended.

In light of some inspections taking potentially a long time to run or being different from those run locally, the IDE plugin for TeamCity allows us to actuallyget the results of a server-side inspection directly in the IDE. For this we can choose to run code inspections from the TeamCity menu

LinkedIn and 3rd parties use essential and non-essential cookies to provide, secure, analyze and improve our Services, and to show you relevant ads (including professional and job ads) on and off LinkedIn. Learn more in our Cookie Policy.

Today I went to Hello Work for an information session on employment insurance benefits. Some of you may not know about Hello Work. Hello Work is an organization that helps unemployed people find new employment. It is also a place where people can apply for insurance benefits for those who have lost their jobs there.

By the way, in case you are wondering, I am currently unemployed, which means I am in a career break period. As such, I have suspended several subscriptions due to lack of steady income. One is Adobe Creative Cloud. And another is IntelliJ IDEA. I am sure they will all resume subscriptions when I return to work, but for now I have decided to pause.