(If you are here to ask “What are all the
noinspection comments in the code?”, please read the “Why are there
noinspection comments” page for a thorough explanation.
But if you just want to learn how to use Code Inspection effectively in JetBrains, this is the page you’re looking for…)
One of the nice features of JetBrains IDEs is “Inspect Code” (
Code -> Inspect Code).
See a description of this feature here: https://www.jetbrains.com/help/ruby/running-inspections.html
The sections below give more details on how to take full advantage of this feature.
Keeping a clean “Inspect Code” and “green check”
This allows you to run all code inspections, including project-configured supported linters such as RuboCop/ESLint, as well as custom IDE inspections such as type safety, potential bugs, etc., which will show up in the “Problems” pane after you run “Inspect Code”.
In addition to the “Problems” pane, you get instant feedback in the editor with the problems being underlined, as well as a summary of all problems with icons in the upper-right of each file. All of these can be hovered over with the mouse to give you more options to deal with the errors, including automatically fixing them in some cases.
And if you have no problems in the file, you get a “Green Check” at the top right of the file, as a constant and instant feedback.
These can be powerful time-saving tools to catch problems immediately, without having to wait for a pre-push hook like “LEFTHOOK” to catch them, or ever worse, having to wait for CI to catch them.
“Next Error” shortcut
PRO TIP: If you set
Settings -> Editor -> Code Editing -> Error Highlighting -> The 'Next Error' action goes through
"All Problems" selection, you can use
F2 to cycle through all errors in the file,
Alt-Enter and arrow keys to show the options you have for resolving the error.
Suppressing false positives with
Sometimes, though, there are “false positive” problems reported by “Inspect Code”. These are usually due to some IDE bug or limitation, or sometimes due to incorrect type annotations in a library.
Whatever the cause, it’s good to suppress these false positives, because:
- They cause noise in the “Problems” pane, and have to be ignored. Or in the case of a file with no other real problems, cause the “Problems” pane to pop up when it otherwise would not.
- They prevent the nice “Green Check” from showing up in a file with no other real problems.
- For JetBrains users who new to that area of the code, they don’t have a way to know if they are a legit problem they should consider fixing or not.
The way you suppress these false positives is with
noinspection ... comments: https://www.jetbrains.com/help/ruby/disabling-and-enabling-inspections.html
If you use
F2 “Next Error” then right arrow, you can automatically add the correct
noinspection ... comment to ignore the problem. However,
you will have to manually add a space after the
# to avoid a RuboCop
warning in the
Use the following process to automatically add a
- Either hit
Option-Enterwhile on the warning line in the code (after pressing
F2to find it), or else in the “Inspect Code”
Problemspane report right-click on the error.
- In the menu that comes up, find the
Suppress for statementoption and click it.
- Note that there is currently a bug that doesn’t put a space after the
#comment in Ruby, you’ll have to add one to avoid a rubocop error (TODO: Open an issue for this against RubyMine)
- This enables you to have a nice, clean report and green check with no false positives :)
noinspection should be accompanied by an explanation or link
noinspection comments might confuse some non-JetBrains users.
Therefore, each of these comments should be accompanied by a comment explaining why it was needed, with a reference to any supporting information.
If it was needed due to a JetBrains bug or limitation, you can reference the specific entry on the Tracked JetBrains Issues page.
If one doesn’t exist yet, you should open an issue against JetBrains and add it to that page.
noinspection and explanation should be a one-liner
# noinspection - <some link or explanation> comments should be on a single line.
This is because we want to to avoid the possibility of deleting an obsolete/fixed
# noinspection line
but forgetting to delete the separate associated comment line.
This should be done consistently, even if there needs to be an associated
# rubocop:disable Layout/LineLength,
on a separate line (because that will cause a separate RuboCop warning if it is left in while no longer
Other options considered:
- We could use a URL shortener service, but that makes people concerned about the security of clicking on links with an unknown destination. We did discuss and reject in the past the possibility of an internal URL shortener.
- We could leave some of the comment without an explanation of link, but that leaves us with the original problem of people not understanding their purpose, and having to manually address repeated questions around them, rather than people discovering the answer themselves in this section.
Inspect Code with custom scopes
One way you can make Code Inspections (and other JetBrains operations) faster and more powerful is through the use of custom scopes
If you curate a custom “Scope” which only selects the files related to the feature you are currently working on, you can also use this report to find all warnings/errors in any of those files.
Here’s a quick list of steps to set this up (TODO: add more details/links):
- Ensure you have all the linting plugins enabled and configured: rubocop, eslint, prettier (search for these in the Preferences search, some are enabled by default)
- In Preferences -> Editor -> Code Editing -> Error Highlighting section -> Change
The 'Next Error' action goes throughto
- Then you can see all the highlighting in the current file by default.
F2(next error) to cycle through all errors in the current file. Press
Option+Returnwhile on the error to open a menu of possible fixes.
- To check multiple files, you can use the
Inspect Codefunction (Cmd-shift-A -> “Inspect Code”) and pick an individual file or custom scope to inspect.
- You can also set up a custom scope to only include the files for the Feature or area of code you are working on
- Preferences -> Appearance and Behavior -> Scopes
+to add a scope and give it a name (e.g.
- Use the Include/Exclude/Recursively buttons to define what files should be included in the scope.
- Here’s a current example of the
remote_devscope definition which could be shared with other team members:
- You can also share the XML file for the directly, it will be under
- Here’s Chad’s current examples of two scopes related to Remote Development:
- All remote dev files: https://gitlab.com/jetbrains-ide-config/jetbrains-ide-config-gitlab/-/blob/master/dotidea/scopes/remote_dev.xml
- Only remote dev services and lib files: https://gitlab.com/jetbrains-ide-config/jetbrains-ide-config-gitlab/-/blob/master/dotidea/scopes/remote_dev_services___lib.xml