Since comma and period (, and .) look almost alike, one can easily be mistaken for the other. So if I have something like foo(bar,foobar) I might think it’s foo(bar.foobar). Or if I have foo(bar. foobar) I might think it’s foo(bar, foobar).
I would like to see a smell rule that flags:
A comma that is not at the end of a line and is followed by something other than a blank;
A period used for member access, which IS followed by a blank (not EOL).
These could be separate rules, or combined; doesn’t matter to me.
(One could argue that #2 could actually be a bug, since people tend not to do it, and SQ tends to classify cases of “you didn’t really mean THAT did you?” as bugs. But if you meant to put a comma and put in a period instead, there’s like a 99.99% change your code won’t compile.)
I was specifically referring to Java, but this would be useful for any language where . is an operator for field or member access (Python, JS/TS, the C family, etc.). You have some fairly general rules, like S100, where there’s a java:S100, javascript:S100, etc. So this rule should be the same way – grab a suffix that hasn’t been used yet by any language, and use it for each language where applicable. (I don’t know how your checker code works but it seems like the implementation would be fairly portable across languages.)
Sorry for the late reply on this. After discussing a potential rule out of your suggestion internally, we believe that such a rule does not have great potential and so we won’t implement it.
While we understand what we would try to catch and finding such a “problematic” chain of tokens is simple (in terms of implementation), identifying what are legitimate cases is pretty hard. Out of our experience in writing rules, we consequently feel that the ratio between TP and FP is going to play hard against it… Making it more confusing/frustrating for users than useful, and so the ROI in implementing it would be poor.
Also, since Java is a compiled language, we strongly believe that you would need to be incredibly unlucky to end up in a situation where writhing , instead of . leads to a valid code.
Without any traction from other users, we will therefore not move forward with your suggestion.