Recent changes to feature-requests

#418 Add support for checking indentation

Chris Mair — Mon, 28 May 2018 00:29:12 -0000

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

#418 Add support for checking indentation

Chris Mair — Mon, 28 May 2018 00:28:56 -0000

Addressed in GitHub #271

#335 Ignore MethodName for all Spec method

Chris Mair — Fri, 10 Nov 2017 15:20:00 -0000

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

#335 Ignore MethodName for all Spec method

Charles — Fri, 10 Nov 2017 11:29:10 -0000

++ Spock support would be great

#437 New MethodNameInCamelCaseRule rule

Chris Mair — Mon, 16 May 2016 00:04:33 -0000

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

Riddhi Gandhi — Fri, 13 May 2016 09:52:37 -0000

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

Rick Jensen — Sat, 15 Aug 2015 16:57:37 -0000

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

Chris Mair — Sat, 28 Feb 2015 14:21:10 -0000

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

#301 Switch to use Groovy-Eclipse compiler for build

Chris Mair — Sat, 28 Feb 2015 14:20:54 -0000

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

#436 exclude Grails src/templates dir

Chris Mair — Wed, 11 Feb 2015 23:27:30 -0000

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.