[prev in list] [next in list] [prev in thread] [next in thread] 

List:       groovy-user
Subject:    RE: [groovy-user] Advocating Groovy vs. Java Phase II - How to Manage Groovy Adoption
From:       "Corum, Michael" <mcorum () rgare ! com>
Date:       2014-08-22 14:22:43
Message-ID: D4E92D0D754A9346BB2CC8FDB445BA0E2F25BCF3 () STLPEXC840 ! rgare ! net
[Download RAW message or body]

We use CodeNarc heavily.  The combination of CodeNarc and Cobertura can tell me if \
developers are really doing Test-Driven Development.  My rules file for CodeNarc is \
typically less than a page and can stay that way for years so the management of the \
rules is not onerous.  Here is a sample rules file from a real "REST Services" \
project (Dropwizard/Groovy/Gradle) with a few things changed to protect company \
information:

Mike

ruleset {
	description 'Rules For Services Groovy Gradle Project'
	ruleset('rulesets/basic.xml')
	ruleset('rulesets/braces.xml')
	ruleset('rulesets/exceptions.xml') {
		CatchThrowable(enabled: false)
		CatchException(enabled: false)
		ThrowException(enabled: false)
	}
	ruleset('rulesets/imports.xml') {
		MisorderedStaticImports(comesBefore: false) // Match up with IntelliJ CTRL-ATL-L
	}
	ruleset('rulesets/logging.xml') {
		Println (enabled:false)
		'PrintStackTrace' priority: 1
	}
	ruleset('rulesets/naming.xml') {
		FactoryMethodName(enabled: false)
	}
	ruleset('rulesets/unnecessary.xml')
	ruleset('rulesets/size.xml') {
		MethodCount {maxMethods = 200}
		CyclomaticComplexity {
			maxMethodComplexity = 7
			ignoreMethodNames = 'assert*'
		}
		MethodSize {
			maxLines = 19 // Small methods with good naming improves quality measurably
			ignoreMethodNames = 'populate*,assert*,mock*,generate*' //These method names are \
used in tests and for populating large Representations (pojos)  \
doNotApplyToFilesMatching = '.*Representation.groovy'  }
		AbcMetric {
			maxMethodAbcScore = 42
			maxClassAverageMethodAbcScore = 24
			ignoreMethodNames = 'populate*,merge*,assert*,mock*'
			doNotApplyToClassNames = 'ASpecificRepresentation,ThatRepsResourceTests' // This \
class was allowed to be more complex - reviewed in code/architecture review  \
doNotApplyToFilesMatching = '.*RepresentationTests.groovy'  }
		ClassSize {
			maxLines = 2000 // Sometimes classes associated with services populate large \
representations (pojos) so the number of data items increases the line count in the \
class  }
	}
	ruleset('rulesets/unused.xml') {
			UnusedMethodParameter {
				ignoreClassRegex = '.*Resource'
			}
		}
}

-----Original Message-----
From: Thibault Kruse [mailto:tibokruse@googlemail.com] 
Sent: Friday, August 22, 2014 8:12 AM
To: user@groovy.codehaus.org
Subject: Re: [groovy-user] Advocating Groovy vs. Java Phase II - How to Manage Groovy \
Adoption

Hi Chris,

thanks, I saw that article, but it sounds more like a description of exciting new \
features, and not advice about which ones should best be avoided.

Also thanks for the CodeNarc self-test ruleset link, in the absence of public \
codenarc rules for Groovy itself and Grails, the codenarc team is the next authority \
I will trust to have carefully considered code style, their opinion will still be \
better than mine.

cheers,
  Thibault



On Fri, Aug 22, 2014 at 2:48 PM,  <chris.mair@wellsfargo.com> wrote:
> > > sadly there is no general convention on clean Groovy Style
> 
> You should also take a look at: "Groovy style and language feature guidelines for \
> Java developers " 
> http://groovy.codehaus.org/Groovy+style+and+language+feature+guideline
> s+for+Java+developers
> 
> But I agree that there is no comprehensive, generally-accepted standard.
> 
> > > Codenarc uses itself on it's own groovy sources, but I struggled to find their \
> > > ruleset file.
> 
> The CodeNarc internal ruleset is at:
> 
> https://github.com/CodeNarc/CodeNarc/blob/master/src/test/resources/Ru
> nCodeNarcAgainstProjectSourceCode.ruleset
> but that is definitely not to be considered a globally-applicable, comprehensive \
> style guide. Some of those rule choices were more pragmatic, rather  than \
> strategic. And of course, CodeNarc only has rules to enforce a subset of \
> style/formatting issues. 
> Chris

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


[prev in list] [next in list] [prev in thread] [next in thread]