google
IdentifierName rejects m-failsafe-p default inclusion patterns
By default, the Maven Failsafe plugin relies on a set of file name patterns to determine which test classes to include. This is the <includes> option, and its default values are
-
**/IT*.java -
**/*IT.java -
**/*ITCase.java
In v2.36.0, the IdentifierName check (which I'm unreasonably excited about!) accurately detects those names as being in violation.
Unfortunately, for a user wishing to take advantage of Failsafe, working around this is a bit cumbersome; it seems they can...
- ... not run Error Prone on test code at all, but I would like to.
- ... change
<includes>to any compliant non-default value, but that introduces non-standard behaviour for dubious reasons. - ... use
-XepOpt:IdentifierName:AllowInitialismsInTypeName=true, but actually, that allows a name likeXMLHTTPRequestthat is specifically called out as in violation, and incidentally, is exactly the sort of situations I see people struggle with the most. - ... suppress each violation, which I personally consider the correct response but a noisy and tiresome one.
Every option is possible but all of them carry friction.
The behaviour I would most like to see is that IdentifierName automagically did not flag these cases so the defaults Just Work™. But Error Prone cannot know which arbitrary patterns I might have set in my own <includes>, so any support for this is bound to be either inflexible or complex. Correspondingly, I would suggest that IdentifierName should at most allow Failsafe's default <includes> values
A more flexible approach is a new option, -XepOpt:IdentifierName:MyBikeshed=*IT,*MXBean, which passes a set of patterns to IdentifierName to allow.
See also #4776.
$ ./mvnw clean test-compile -DepFlags='-XepDisableAllChecks -Xep:IdentifierName:ERROR'
[INFO] Scanning for projects...
[INFO]
...
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] /.../src/test/java/example/ITFoo.java:[1,8] [IdentifierName] Classes should be named in UpperCamelCase, with acronyms treated as words (https://google.github.io/styleguide/javaguide.html#s5.3-camel-case); did you mean 'ItFoo'?
(see https://google.github.io/styleguide/javaguide.html#s5.2-specific-identifier-names)
[ERROR] /.../src/test/java/example/FooIT.java:[3,8] [IdentifierName] Classes should be named in UpperCamelCase, with acronyms treated as words (https://google.github.io/styleguide/javaguide.html#s5.3-camel-case); did you mean 'FooIt'?
(see https://google.github.io/styleguide/javaguide.html#s5.2-specific-identifier-names)
[ERROR] /.../src/test/java/example/FooITCase.java:[3,8] [IdentifierName] Classes should be named in UpperCamelCase, with acronyms treated as words (https://google.github.io/styleguide/javaguide.html#s5.3-camel-case); did you mean 'FooItCase'?
(see https://google.github.io/styleguide/javaguide.html#s5.2-specific-identifier-names)
which I'm unreasonably excited about!
I'm glad someone is unreasonably excited about style-violating identifier names. :)
As you can probably imagine, we're not super motivated about adding carve-outs for the style guide that don't matter to Google internally. I quite like the idea of a regular expression flag to exempt certain names, though, if that would be useful to external users. I'd be happy to accept a PR.
As you can probably imagine, we're not super motivated about adding carve-outs for the style guide that don't matter to Google internally.
No doubt; and it can be pretty frustrating to be on the user side of fixed exemptions that don't include one's pet violation, too. Fortunately it was a lot easier to expose a regex option than I had guessed it would be; I have a preliminary suggestion in #4842.