Recent changes to feature-requests

#418 Add support for checking indentation

2018-05-28T00:29:12.691000Z

status: open --> closed
Group: -->

#418 Add support for checking indentation

2018-05-28T00:28:56.631000Z

Addressed in GitHub #271

#335 Ignore MethodName for all Spec method

2017-11-10T15:20:00.761000Z

See https://github.com/CodeNarc/CodeNarc/issues/261.

#335 Ignore MethodName for all Spec method

2017-11-10T11:29:10.165000Z

++ Spock support would be great

#437 New MethodNameInCamelCaseRule rule

2016-05-16T00:04:33.272000Z

The CodeNarc repo is now on GitHub:
https://github.com/CodeNarc/CodeNarc

My apologies for not making that more obvious on the SourceForge site. Are you able to submit a GitHub pull request instead?

And I cannot yet understand how MethodNameInCamelCaseRule actually works, given the code in that patch file, but maybe I am missing something.

Thanks for the contribution.
Chris

New MethodNameInCamelCaseRule rule

2016-05-13T09:52:37.095000Z

Hi, I have added a new rule "MethodNameInCamelCase", I've added a patch here.. Please add!
Thanks in advance.

#335 Ignore MethodName for all Spec method

2015-08-15T16:57:37.441000Z

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.

#301 Switch to use Groovy-Eclipse compiler for build

2015-02-28T14:21:10.219000Z

status: open --> closed
assigned_to: Chris Mair
Group: -->

#301 Switch to use Groovy-Eclipse compiler for build

2015-02-28T14:20:54.659000Z

Cosed as duplicate of
https://github.com/CodeNarc/CodeNarc/issues/87

#436 exclude Grails src/templates dir

2015-02-11T23:27:30.933000Z

Thats correct, I use the Sonar Groovy Plugin and sonar-runner within Jenkins as a Post build standalone task. This way (on Sonar 5.0), multi-language tests are performed out of the box dependent on the plugins installed in Sonar, so we can test Groovy, Java, Javascript, XML and CSS files automatically.

I played around with the sonar.sources and sonar.exclusions properties and figured out that sonar.exclusions seem to be ignored by codenarc.

So using

sonar.sources=src/java,src/groovy,grails-app/services,grails-app/controllers,grails-app/domain,grails-app/taglib,grails-app/assets, grails-app/conf

did the trick. This way, you can avoid the template compilation errors.
Disadvantage is, that you need to add new source directories and files to sonar.sources manually.