Inspection - Preferred case - too many false negatives

[Eric Kintzer]

There are too many "technically positive, but practically false negative" inspections for SFDC language keywords where SFDC itself isn't consistent in the documentation. I believe the inspection should be way more tolerant (or configurable) for language elements versus user-defined class, method, and variable names

Examples of "spurious for all practical purposes" inspection warnings

@isTest  // should be @IsTest
Sobject // should be SObject
DateTime // should be Datetime
set // should be Set
list  // should be List
map // should be Map

Examples of legitimate Preferred case inspections

• All method names
• All user-defined Class names
• All user-defined variable names

You just have to look at the SFDC doc, for example this page to see SFDC examples and text that violate the technical spirit of the inspection.

When I open up a class in our org , I'm presented with a wall of yellow in the right hand column - 99% of which are spurious items like 'list' instead of 'List'

So, yes I can fix these all up with the Quick Fix but more than likely, since typing in lower case is easier, I'm going to reintroduce lowercase 'set' or 'list' into the code that I have to fix up again (or a colleague will do the same, especially if the colleague is not using IC).

I could also turn off the inspection but then I would lose what I legitimately feel are valid inspection alerts (vbl names, Sobject type and field names, and all method names). I could also exploit the live templates more but this doesn't solve the colleague issue above.

I didn't mean to turn this into a rant as I really do like IC.

Bottom line: Turn the preferred case inspection into multiple inspection types:

• Preferred Case - System types
• Preferred Case - System methods
• Preferred Case - System properties
• Preferred Case - Sobject types and fields
• Preferred Case - SOQL
• Preferred Case - User types
• Preferred Case - User methods
• Preferred Case - User properties/variables

I'm sure I'm leaving something out but you get the gist

and allow these to be enabled/disabled in Preferences

[Scott Wells]

Eric, totally understood. This inspection is currently 100% subjective (albeit based on the standards for Java and SQL respectively and their respective analogs in Apex/SOQL/SOSL).

FWIW, the plan here is to allow the user to configure the desired case for all Apex/SOQL/SOSL keywords, both for purposes of code completion and for this inspection. I do plan to add that enhancement, but it's currently behind many other items on my backlog. My recommendation to folks who are finding this particular code inspection to be more noise than signal due to preferences that are different from the inspection's (i.e., mine) is to disable the code inspection entirely until the enhancements are in place. That way you won't be constantly fighting it.

[Eric Kintzer]

Scott - np -- wanted to get this onto the issue tracker; as I noted, it is minor

[Scott Wells]

I do like the idea of having distinct enabled/disabled categories for this inspection if you agree with keywords but not annotations. That might be a good stopgap measure until I can add full configuration.

Regarding some of the examples you've provided, all but the annotation (@isTest) are actually system types with their canonical casing decided by Salesforce's own APIs. They're not technically keywords. You can see how Salesforce specifies them when querying the Tooling API's completions REST resource. Those are being highlighted by another code inspection that is not subjective. It basically says that the declaration case is authoritative, and for system types the declaration case is provided by Salesforce themselves.

The subjective portion of this inspection is for keywords, and in annotations are keywords and not class names as they are in Java and some other languages. Those are what I plan to make configurable according to folks' preferences in the future.

I hope that helps!

[Scott Wells]

This should have been addressed -- as much as it will be -- by the enhancement to allow the user to select the desired case for each key category of keyword.