Naming conflicts in inspection profiles


I've encountered an issue with enabling/disabling inspections. It seems that IJ is inferring a name/id to be used in the `.idea/inspectionProfiles/Project_Default.xml` by simply trimming "Inspection" from the inspection-class name. However, this easily leads to naming conflicts since commons inspections like "some.package.UnusedReferenceInspection" will have the same derived short name in the profile.xml.

This gives an unpredictable UX when disabling inspections, ie. those with naming conflicts are impossible to become permanently disabled. 

It seems that I can define my own `shortName` but why isn't IJ just using the complete `implementationClass` to refer to an inspection in the profile?Or use some prefixing by language for the derived short names? Or at least the `shortName` should/could be enforced by an inspection on the `plugin.xml`? 


You can define the shortName and in most cases they are explicitly defined. On the other hand there is an implementation which you can reuse if your inspections are specific. It's impossible to redefine ids of existing inspections as this would break users profiles, for the new inspections one can define meaningful shortNames which by default would be used as suppress ids in the source code, so they should not be too long.

Hope I answer your questions,



Thanks Anna. I see your point, but I would still expect plugins to run into naming problems all the time because chosen short-names are often very generic. E.g. take 

<localInspection groupPath="Java" language="JAVA" shortName="UnusedImport" bundle="com.siyeh.InspectionGadgetsBundle" key="" runForWholeFile="true"
groupBundle="messages.InspectionsBundle" groupKey="group.names.imports" enabledByDefault="false" level="WARNING"

With `UnusedImport` as shortName the odds are pretty high that another language plugin has used the same short-name.

As a plugin-dev I could potentially avoid all the java-shortnames but checking all other existing plugins is impossible, so the only workaround seems to use not-so-short ids (like the full class-reference to avoid another set of extra-ids) as "shortName"s instead. 

I think the reason why nobody complained about this issue yet is that IJ inspection profiles are silently buggy by "just" reenabling/disabling the name-conflicting inspections on startup.


Please sign in to leave a comment.