As Spock is being more and more used among Groovy developers CodeNarc should not complain about nonstandard method name in classes extending directly or indirectly from spock.lang.Specification
and specifically the doNotApplyToClassNames. doNotApplyToFileNames and doNotApplyToFilesMatching rule properties.
I am hesitant to put framework-specific logic in generic rules, as suggested. But perhaps you could argue that we already do that so some extent by ignoring test classes (by default) for certain rules.
Is the above good enough?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A set of rules that "play nice" with Spock tests would be a big help. Spock tests often have strange method signatures in that they usually start with "def" and have strings for method names, which don't fit the "normal" method name regex.
Simply setting these existing rules to not be applied to Spec files isn't quite sufficient, since there are often helper methods defined in the Spec files that would be nice to apply the "normal" rules to.
There are also a number of rules that are "best practices" or at least suggested formatting rules that I've not been able to find a rule set for, but would be great to have available for me, my team, and I'm sure many others.
I'm fully behind not mixing framework-specific logic into the generic rules, but having framework-specific versions of those rules like for the Grails-specific ruleset, or control points on the generic rules that allow them to be sufficiently targeted would be a big help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is fairly simple and straightforward to configure the MethodName rule (or any rule) to ignore classes by name or by filename or regex.
See: http://codenarc.sourceforge.net/codenarc-configuring-rules.html#Standard_Properties_for_Configuring_Rules
and specifically the doNotApplyToClassNames. doNotApplyToFileNames and doNotApplyToFilesMatching rule properties.
I am hesitant to put framework-specific logic in generic rules, as suggested. But perhaps you could argue that we already do that so some extent by ignoring test classes (by default) for certain rules.
Is the above good enough?
A set of rules that "play nice" with Spock tests would be a big help. Spock tests often have strange method signatures in that they usually start with "def" and have strings for method names, which don't fit the "normal" method name regex.
Simply setting these existing rules to not be applied to Spec files isn't quite sufficient, since there are often helper methods defined in the Spec files that would be nice to apply the "normal" rules to.
There are also a number of rules that are "best practices" or at least suggested formatting rules that I've not been able to find a rule set for, but would be great to have available for me, my team, and I'm sure many others.
I'm fully behind not mixing framework-specific logic into the generic rules, but having framework-specific versions of those rules like for the Grails-specific ruleset, or control points on the generic rules that allow them to be sufficiently targeted would be a big help.
++ Spock support would be great
See https://github.com/CodeNarc/CodeNarc/issues/261.