codenarc-developer — CodeNarc Developers

Re: [Codenarc-developer] gradle + codenarc

[Chris M. <chr...@ea...>]

Thanks for the heads-up Hamlet.

I am waiting for my subscription request to us...@gr... list to
be accepted/confirmed so that I can reply.

(1) It looks like the problem is this code in RuleSetUtil for loading a rule
script file:

        def inputStream = resourceFactory.getResource(path).inputStream
        Class ruleClass
        inputStream.withStream { input ->
            GroovyClassLoader gcl = new GroovyClassLoader()
            ruleClass = gcl.parseClass(input)
        }

I expect that the new GroovyClassLoader() should probably instead be:
	new GroovyClassLoader(this.class.classLoader())

That may explain not being able to compile the rule script file.

(2) The file:xxx URL to the rule script file can also be a relative path (to
the current dir). So I was gonna suggest trying:

	rule('file:config/codenarc/MyCustomRuleScript.groovy') 

instead of:

	def ruleScript = new
File('config/codenarc/MyCustomRuleScript.groovy') 
	rule('file:' + ruleScript.canonicalPath) 


Let me know if you think I am off base on either of these.

Unfortunately, Nabble is blocked at my work (don't get me started about our
$%#@^ firewall policy), so it will be another half-day or so until I can
reply.

Thanks.
Chris

-----Original Message-----
From: Hamlet DArcy [mailto:ham...@ca...] 
Sent: Tuesday, February 22, 2011 2:13 PM
To: cod...@li...;
cod...@li...
Subject: [Codenarc-developer] gradle + codenarc

Does anyone want to comment on this thread: 
http://gradle.1045684.n5.nabble.com/code-quality-plugin-location-of-custom-c
odenarc-rule-td3373768.html

A user is having trouble including their own custom rule. 

--
Hamlet D'Arcy
ham...@ca...


----------------------------------------------------------------------------
--
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT
data generated by your applications, servers and devices whether physical,
virtual or in the cloud. Deliver compliance at lower cost and gain new
business insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________
Codenarc-developer mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-developer

[Codenarc-developer] gradle + codenarc

[Hamlet D. <ham...@ca...>]

Does anyone want to comment on this thread: 
http://gradle.1045684.n5.nabble.com/code-quality-plugin-location-of-custom-codenarc-rule-td3373768.html

A user is having trouble including their own custom rule. 

--
Hamlet D'Arcy
ham...@ca...

Re: [Codenarc-developer] Next CodeNarc release?

[<chr...@wa...>]

No problem. I have been pretty slammed myself.




Hamlet DArcy <ham...@ca...> 
02/18/2011 01:16 AM


To

cc
cod...@li...
Subject
Re: [Codenarc-developer] Next CodeNarc release?






I am slammed with work between now and next Friday. However, next weekend 
I could maybe find time to fix the few bugs. 

To fix the UnusedPrivate* rules, I think it is easy. I have some ideas but 
don't have time to write them out right now. 



----- Original Message -----
> 
> 
> 
> Hamlet,
> 
> 
> 
> Any thoughts on timing for the 0.13 release? Any motivation to either
> do it ASAP or hold off for a while?
> 
> 
> 
> Chris

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Codenarc-developer mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-developer

ForwardSourceID:NT00103532 

Re: [Codenarc-developer] Next CodeNarc release?

[Hamlet D. <ham...@ca...>]

I am slammed with work between now and next Friday. However, next weekend I could maybe find time to fix the few bugs. 

To fix the UnusedPrivate* rules, I think it is easy. I have some ideas but don't have time to write them out right now. 



----- Original Message -----
> 
> 
> 
> Hamlet,
> 
> 
> 
> Any thoughts on timing for the 0.13 release? Any motivation to either
> do it ASAP or hold off for a while?
> 
> 
> 
> Chris

[Codenarc-developer] Next CodeNarc release?

[Chris M. <chr...@ea...>]

Hamlet,

 

Any thoughts on timing for the 0.13 release? Any motivation to either do it
ASAP or hold off for a while?

 

Chris

[Codenarc-developer] CodeNarc rulesets - even necessary?

[Chris M. <chr...@ea...>]

Hamlet,

 

I am still looking into the possibilities for extending the ruleset configuration options. As I mentioned before, my goal was to extend the Groovy Ruleset DSL to allow configuring rules by only specifying the rule name (and not requiring the rule class or a ruleset), e.g.

 

ruleset {

        CatchThrowable(priority:1)

        EqualsAndHashCode(priority:3)

        MethodCount {

                doNotApplyToClassNames = ‘*Test, *TestCase’

        }

        UnnecessaryConstructor()

}

 

As long as I can determine the rule class for a specific rule name, I can modify the Groovy RuleSet DSL to support that syntax. My first thought was introducing a @Rule annotation for the rule implementations. That might be the cleanest, but I am not sure how to do the annotation processing. It looks like Java 1.6 includes much better support for annotation processing, but I am not willing to mandate Java 1.6.

 

So, after that, the best I can come up with is to retain a "registry" of all rules, indexed by name. Perhaps that means configure all rules; maybe in a “codenarc-base-rules.properties” file (mapping ruleName to ruleClass). But that is kind of brute force, and certainly violates DRY.

 

I think that ruleset capability would be valuable, and I would be inclined to recommend that as the “right” way for users to build their own custom rulesets, rather than assembling rulesets from our existing rulesets (e.g. basic, concurrency, etc.). That would remove the dependency on specific ruleset files, containing a set of rules that changes from release to release. That dependency on changing ruleset files causes me some hassle migrating 15+ projects with every release of CodeNarc, so I assume some other users experience that pain as well.

 

And, whether they use Grails or Gradle or just Ant, I think that most users end up customizing their rulesets. I also wonder whether having a single, definitive list/repository of all rules might benefit tools like the IDEA plugin or a future “CodeNarc Configuration Console”.

 

But what do you think?

 

Chris

 

From: chr...@wa... [mailto:chr...@wa...] 
Sent: Monday, January 24, 2011 9:34 AM
To: Hamlet DArcy
Cc: cod...@li...
Subject: Re: [Codenarc-user] CodeNarc rulesets - even necessary?

 


But even using Gradle/Grails/Griffon plugins, you often still need to assemble a custom ruleset. 

I may still explore options such as @Rule and configuring a custom ruleset without needing to reference those individual predefined rulesets. I think that could be done without harming backwards-compatibility. 

Chris 

Hamlet DArcy <ham...@ca...> wrote on 01/24/2011 03:23:00 AM:

> To me, the future lies in tools like the Grails, Griffon, Gradle, 
> and IDEA plugins. There are few questions (so far) about how to use 
> CodeNarc with these tools because the plugins take care of it for you. 
> 
> I wouldn't make any changes now because of backwards compatibility. 
> 
> --
> Hamlet D'Arcy
> ham...@ca...
> 
> ----- Original Message -----
> > Okay, to continue the discussion about the necessity of rulesets...
> > 
> > 
> > 
> > >> But why even have rulesets? ...
> > 
> > 
> > 
> > In general, I agree with you. Although we have done a little bit of
> > mix-and-match of picking rulesets at my work (e.g. pulling in the
> > Grails rules only for Grails projects), overall that has probably not
> > been worth the effort and complexity of maintaining those separate
> > rulesets.
> > 
> > 
> > 
> > But I would add that having something like the "Basic" ruleset is
> > valuable -- here are a "minimal" set of rules that pretty much
> > everyone can agree on. This is often the way to wade into using a tool
> > like CodeNarc. (Though I admittedly let the "basic" ruleset drift away
> > from that core mission a bit)
> > 
> > 
> > 
> > At this point, for backward-compatibility, I don' think we could just
> > remove the existing rulesets.
> > 
> > 
> > 
> > That all being said, I do think there is definitely room for
> > reorganization, improvement and innovation.
> > 
> > 
> > 
> > We could create one "All-Rules" ruleset. The Groovy Ruleset DSL could
> > be used as-is, but we’d have to figure out some scheme to NOT
> > automatically include all the rules in the ruleset by default, as it
> > does today, e.g.
> > 
> > 
> > 
> > ruleset {
> > 
> > ruleset('rulesets/all-codenarc-rules.xml', excludeByDefault:true ) {
> > 
> > CatchThrowable(priority:1) // only include explicitly-configured rules
> > 
> > EqualsAndHashCode(priority:3)
> > 
> > ThrowExceptionFromFinallyBlock()
> > 
> > UnnecessaryConstructor()
> > 
> > }
> > 
> > }
> > 
> > 
> > 
> > Another option along these lines is to automatically retain a
> > "registry" of all rules, indexed by name. Perhaps we could introduce a
> > @Rule (or somesuch) annotation for the rule implementations. I had
> > considered that from the beginning, but back then I needed to maintain
> > compatibility with Java 1.4 (don't get me started), so I could not
> > support annotations. I think it would then be possible to extend the
> > Groovy Ruleset DSL to automatically look into this registry for rule
> > names, so, there would be no need to specify an explicit ruleset file,
> > e.g.
> > 
> > 
> > 
> > ruleset {
> > 
> > CatchThrowable(priority:1)
> > 
> > EqualsAndHashCode(priority:3)
> > 
> > MethodCount {
> > 
> > doNotApplyToClassNames = ‘*Test, *TestCase’
> > 
> > }
> > 
> > UnnecessaryConstructor()
> > 
> > }
> > 
> > 
> > 
> > That seems quite nice and usable from my perspective.
> > 
> > 
> > 
> > 
> > 
> > >> One idea I had for simplification was to provide a "CodeNarc
> > >> Configuration Console"...
> > 
> > 
> > 
> > That sounds pretty cool.
> > 
> > 
> > 
> > Chris
> > 
> > -----Original Message-----
> > From: Hamlet DArcy [mailto:ham...@ca...]
> > Sent: Friday, January 21, 2011 9:31 AM
> > To: chris mair
> > Cc: cod...@li...; Jason Stell
> > Subject: Re: [Codenarc-user] Ruleset Resources Namespace Conflict
> > 
> > 
> > 
> > This is getting off topic from Jason's email...
> > 
> > 
> > 
> > But why even have rulesets? You can't actually make a decision based
> > on rulesets. You never say "you know, I want the concurrency ruleset
> > but not the exception ruleset". You would always look inside the set
> > and make decisions about individual rules. In my mind, I'd rather see
> > two and only two rulesets: CodeNarc rules and user rules.
> > 
> > 
> > 
> > One idea I had for simplification was to provide a "CodeNarc
> > Configuration Console". It would read the ruleset.xml files and
> > produce a tree view UI based on the rule classes, the declared
> > parameters, and the documentation. Then the user could just click
> > checkboxes and text fields until they had the configuration they
> > wanted and export the correct codenarc-properties.groovy file. The
> > model would be the IntelliJ IDEA Inspections UI. It's a bit of work
> > but nothing too challenging. A Gaelyk app would be cool. Can't we talk
> > someone from Gaelyk into doing this? I wonder what rentacoder.com
> > would charge.
> > 
> > 
> > 
> > 
> > 
> > --
> > 
> > Hamlet D'Arcy
> > 
> > ham...@ca...
> > 
> > 
> > 
> > ----- Original Message -----
> > 
> > > Yes, in hindsight, I should have put the ruleset files in a unique
> > 
> > > namespace, and as Hamlet suggested, avoiding specific rulesets
> > 
> > > altogether might have been a better approach.
> > 
> > >
> > 
> > > Is there anything forcing you to use the same classpath for both
> > 
> > > CodeNarc and PMD?
> > 
> > >
> > 
> > > I don't think we can, at this point, move the CodeNarc ruleset
> > > files,
> > 
> > > since that would break every user. Copying the ruleset files to a
> > 
> > > different location may help as a workaround, but I don't think that
> > 
> > > would solve the problem if the CodeNarc files are "hiding" the
> > 
> > > CodeNarc ones.
> > 
> > >
> > 
> > > Chris
> > 
> > >
> > 
> > >
> > 
> > > Hamlet DArcy < ham...@ca... >
> > 
> > >
> > 
> > > 01/21/2011 09:05 AM
> > 
> > >
> > 
> > > To Jason Stell < js...@gm... >
> > 
> > >
> > 
> > > cc cod...@li...
> > 
> > >
> > 
> > > Subject Re: [Codenarc-user] Ruleset Resources Namespace Conflict
> > 
> > >
> > 
> > >
> > 
> > >
> > 
> > >
> > 
> > > CodeNarc is modeled on PMD so we have all those ruleset files in
> > 
> > > common. Personally, I find both projects a little difficult to
> > 
> > > configure. I'd prefer to see one massive configuration file. But
> > 
> > > that's water under the bridge at this point. As you know, there is
> > 
> > > nothing special about that location. You /can/ copy all the contents
> > 
> > > of the ruleset xml files and dump them into one big file.
> > 
> > >
> > 
> > > --
> > 
> > > Hamlet D'Arcy
> > 
> > > ham...@ca...
> > 
> > >
> > 
> > > ----- Original Message -----
> > 
> > > > It does kinda stink ;) I would have suggested a change to PMD
> > 
> > > > resource names, as well, but that project has been around a long
> > 
> > > > time and a change would probably impact many more users (still, as
> > > > a
> > 
> > > > good practice, they should also think about putting resources in
> > > > an
> > 
> > > > appropriate namespace).
> > 
> > > >
> > 
> > > >
> > 
> > > > As a workaround I can always extract/copy the rulesets I'm using
> > > > and
> > 
> > > > put them in a different local namespace.
> > 
> > > >
> > 
> > > >
> > 
> > > > Oh - and thanks for CodeNarc!
> > 
> > > >
> > 
> > > >
> > 
> > > > Regards
> > 
> > > > Jason
> > 
> > > >
> > 
> > > >
> > 
> > > > On Fri, Jan 21, 2011 at 1:30 AM, Hamlet DArcy <
> > 
> > > > ham...@ca...
> > 
> > > > > wrote:
> > 
> > > >
> > 
> > > >
> > 
> > > >
> > 
> > > > > If I have both CodeNarc and PMD libs in my classpath, I have
> > 
> > > > > problems
> > 
> > > >
> > 
> > > > Well that stinks. If we rename the rules then we have backwards
> > 
> > > > compatibility issues. :( We'll have to discuss what to do.
> > 
> > > >
> > 
> > > > Do you need a workaround temporarily? Or do you have that covered?
> > 
> > > >
> > 
> > > >
> > 
> > > > --
> > 
> > > > Hamlet D'Arcy
> > 
> > > > ham...@ca...
> > 
> > > >
> > 
> > > >
> > 
> > > >
> > 
> > > >
> > 
> > > > ----- Original Message -----
> > 
> > > > > If I have both CodeNarc and PMD libs in my classpath, I have
> > 
> > > > > problems with one or the other, because both have resources with
> > 
> > > > > the same
> > 
> > > > > name:
> > 
> > > > > e.g., 'rulesets/basic.xml', 'rulesets/design.xml', etc. How
> > > > > about
> > 
> > > > > using a safer resource namespace, like
> > 
> > > > > 'org/codenarc/rulesets/...'?
> > 
> > > > >
> > 
> > > > >
> > 
> > > > > Thanks!
> > 
> > > > > Jason
> > 
> > > > > ------------------------------------------------------------------
> > 
> > > > > ------------ Special Offer-- Download ArcSight Logger for FREE
> > > > > (a
> > 
> > > > > $49 USD value)!
> > 
> > > > > Finally, a world-class log management solution at an even better
> > 
> > > > > price-free!
> > 
> > > > > Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> > 
> > > > > February 28th, so secure your free ArcSight Logger TODAY!
> > 
> > > > > http://p.sf.net/sfu/arcsight-sfd2d
> > 
> > > > > _______________________________________________
> > 
> > > > > Codenarc-user mailing list
> > 
> > > > > Cod...@li...
> > 
> > > > > https://lists.sourceforge.net/lists/listinfo/codenarc-user
> > 
> > >
> > 
> > > ----------------------------------------------------------------------
> > 
> > > -------- Special Offer-- Download ArcSight Logger for FREE (a $49
> > > USD
> > 
> > > value)!
> > 
> > > Finally, a world-class log management solution at an even better
> > 
> > > price-free!
> > 
> > > Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> > 
> > > February 28th, so secure your free ArcSight Logger TODAY!
> > 
> > > http://p.sf.net/sfu/arcsight-sfd2d
> > 
> > > _______________________________________________
> > 
> > > Codenarc-user mailing list
> > 
> > > Cod...@li...
> > 
> > > https://lists.sourceforge.net/lists/listinfo/codenarc-user
> > 
> > >
> > 
> > > ForwardSourceID:NT000F67C6
> > 
> > 
> > 
> > 
> ------------------------------------------------------------------------------
> > 
> > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> > 
> > Finally, a world-class log management solution at an even better
> > price-free!
> > 
> > Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> > February 28th, so secure your free ArcSight Logger TODAY!
> > 
> > http://p.sf.net/sfu/arcsight-sfd2d
> > 
> > _______________________________________________
> > 
> > Codenarc-user mailing list
> > 
> > Cod...@li...
> > 
> > https://lists.sourceforge.net/lists/listinfo/codenarc-user
> 
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
> February 28th, so secure your free ArcSight Logger TODAY! 
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user

> ForwardSourceID:NT000F9A3A     

Re: [Codenarc-developer] Add rule for Condition.wait() methods not called inside a loop?

[Hamlet D. <ham...@ca...>]

I would add a rule, but be conservative about what triggers an error. For instance, we can definitely tell the type of a field. So we know the types of some variables as long as they aren't shadowed. So I would add the rule to the feature list... but wait on implementation. 

I have, in my head, a strategy for determining the type of a reference. So if you have 'varName' you can get the type. However, I have not had time to code this. There are a few rules in the backlog that rely on types to perform work, and there are others that would benefit. Maybe in March I can do this work. 

So, I would add the rule to the backlog. It's a good idea. 

--
Hamlet D'Arcy
ham...@ca...

----- Original Message -----
> We added a rule to ensure that the Object.wait () method is only
> called within a while loop ( WaitOutsideOfWhileLoop ).
> 
> 
> 
> The java.util.concurrent.locks.Condition has a similar “requirement”
> about its await () methods (see the class javadoc).
> 
> 
> 
> If you see a call to wait (), there is no ambiguity about it being the
> wrong wait () method, since it is defined on Object . But the await ()
> methods could catch unintended method invocations (false positives) on
> objects other than Locks .
> 
> 
> 
> So. is it still worth adding a rule for that? I am tempted to think
> so.
> 
> 
> 
> Chris

[Codenarc-developer] Add rule for Condition.wait() methods not called inside a loop?

[Chris M. <chr...@ea...>]

We added a rule to ensure that the Object.wait() method is only called
within a while loop (WaitOutsideOfWhileLoop).

 

The java.util.concurrent.locks.Condition has a similar "requirement" about
its await() methods (see the class javadoc).

 

If you see a call to wait(), there is no ambiguity about it being the wrong
wait() method, since it is defined on Object. But the await() methods could
catch unintended method invocations (false positives) on objects other than
Locks.

 

So. is it still worth adding a rule for that? I am tempted to think so.

 

Chris

[Codenarc-developer] Renamed 3 Avoid* rules

[Chris M. <chr...@ea...>]

FYI, I renamed the 3 new AvoidXXX rules to remove “Avoid”. e.g.
AvoidBusyWait à BusyWait.

Re: [Codenarc-developer] clean up apt files

[Hamlet D'A. <ham...@gm...>]

Thanks... I was wondering why site was failing... not enough to
actually debug and fix it, but wondering none the less!




On Sun, Feb 6, 2011 at 7:04 PM, Chris Mair <chr...@ea...> wrote:
> Hamlet,
>
>
>
> I cleaned up a few issues with the APT files, where I found them:
>
>
>
> (1) Unfortunately, APT is kind of picky about needing blank lines in between
> sections, including before a source code section. So,
>
>
>
>    Example of violations:
>
> --------------------------------------------------
>
>
>
> Needs to be:
>
>
>
>    Example of violations:
>
>
>
> --------------------------------------------------
>
>
>
>
>
> (2) Likewise:
>
>
>
>   <New in CodeNarc 0.13>
>
>   Busy waiting (forcing a <<<Thread.sleep()>>> while waiting on a condition)
> should be avoided. Prefer using the gate and
>
>
>
> Needs to be:
>
>
>
>   <New in CodeNarc 0.13>
>
>
>
>   Busy waiting (forcing a <<<Thread.sleep()>>> while waiting on a condition)
> should be avoided. Prefer using the gate and
>
>
>
>
>
> (3) URL links should be surrounded in {{{ .. }}} or {{{url}label}}
>
>
>
> Chris
>
> ------------------------------------------------------------------------------
> The modern datacenter depends on network connectivity to access resources
> and provide services. The best practices for maximizing a physical server's
> connectivity to a physical network are well understood - see how these
> rules translate into the virtual world?
> http://p.sf.net/sfu/oracle-sfdevnlfb
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
>
>



-- 
Hamlet D'Arcy
ham...@gm...

[Codenarc-developer] clean up apt files

[Chris M. <chr...@ea...>]

Hamlet,

 

I cleaned up a few issues with the APT files, where I found them:

 

(1) Unfortunately, APT is kind of picky about needing blank lines in between
sections, including before a source code section. So,

 

   Example of violations:

--------------------------------------------------

 

Needs to be:

 

   Example of violations:

 

--------------------------------------------------

 

 

(2) Likewise: 

 

  <New in CodeNarc 0.13>

  Busy waiting (forcing a <<<Thread.sleep()>>> while waiting on a condition)
should be avoided. Prefer using the gate and

 

Needs to be:

 

  <New in CodeNarc 0.13>

 

  Busy waiting (forcing a <<<Thread.sleep()>>> while waiting on a condition)
should be avoided. Prefer using the gate and

 

 

(3) URL links should be surrounded in {{{ .. }}} or {{{url}label}}

 

Chris

[Codenarc-developer] Grails CodeNarc Plugin updated (0.9)

[Chris M. <chr...@ea...>]

The Grails CodeNarc Plugin has been updated to include CodeNarc 0.12.

 

See the Grails CodeNarc Plugin <http://grails.org/plugin/codenarc>  page.

Re: [Codenarc-developer] sort the base-messages.properties file

[Chris M. <chr...@ea...>]

Yeah, that sounds reasonable.

-----Original Message-----
From: Hamlet D'Arcy [mailto:ham...@gm...] 
Sent: Wednesday, January 19, 2011 3:43 PM
To: Cod...@li...
Subject: [Codenarc-developer] sort the base-messages.properties file

Can we get rid of the comments in the codenarc-base-messages.properties
file?
That way we could just sort the file alphabetically. Sorting it manually for
every new rule is kinda a PITA.

--
Hamlet D'Arcy
ham...@gm...

----------------------------------------------------------------------------
--
Protect Your Site and Customers from Malware Attacks Learn about various
malware tactics and how to avoid them. Understand malware threats, the
impact they can have on your business, and how you can protect your company
and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Codenarc-developer mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-developer

[Codenarc-developer] [ANN] Announcing CodeNarc 0.12

[<chr...@wa...>]

The CodeNarc Team is proud to announce the release of version 0.12.

CodeNarc is a static analysis tool for Groovy source code.  Version 0.12
adds 36 new rules to the product (bringing the total to 160+ rules). Try it
out on the CodeNarc web console, running on Google App Engine.

New Features
      Improved performance of the CodeNarc Ant Task (by multi-threading
      source code analysis) - Feature #3150044
      Add support for message parameter substitution in Rule descriptions -
      Feature #3133988

New Rules

Basic Rules
      CompareToWithoutComparable rule (basic) - Adds violation if you
      implement a compare method without implementing the Comparable
      interface
      ExplicitGarbageCollection rule (basic) - Feature #3106689 - Adds a
      violation if you try to manually trigger a garbage collection run
      ConfusingTernary rule (basic) - Feature #3158945 - Adds violation if
      you use unnecessary negation within a ternary expression
      SimpleDateFormatMissingLocale rule (basic) - Feature #3160227 - Adds
      a violation if SimpleDateFormat is used without a Locale.
Design Rules
      AbstractClassWithoutAbstractMethod rule (design) - Feature #3160204 -
      Adds a violation when an abstract class does not contain any abstract
      methods
      CloseWithoutCloseable rule (design) - Feature #3138445 - Adds a
      violation if you implement a close method without imlpementing the
      Closeable interface
      FinalClassWithProtectedMember rule (design) - Feature #3137650 - Adds
      violation if you have a protected member in a final class
      ConstantsOnlyInterface rule (design) - Feature #3159134 - Adds
      violation if an interface contains constants but no methods
      EmptyMethodInAbstractClass rule (design) - Feature #3159180 - Adds
      violation if an abstract class contains an empty method
Exceptions Rules
      CatchArrayIndexOutOfBoundsException rule (exceptions)  - Feature
      #3122979 - Adds violation if you explicitly catch
      ArrayIndexOutOfBoundsException
      CatchIndexOutOfBoundsException rule (exceptions) - Feature #3122979 -
      Adds violation if you explicitly catch IndexOutOfBoundsException
      MissingNewInThrowStatement (exceptions) - Feature #3140762  -Adds a
      violation if a throw statement is used to throw a class literal
Generic Rules
      RequiredString rule (generic) - Feature #3122980 - Adds violation if
      a user-defined String is not found. For example, a copyright notice
      may be required.
JUnit Rules
      UseAssertFalseInsteadOfNegation rule (junit) - Feature #3114728 -
      Adds violation if JUnit's assertEquals is used with the boolean
      literal 'false'
      UseAssertTrueInsteadOfNegation rule (junit) - Feature #3114728 - Adds
      violation if JUnit's assertEquals is used with the boolean literal
      'true'
      JUnitTestMethodWithoutAssert. rule (junit) - Feature #3111443 - Adds
      violation if a JUnit test method contains no assert statements
Logging Rules
      LoggerForDifferentClass rule (logging) - Feature #3114736 - Adds
      violation if a Logger is created based on a Class that is not the
      enclosing class
      LoggerWithWrongModifiers rule (logging) - Adds violation if a Logger
      is not private, final, and static.
      LoggingSwallowsStacktrace rule (logging) - Adds violation if a log
      statement logs an exception without the accompanying stack trace
      MultipleLoggers rule (logging) - Adds a violation if a class declares
      more than one logger field
Unnecessary Code Rules
      UnnecessaryBigDecimalInstantiation rule (unnecessary) - Adds a
      violation for explicit instantiation of BigDecimal
      UnnecessaryBigIntegerInstantiation rule (unnecessary) - Adds a
      violation for explicit instantiation of BigInteger
      UnnecessaryCatchBlock rule (unnecessary) - Feature #3107168 - Adds
      violation if catch block does nothing but throw original exception
      UnnecessaryDoubleInstantiation rule (unnecessary) - Adds a violation
      for explicit instantiation of Double
      UnnecessaryFloatInstantiation rule (unnecessary) - Adds a violation
      for explicit instantiation of Float
      UnnecessaryInstantiationToGetClass (unnecessary) - Feature #3158935 -
      Adds a violation if a new instance is created in order to invoke
      getClass()
      UnnecessaryIntegerInstantiation rule (unnecessary) - Adds a violation
      for explicit instantiation of Integer
      UnnecessaryLongInstantiation rule (unnecessary) - Adds a violation
      for explicit instantiation of Long
      UnnecessaryNullCheck Rule (unnecessary) - Feature #3160184 - Adds
      violation when a null-safe dereference can be used instead of an
      explicit null check
      UnnecessaryNullCheckBeforeInstanceOf rule (unnecessary) - Feature
      #3159274 - Adds a violation for an unnecessary null check before
      using the instanceof operator
      UnnecessaryObjectReferences rule (unnecessary) - Feature #3107838 -
      Adds a violation for a chain of setters being invoked, which can be
      converted into a with or identity block
      UnnecessaryCallForLastElement rule (unnecessary) - Feature #3107884 -
      Adds violation if accessing the last element of a list without using
      the .last() method or -1th index
      UnnecessaryCollectCall rule (unnecessary) - Feature #3110317 - Adds a
      violation if a collect method call can be replaced with the spread
      operator
      UnnecessaryCatchBlock rule  (unnecessary)- Feature #3110318 - Adds a
      violation if a catch block does nothing but throw the original
      exception
      UnnecessaryGetter rule  (unnecessary)- Feature #3110321 - Adds a
      violation if a a getter method is called explicitly instead of using
      property syntax
Unused Code Rules
      UnusedPrivateMethodParameter rule (unused) - Feature #3151598 - Adds
      a violation if the parameter to a private method is never used within
      that method

Bug Fixes
      Fix Bug #3127967 DuplicateImportRule: Fix for Groovy 1.7. Resort to
      parsing source code.
      Fix Bug #3146678: UnnecessaryGetter false positive, e.g. def allPaths
      = resultsMap.keySet()  keySet() can probably be rewritten as set.
      Fix Bug #3111189: "StatelessClassRule - Honor @Immutable".
      Fix Bug #3111181: "UnnecessaryIfStatement - misses if without
      explicit return".
      Fix Bug #3108126: "assertNoViolations still passes when compile
      fails"
      Fix Bug #3111439: "Synchronized on getClass() rule gives double
      warnings".
      Fix Bug #3111438: "Lines with annotations have the wrong source
      line".
      Fix Bug #3109909: DuplicateStringLiteralRule: Add "" as default
      ignoreStringLiteral.
      Fix Bug #3110308: "Rules to catch null returns ignore ternary
      expressions".
      Fix Bug #3110303: "ExplicitCallToXMethod rules should ignore spread
      statements".
      Fix Bug #3109917: "DuplicateStringLiteralRule - enum names".
      Fix Bug #3109628: "Exceptions are thrown with CodeNarc v0.11" –
      "GString as map key checking classes that do not exist yet” and
      “unnecessary ctor rule breaks for anonymous classes".

Potential Breaking Changes
      Moved the existing StringInstantiation and BooleanInstantiation rules
      from the Basic ruleset into the Unnecessary ruleset.Also renamed the
      rules to UnnecessaryStringInstantiationRule and
      UnnecessaryBooleanInstantiation.Likewise, the rule classes were moved
      from the org.codenarc.rule.basic package into
      org.codenarc.rule.unnecessary.NOTE: This should only affect users if
            You configured one of these rules specifically by rule name or
            by class name within a custom ruleset
            You configured one of these rules (by rule name) within
            "codenarc.properties"
            You configured one of these rules (by rule name) within a
            @SuppressWarnings annotation
            You configured one of these rules (by rule name) within
            "codenarc-message.properties".
      Removed deprecated applyToFilenames and doNotApplyToFilenames
      properties of AbstractRule.

Other Changes
      UnnecessaryIfStatementRule: Expand the rule to also catch if/else
      statements that contain only single constant/literal expressions for
      the if and/or else blocks, if the if is not the last statement in the
      block.
      Feature #3108153: Expand ReturnNull* rules to catch elvis operators
      Feature #3111442: "add better error messages to the
      ReturnsNull*Rules"
      Feature #3111440: "added better violation messages to
      BigDecimalInstantiationRule, BooleanInstantiationRule, and
      StringInstantiationRule".
      Add isValid() to SourceCode (and AbstractSourceCode).


Vote for IDEA Support for CodeNarc


Visit the CodeNarc Home Page
ForwardSourceID:NT000CEB6A

[Codenarc-developer] sort the base-messages.properties file

[Hamlet D'A. <ham...@gm...>]

Can we get rid of the comments in the codenarc-base-messages.properties file?
That way we could just sort the file alphabetically. Sorting it
manually for every new rule is kinda a PITA.

-- 
Hamlet D'Arcy
ham...@gm...

[Codenarc-developer] codenarc in maven repo?

[Hamlet D'A. <ham...@gm...>]

How does the codenarc Jar get into a Maven repository? Is that
automatic somehow?

-- 
Hamlet D'Arcy
ham...@gm...

Re: [Codenarc-developer] 0.12 release planning

[Hamlet D'A. <ham...@gm...>]

> If possible, I'd like to resolve that UnnecessaryNullCheck issue (see previous email).

It is done.

--
Hamlet D'Arcy
ham...@gm...



On Tue, Jan 18, 2011 at 6:47 PM, <chr...@wa...> wrote:
>
> Wonderful. I am done with my development, as well. I appreciate you keeping the change log and APT files up-to-date.
>
> If possible, I'd like to resolve that UnnecessaryNullCheck issue (see previous email). But other than that, we are ready. Your checklist looks good. I am quite pleased with the contents of this release.
>
> Chris
>
>
> Hamlet DArcy <ham...@ca...>
>
> 01/18/2011 01:59 AM
>
> To
> cod...@li...
> cc
> Subject
> [Codenarc-developer] 0.12 release planning
>
>
>
>
>
> I'm done with all my new rules for the 0.12 release. We have almost 40 new ones and it is a good batch. The CHANGELOG.txt file is updated and I've tried to be better about making the .apt files more informative.
>
> On our todo list is:
> 1. Run Codenarc against Grails & other projects (chris)
> 2. Update and test codenarc-webconsole (hamlet)
> 3. Write a 0.12 blog post (hamlet)
> 4. Write release announcement (chris)
> And post release:
> 5. Update Griffon plugin (hamlet)
> 6. File Gradle JIRA to update plugin (hamlet)
> 7. Update Grails plugin (chris)
> 8. Send release announcement
>
> How much more development do you have planned for 0.12?
> Are there other tasks for 0.12?
>
> --
> Hamlet D'Arcy
> ham...@ca...
>
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
>
> ForwardSourceID:NT000F5FEA
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
>

Re: [Codenarc-developer] 0.12 release planning

[<chr...@wa...>]

Wonderful. I am done with my development, as well. I appreciate you 
keeping the change log and APT files up-to-date.

If possible, I'd like to resolve that UnnecessaryNullCheck issue (see 
previous email). But other than that, we are ready. Your checklist looks 
good. I am quite pleased with the contents of this release.

Chris



Hamlet DArcy <ham...@ca...> 
01/18/2011 01:59 AM


To
cod...@li...
cc

Subject
[Codenarc-developer] 0.12 release planning







I'm done with all my new rules for the 0.12 release. We have almost 40 new 
ones and it is a good batch. The CHANGELOG.txt file is updated and I've 
tried to be better about making the .apt files more informative. 

On our todo list is: 
1. Run Codenarc against Grails & other projects (chris)
2. Update and test codenarc-webconsole (hamlet)
3. Write a 0.12 blog post (hamlet) 
4. Write release announcement (chris)
And post release: 
5. Update Griffon plugin (hamlet)
6. File Gradle JIRA to update plugin (hamlet)
7. Update Grails plugin (chris)
8. Send release announcement

How much more development do you have planned for 0.12? 
Are there other tasks for 0.12? 

--
Hamlet D'Arcy
ham...@ca...


------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Codenarc-developer mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-developer

ForwardSourceID:NT000F5FEA 

[Codenarc-developer] UnnecessaryNulCheck - bug?

[<chr...@wa...>]

Hamlet,

I am running the CodeNarc snapshot release jar against a bunch of projects 
at work. I came across what seems like a bug in UnnecessaryNullCheck.

This code:

            if (cmd.autoDefUseOrderInd && cmd.allMTsBottom != null) { // 
Line 128
                cmd.errors.reject("message.code", "All the auto deferral 
MTs must be included in the order list.");
            }

produces:

Rule Name
Priority
Line #
Source Line / Message
UnnecessaryNullCheck
2
128
[SRC]if (cmd.autoDefUseOrderInd && cmd.allMTsBottom != null) {
[MSG]The expression (cmd.autoDefUseOrderInd && (cmd.allMTsBottom != null)) 
can be simplified to (cmd.autoDefUseOrderInd)
UnnecessaryNullCheck
2
128
[SRC]if (cmd.autoDefUseOrderInd && cmd.allMTsBottom != null) {
[MSG]The expression (cmd.autoDefUseOrderInd && (cmd.allMTsBottom != null)) 
can be simplified to (cmd.autoDefUseOrderInd)

I don't think that should be a violation, and I'm not sure why it shows up 
twice.

Thanks.
Chris

[Codenarc-developer] 0.12 release planning

[Hamlet D. <ham...@ca...>]

I'm done with all my new rules for the 0.12 release. We have almost 40 new ones and it is a good batch. The CHANGELOG.txt file is updated and I've tried to be better about making the .apt files more informative. 

On our todo list is: 
1. Run Codenarc against Grails & other projects (chris)
2. Update and test codenarc-webconsole (hamlet)
3. Write a 0.12 blog post (hamlet) 
4. Write release announcement (chris)
And post release: 
5. Update Griffon plugin (hamlet)
6. File Gradle JIRA to update plugin (hamlet)
7. Update Grails plugin (chris)
8. Send release announcement

How much more development do you have planned for 0.12? 
Are there other tasks for 0.12? 

--
Hamlet D'Arcy
ham...@ca...

Re: [Codenarc-developer] New logo

[Hamlet D. <ham...@ca...>]

Looks nice. We can call it the "CodeNarc Grue". 

Your previous grammar suggestion was correct, by the way. The correct grammar is "Fewer Bugs, Better Code". We could change it to that, but it sounds more formal. 

--
Hamlet D'Arcy
ham...@ca...

----- Original Message -----
> Hamlet,
> 
> 
> 
> I have checked in the changes to use the new logo. It is the “new1”
> image that you sent, but shrunk down to 140 pixels.
> 
> 
> 
> I spent a while playing around with fonts and colors for the text. But
> in an informal survey of family and friends, they all liked the
> original design, colors and fonts, which was quite fine with me.
> 
> 
> 
> A couple of them said that they might not have guessed it was an
> armadillo, but they liked the image and the design and thought it was
> a neat theme. And in any case, whatever it was, it was something that
> ate bugs!
> 
> 
> 
> Thanks again for getting that all together.
> 
> 
> 
> Chris
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how
> you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer

Re: [Codenarc-developer] ExplicitHashMapInstantiation - copy of Map

[Hamlet D. <ham...@ca...>]

> For ExplicitHashMapInstantiation , should there be a violation if you
> pass in a Map (or any variable) to the constructor of HashMap? I'm
> thinking not. Is there a better, idiomatic way to make a copy of a
> Map?

Hmmm. You are right. That sucks. I guess we should limit the rule to look for only parameterless instantiations. 


--
Hamlet D'Arcy
ham...@ca...

----- Original Message -----
> Hamlet,
> 
> For ExplicitHashMapInstantiation , should there be a violation if you
> pass in a Map (or any variable) to the constructor of HashMap? I'm
> thinking not. Is there a better, idiomatic way to make a copy of a
> Map?
> 
> 
> 
> Rule Name
> Priority
> Line #
> Source Line / Message
> ExplicitHashMapInstantiation
> 4
> 24 [SRC] def copyOfMap = new HashMap(map)
> 
> 
> def myMethod(Map map) {
> def copyOfMap = new HashMap(map)
> // ...
> }
> 
> 
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how
> you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer

[Codenarc-developer] New logo

[Chris M. <chr...@ea...>]

Hamlet,

 

I have checked in the changes to use the new logo. It is the "new1" image
that you sent, but shrunk down to 140 pixels.

 

I spent a while playing around with fonts and colors for the text. But in an
informal survey of family and friends, they all liked the original design,
colors and fonts, which was quite fine with me. 

 

A couple of them said that they might not have guessed it was an armadillo,
but they liked the image and the design and thought it was a neat theme. And
in any case, whatever it was, it was something that ate bugs!

 

Thanks again for getting that all together.

 

Chris

[Codenarc-developer] ExplicitHashMapInstantiation - copy of Map

[<chr...@wa...>]

Hamlet,

For ExplicitHashMapInstantiation, should there be a violation if you pass 
in a Map (or any variable) to the constructor of HashMap? I'm thinking 
not. Is there a better, idiomatic way to make a copy of a Map?



Rule Name
Priority
Line #
Source Line / Message
ExplicitHashMapInstantiation
4
24
[SRC]def copyOfMap = new HashMap(map)


        def myMethod(Map map) {
                def copyOfMap = new HashMap(map)
                // ...
        }

Re: [Codenarc-developer] UnnecessaryIntegerInstantiation message

[Hamlet D. <ham...@ca...>]

Sure, feel free to clarify the message. 
I suggest "Can probably be rewritten as 1115.37 or 1115.37G" so that developers learn the G suffix forces a type case. Some for "i". 

--
Hamlet D'Arcy
ham...@ca...

----- Original Message -----
> Hamlet,
> 
> In the violation message for the UnnecessaryBigDecimalInstantiation
> rule, is the "G" suffix necessary? e.g.
> 
> source: BigDecimal amount = new BigDecimal("1115.37")
> message: Can probably be rewritten as 1115.37G
> 
> since Groovy will treat 1115.37 as a BigDecimal by default.
> 
> Likewise, the message for UnnecessaryIntegerInstantiation includes an
> "i" suffix after the number.
> 
> Can we remove them or at least further qualify that message. I can
> just see developers adding unnecessary "G" and "i" all over the place.
> 
> Chris
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how
> you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer