Avoid scanBadSymbols to be Error. about codeinspector HOT 6 CLOSED

Yes, that is why these are not 100% confident.

I'm sorry if a user defines, e.g., UnSameQ as their own function (and does not want to use the built-in System`UnsameQ. Mind the capitalization!)

Do you have examples? I can always adjust confidence appropriately.

from codeinspector.

I could imagine people defining their own SymbolQ, RealQ, etc.

https://mathematica.stackexchange.com/questions/225811/when-is-a-symbol-a-symbol-is-there-an-easy-mathematica-way-to-test-if-an-object
https://mathematica.stackexchange.com/questions/181761/why-no-rationalq-or-realq

Is there evidence that these are real mistakes that people make? Syntax colouring should alert them that these functions do not exist.

(It doesn't bother me though as it's so easy to turn off. Also, using names such as SymbolQ or RealQ in a package is IMO a bad idea: there is a high risk that these may appear in the System context in the future. So alerting people to this is not necessarily bad.)

from codeinspector.

@szhorvat Yes, all are taken from real-world cases of assuming a function existed without first checking.

There will be false positives. Someone may define RationalQ precisely because it is not in System` .

It is a goal of CodeParser to eventually do a better job of knowing when there are local function definitions. And then CodeInspector would know to not give BadSymbol lints for those functions.

What do people think of the assigned confidences?

0.95 Confidence:

• UnSameQ
• StringMatch

0.75 Confidence:

• AnyFalse
• AllFalse
• Failed
• Boolean
• RealQ
• FalseQ
• RationalQ
• ComplexQ
• SymbolQ
• Match

Should anything be adjusted?

from codeinspector.

Yes, I saw them in Rubi.

https://github.com/RuleBasedIntegration/Rubi/blob/a57f10f6e0a0b1168599df88cfaca1fa29c76ea7/Rubi/IntegrationUtilityFunctions.m#L60

Coding styles are project-based / organization-based, people naming their functions as FooQ is completely legit. scanBadSymbols is used to remind the users these functions do not exists in System`, but we do not have a way in Wolflang to statically analyze whether user has defined them or not. That's the point I think this should be changed to some kind of warning, hint or code suggestion instead of error.

Btw, is confidence currently only a reference for the users, not applied in actual analysis right?

from codeinspector.

Confidence is used when showing the results. You can see the difference with CodeInspectSummarize["UnSameQ"] vs. CodeInspectSummarize["UnSameQ", ConfidenceLevel -> 0.96]. It is metadata that is present in all InspectionObjects and can be used to filter results for more or less confidence.

from codeinspector.

If there are any suggestions for changing confidences, let me know. Otherwise, I am closing this since:

There is more value in flagging these as errors than not
Results can always be filtered programmatically, if people want to

from codeinspector.