codenarc-user — CodeNarc Users

Re: [Codenarc-user] Question about Using New Size Features

[Corum, M. <mc...@rg...>]

This is what is confusing me.  I’m using Grails so I’m not using (as in coding) any Ant task that I know of.  Where would I put the rulesetfiles = MyRuleSet.groovy line?  Would that go into BuildConfig.groovy or application.properties or somewhere else?

 

Thanks,

 

Mike

 

From: chr...@wa... [mailto:chr...@wa...] 
Sent: Monday, November 15, 2010 3:36 PM
To: Corum, Michael
Cc: cod...@li...
Subject: RE: [Codenarc-user] Question about Using New Size Features

 


If you have included the "rulsets/size.xml" in your list of rulesets, then yes, you can do this configuration within "codenarc.properties". 

If you want to customize your rules and/or pull in from lots of different rulesets, then it makes sense to go ahead and create your own custom ruleset. 

Here is an example that just pulls in the basic and size rulesets. It turns off the ExplicitCallToMultiplyMethod and ExplicitArrayListInstantiation rules and configures maxLines property of the MethodSize rule. If you call this file "MyRuleSet.groovy" and put it somewhere on your classpath, then you can set your rulesetfiles (if using the Ant task) to "MyRuleSet.groovy". 

ruleset {

   ruleset('rulesets/basic.xml') {
       ExplicitCallToMultiplyMethod {
           enabled = false
       } 
        ExplicitArrayListInstantiation {
           enabled = false
       } 
   }

   ruleset('rulesets/size.xml') {
       MethodSize {
           maxLines = 8
       }
   }
}

Chris 



"Corum, Michael" <mc...@rg...> 

11/15/2010 04:24 PM 

To

<chr...@wa...> 

cc

<cod...@li...> 

Subject

RE: [Codenarc-user] Question about Using New Size Features

 

		




On the MethodSize thing, is there a way to do that only in the codenarc.properties file?  Or do I have to set up a rulesets/size.xml?  Can you provide example config files for this?  I wasn’t able to figure that method out from the documentation so I went with the easier-to-understand codenarc.properties file. 
  
Thanks, 
  
Mike 
  
From: chr...@wa... [mailto:chr...@wa...] 
Sent: Monday, November 15, 2010 3:22 PM
To: Corum, Michael
Cc: cod...@li...
Subject: Re: [Codenarc-user] Question about Using New Size Features 
  

Mike, 

The doNotApplyToClassNames property should specify the name of the class(es) containing the code that you want to ignore.  So, set it to the name of the class containing the calls to multiply(). 

You can specify either a single class name or a comma-separated list of names. The names may optionally contain wildcard characters ('*' or '?'). The wildcard character '*' matches a sequence of zero or more characters in the input string. The wildcard character '?' matches exactly one character in the input string. Each class name(s) can be either a fully-qualified class name (including the package) or else a class name without a package. 

The ExplicitCallToMultiplyMethod rule and other similar methods are intended to encourage use of the corresponding operators -- in this case '*'. The code a.multiply(b) will produce exactly the same results under the covers as a *  b. That being said, if you disagree with that convention, or just don't think it is important, feel free to disable the rule, as always. 

The rule configuration MethodSize.maxLines=8  is only relevant if you include the MethodSize rule in your ruleset. Are you including the "Size" ruleset ("rulesets/size.xml") or are you including that rule class directly when you configure a custom ruleset? 

Chris 

"Corum, Michael" <mc...@rg...> 

11/15/2010 04:12 PM 

 

To

<cod...@li...> 

cc

	
Subject

Re: [Codenarc-user] Question about Using New Size Features


  

 

		





Sorry, I sent this before my test suite finished all the way.  It didn’t work.  Here is what I have in codenarc.properties: 
 
ExplicitCallToMultiplyMethod.doNotApplyToClassNames=java.lang.String,groovy.lang.GString 
 
It still flags any use of multiple on a string or GString. 
 
Any help would be much appreciated. 
 
Mike 
 
From: Corum, Michael [mailto:mc...@rg...] 
Sent: Monday, November 15, 2010 3:11 PM
To: cod...@li...
Subject: Re: [Codenarc-user] Question about Using New Size Features 
 
Please ignore this question.  It was a GString rather than a java string.  Once I put that in, this one worked. 
 
I’m still interested in the question of how to get the new features that were added in 0.11 to work properly.  For instance, I put MethodSize.maxLines=8 in my codenarc.properties file and it isn’t catching any long methods. 
 
Thanks, 
 
Mike Corum 
 
 
From: Corum, Michael [mailto:mc...@rg...] 
Sent: Monday, November 15, 2010 2:56 PM
To: cod...@li...
Subject: Re: [Codenarc-user] Question about Using New Size Features 
 
Since upgrading from 0.6.1 to 0.11, I’m seeing lots of new violations.  Many of them don’t really make sense.  One example is the use of the “multiply” method on a string.  The idea that this is a violation makes no sense.  Here is some example code from a test where I was testing a long string: 
 
def longString = "Long String!".multiply(201) 
 
CodeNarc flags this with ExplicitCallToMultiplyMethod.  Since using multiply is correct in this case (in fact, the recommended Groovy way of doing it), I wanted to turn this one off.  So, I added the following line to codenarc.properties: 
 
ExplicitCallToMultiplyMethod.doNotApplyToClassNames=java.lang.String 
 
However, after running codenarc again, it still flags that line of code with ExplicitCallToMultiplyMethod.  What can I do to make this work correctly? 
 
 
Michael Corum   
Consultant 
Software Architect 
 
RGA Reinsurance Company 
1370 Timerlake Manor Parkway 
Saint Louis, MO  63017 
T 636.736.7066   
 
www.rgare.com 
 
_____________________________ 
 
This message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by telephone and return the original message to its sender. Thank you for your cooperation and assistance.------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev_______________________________________________
Codenarc-user mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-user

ForwardSourceID:NT000CECDE     
ForwardSourceID:NT000CECFA     

Re: [Codenarc-user] Question about Using New Size Features

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

If you have included the "rulsets/size.xml" in your list of rulesets, then 
yes, you can do this configuration within "codenarc.properties".

If you want to customize your rules and/or pull in from lots of different 
rulesets, then it makes sense to go ahead and create your own custom 
ruleset.

Here is an example that just pulls in the basic and size rulesets. It 
turns off the ExplicitCallToMultiplyMethod and 
ExplicitArrayListInstantiation rules and configures maxLines property of 
the MethodSize rule. If you call this file "MyRuleSet.groovy" and put it 
somewhere on your classpath, then you can set your rulesetfiles (if using 
the Ant task) to "MyRuleSet.groovy".

ruleset {

    ruleset('rulesets/basic.xml') {
        ExplicitCallToMultiplyMethod {
            enabled = false
        }
        ExplicitArrayListInstantiation {
            enabled = false
        } 
    }

    ruleset('rulesets/size.xml') {
        MethodSize {
            maxLines = 8
        }
    }
}

Chris



"Corum, Michael" <mc...@rg...> 
11/15/2010 04:24 PM


To
<chr...@wa...>
cc
<cod...@li...>
Subject
RE: [Codenarc-user] Question about Using New Size Features






On the MethodSize thing, is there a way to do that only in the 
codenarc.properties file?  Or do I have to set up a rulesets/size.xml?  
Can you provide example config files for this?  I wasn’t able to figure 
that method out from the documentation so I went with the 
easier-to-understand codenarc.properties file.
 
Thanks,
 
Mike
 
From: chr...@wa... [mailto:chr...@wa...] 
Sent: Monday, November 15, 2010 3:22 PM
To: Corum, Michael
Cc: cod...@li...
Subject: Re: [Codenarc-user] Question about Using New Size Features
 

Mike, 

The doNotApplyToClassNames property should specify the name of the 
class(es) containing the code that you want to ignore.  So, set it to the 
name of the class containing the calls to multiply(). 

You can specify either a single class name or a comma-separated list of 
names. The names may optionally contain wildcard characters ('*' or '?'). 
The wildcard character '*' matches a sequence of zero or more characters 
in the input string. The wildcard character '?' matches exactly one 
character in the input string. Each class name(s) can be either a 
fully-qualified class name (including the package) or else a class name 
without a package. 

The ExplicitCallToMultiplyMethod rule and other similar methods are 
intended to encourage use of the corresponding operators -- in this case 
'*'. The code a.multiply(b) will produce exactly the same results under 
the covers as a *  b. That being said, if you disagree with that 
convention, or just don't think it is important, feel free to disable the 
rule, as always. 

The rule configuration MethodSize.maxLines=8  is only relevant if you 
include the MethodSize rule in your ruleset. Are you including the "Size" 
ruleset ("rulesets/size.xml") or are you including that rule class 
directly when you configure a custom ruleset? 

Chris 


"Corum, Michael" <mc...@rg...> 
11/15/2010 04:12 PM 


To
<cod...@li...> 
cc

Subject
Re: [Codenarc-user] Question about Using New Size Features
 








Sorry, I sent this before my test suite finished all the way.  It didn’t 
work.  Here is what I have in codenarc.properties: 
  
ExplicitCallToMultiplyMethod.doNotApplyToClassNames=java.lang.String,groovy.lang.GString 

  
It still flags any use of multiple on a string or GString. 
  
Any help would be much appreciated. 
  
Mike 
  
From: Corum, Michael [mailto:mc...@rg...] 
Sent: Monday, November 15, 2010 3:11 PM
To: cod...@li...
Subject: Re: [Codenarc-user] Question about Using New Size Features 
  
Please ignore this question.  It was a GString rather than a java string. 
Once I put that in, this one worked. 
  
I’m still interested in the question of how to get the new features that 
were added in 0.11 to work properly.  For instance, I put 
MethodSize.maxLines=8 in my codenarc.properties file and it isn’t catching 
any long methods. 
  
Thanks, 
  
Mike Corum 
  
  
From: Corum, Michael [mailto:mc...@rg...] 
Sent: Monday, November 15, 2010 2:56 PM
To: cod...@li...
Subject: Re: [Codenarc-user] Question about Using New Size Features 
  
Since upgrading from 0.6.1 to 0.11, I’m seeing lots of new violations. 
Many of them don’t really make sense.  One example is the use of the 
“multiply” method on a string.  The idea that this is a violation makes no 
sense.  Here is some example code from a test where I was testing a long 
string: 
  
def longString = "Long String!".multiply(201) 
  
CodeNarc flags this with ExplicitCallToMultiplyMethod.  Since using 
multiply is correct in this case (in fact, the recommended Groovy way of 
doing it), I wanted to turn this one off.  So, I added the following line 
to codenarc.properties: 
  
ExplicitCallToMultiplyMethod.doNotApplyToClassNames=java.lang.String 
  
However, after running codenarc again, it still flags that line of code 
with ExplicitCallToMultiplyMethod.  What can I do to make this work 
correctly? 
  
  
Michael Corum   
Consultant 
Software Architect 
  
RGA Reinsurance Company 
1370 Timerlake Manor Parkway 
Saint Louis, MO  63017 
T 636.736.7066   
  
www.rgare.com 
  
_____________________________ 
  
This message is intended only for the use of the individual or entity to 
which it is addressed, and may contain information that is privileged, 
confidential, and exempt from disclosure under applicable law. If the 
reader of this message is not the intended recipient, or the employee or 
agent responsible for delivering the message to the intended recipient, 
you are hereby notified that any dissemination, distribution, or copying 
of this communication is strictly prohibited. If you have received this 
communication in error, please notify us immediately by telephone and 
return the original message to its sender. Thank you for your cooperation 
and assistance.
------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev_______________________________________________

Codenarc-user mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-user

ForwardSourceID:NT000CECDE     
ForwardSourceID:NT000CECFA 

Re: [Codenarc-user] Question about Using New Size Features

[Corum, M. <mc...@rg...>]

On the MethodSize thing, is there a way to do that only in the codenarc.properties file?  Or do I have to set up a rulesets/size.xml?  Can you provide example config files for this?  I wasn’t able to figure that method out from the documentation so I went with the easier-to-understand codenarc.properties file.

 

Thanks,

 

Mike

 

From: chr...@wa... [mailto:chr...@wa...] 
Sent: Monday, November 15, 2010 3:22 PM
To: Corum, Michael
Cc: cod...@li...
Subject: Re: [Codenarc-user] Question about Using New Size Features

 


Mike, 

The doNotApplyToClassNames property should specify the name of the class(es) containing the code that you want to ignore.  So, set it to the name of the class containing the calls to multiply(). 

You can specify either a single class name or a comma-separated list of names. The names may optionally contain wildcard characters ('*' or '?'). The wildcard character '*' matches a sequence of zero or more characters in the input string. The wildcard character '?' matches exactly one character in the input string. Each class name(s) can be either a fully-qualified class name (including the package) or else a class name without a package. 

The ExplicitCallToMultiplyMethod rule and other similar methods are intended to encourage use of the corresponding operators -- in this case '*'. The code a.multiply(b) will produce exactly the same results under the covers as a *  b. That being said, if you disagree with that convention, or just don't think it is important, feel free to disable the rule, as always. 

The rule configuration MethodSize.maxLines=8  is only relevant if you include the MethodSize rule in your ruleset. Are you including the "Size" ruleset ("rulesets/size.xml") or are you including that rule class directly when you configure a custom ruleset? 

Chris 



"Corum, Michael" <mc...@rg...> 

11/15/2010 04:12 PM 

To

<cod...@li...> 

cc

	
Subject

Re: [Codenarc-user] Question about Using New Size Features

 

		




Sorry, I sent this before my test suite finished all the way.  It didn’t work.  Here is what I have in codenarc.properties: 
  
ExplicitCallToMultiplyMethod.doNotApplyToClassNames=java.lang.String,groovy.lang.GString 
  
It still flags any use of multiple on a string or GString. 
  
Any help would be much appreciated. 
  
Mike 
  
From: Corum, Michael [mailto:mc...@rg...] 
Sent: Monday, November 15, 2010 3:11 PM
To: cod...@li...
Subject: Re: [Codenarc-user] Question about Using New Size Features 
  
Please ignore this question.  It was a GString rather than a java string.  Once I put that in, this one worked. 
  
I’m still interested in the question of how to get the new features that were added in 0.11 to work properly.  For instance, I put MethodSize.maxLines=8 in my codenarc.properties file and it isn’t catching any long methods. 
  
Thanks, 
  
Mike Corum 
  
  
From: Corum, Michael [mailto:mc...@rg...] 
Sent: Monday, November 15, 2010 2:56 PM
To: cod...@li...
Subject: Re: [Codenarc-user] Question about Using New Size Features 
  
Since upgrading from 0.6.1 to 0.11, I’m seeing lots of new violations.  Many of them don’t really make sense.  One example is the use of the “multiply” method on a string.  The idea that this is a violation makes no sense.  Here is some example code from a test where I was testing a long string: 
  
def longString = "Long String!".multiply(201) 
  
CodeNarc flags this with ExplicitCallToMultiplyMethod.  Since using multiply is correct in this case (in fact, the recommended Groovy way of doing it), I wanted to turn this one off.  So, I added the following line to codenarc.properties: 
  
ExplicitCallToMultiplyMethod.doNotApplyToClassNames=java.lang.String 
  
However, after running codenarc again, it still flags that line of code with ExplicitCallToMultiplyMethod.  What can I do to make this work correctly? 
  
  
Michael Corum   
Consultant 
Software Architect 
  
RGA Reinsurance Company 
1370 Timerlake Manor Parkway 
Saint Louis, MO  63017 
T 636.736.7066   
  
www.rgare.com 
  
_____________________________ 
  
This message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by telephone and return the original message to its sender. Thank you for your cooperation and assistance.------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev_______________________________________________
Codenarc-user mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-user

ForwardSourceID:NT000CECDE     

Re: [Codenarc-user] Question about Using New Size Features

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

Mike,

The doNotApplyToClassNames property should specify the name of the 
class(es) containing the code that you want to ignore.  So, set it to the 
name of the class containing the calls to multiply(). 

You can specify either a single class name or a comma-separated list of 
names. The names may optionally contain wildcard characters ('*' or '?'). 
The wildcard character '*' matches a sequence of zero or more characters 
in the input string. The wildcard character '?' matches exactly one 
character in the input string. Each class name(s) can be either a 
fully-qualified class name (including the package) or else a class name 
without a package.

The ExplicitCallToMultiplyMethod rule and other similar methods are 
intended to encourage use of the corresponding operators -- in this case 
'*'. The code a.multiply(b) will produce exactly the same results under 
the covers as a *  b. That being said, if you disagree with that 
convention, or just don't think it is important, feel free to disable the 
rule, as always.

The rule configuration MethodSize.maxLines=8  is only relevant if you 
include the MethodSize rule in your ruleset. Are you including the "Size" 
ruleset ("rulesets/size.xml") or are you including that rule class 
directly when you configure a custom ruleset?

Chris



"Corum, Michael" <mc...@rg...> 
11/15/2010 04:12 PM


To
<cod...@li...>
cc

Subject
Re: [Codenarc-user] Question about Using New Size Features






Sorry, I sent this before my test suite finished all the way.  It didn’t 
work.  Here is what I have in codenarc.properties:
 
ExplicitCallToMultiplyMethod.doNotApplyToClassNames=java.lang.String,groovy.lang.GString
 
It still flags any use of multiple on a string or GString.
 
Any help would be much appreciated.
 
Mike
 
From: Corum, Michael [mailto:mc...@rg...] 
Sent: Monday, November 15, 2010 3:11 PM
To: cod...@li...
Subject: Re: [Codenarc-user] Question about Using New Size Features
 
Please ignore this question.  It was a GString rather than a java string. 
Once I put that in, this one worked.
 
I’m still interested in the question of how to get the new features that 
were added in 0.11 to work properly.  For instance, I put 
MethodSize.maxLines=8 in my codenarc.properties file and it isn’t catching 
any long methods.
 
Thanks,
 
Mike Corum
 
 
From: Corum, Michael [mailto:mc...@rg...] 
Sent: Monday, November 15, 2010 2:56 PM
To: cod...@li...
Subject: Re: [Codenarc-user] Question about Using New Size Features
 
Since upgrading from 0.6.1 to 0.11, I’m seeing lots of new violations. 
Many of them don’t really make sense.  One example is the use of the 
“multiply” method on a string.  The idea that this is a violation makes no 
sense.  Here is some example code from a test where I was testing a long 
string:
 
def longString = "Long String!".multiply(201)
 
CodeNarc flags this with ExplicitCallToMultiplyMethod.  Since using 
multiply is correct in this case (in fact, the recommended Groovy way of 
doing it), I wanted to turn this one off.  So, I added the following line 
to codenarc.properties:
 
ExplicitCallToMultiplyMethod.doNotApplyToClassNames=java.lang.String
 
However, after running codenarc again, it still flags that line of code 
with ExplicitCallToMultiplyMethod.  What can I do to make this work 
correctly?
 
 
Michael Corum 
Consultant
Software Architect 
 
RGA Reinsurance Company
1370 Timerlake Manor Parkway
Saint Louis, MO  63017 
T 636.736.7066 
 
www.rgare.com
 
_____________________________
 
This message is intended only for the use of the individual or entity to 
which it is addressed, and may contain information that is privileged, 
confidential, and exempt from disclosure under applicable law. If the 
reader of this message is not the intended recipient, or the employee or 
agent responsible for delivering the message to the intended recipient, 
you are hereby notified that any dissemination, distribution, or copying 
of this communication is strictly prohibited. If you have received this 
communication in error, please notify us immediately by telephone and 
return the original message to its sender. Thank you for your cooperation 
and assistance.
------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Codenarc-user mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-user

ForwardSourceID:NT000CECDE 

Re: [Codenarc-user] Question about Using New Size Features

[Corum, M. <mc...@rg...>]

Sorry, I sent this before my test suite finished all the way.  It didn't
work.  Here is what I have in codenarc.properties:

 

ExplicitCallToMultiplyMethod.doNotApplyToClassNames=java.lang.String,gro
ovy.lang.GString

 

It still flags any use of multiple on a string or GString.

 

Any help would be much appreciated.

 

Mike

 

From: Corum, Michael [mailto:mc...@rg...] 
Sent: Monday, November 15, 2010 3:11 PM
To: cod...@li...
Subject: Re: [Codenarc-user] Question about Using New Size Features

 

Please ignore this question.  It was a GString rather than a java
string.  Once I put that in, this one worked.

 

I'm still interested in the question of how to get the new features that
were added in 0.11 to work properly.  For instance, I put
MethodSize.maxLines=8 in my codenarc.properties file and it isn't
catching any long methods.

 

Thanks,

 

Mike Corum

 

 

From: Corum, Michael [mailto:mc...@rg...] 
Sent: Monday, November 15, 2010 2:56 PM
To: cod...@li...
Subject: Re: [Codenarc-user] Question about Using New Size Features

 

Since upgrading from 0.6.1 to 0.11, I'm seeing lots of new violations.
Many of them don't really make sense.  One example is the use of the
"multiply" method on a string.  The idea that this is a violation makes
no sense.  Here is some example code from a test where I was testing a
long string:

 

def longString = "Long String!".multiply(201)

 

CodeNarc flags this with ExplicitCallToMultiplyMethod.  Since using
multiply is correct in this case (in fact, the recommended Groovy way of
doing it), I wanted to turn this one off.  So, I added the following
line to codenarc.properties:

 

ExplicitCallToMultiplyMethod.doNotApplyToClassNames=java.lang.String

 

However, after running codenarc again, it still flags that line of code
with ExplicitCallToMultiplyMethod.  What can I do to make this work
correctly?

 

 

Michael Corum  

Consultant

Software Architect 

 

RGA Reinsurance Company

1370 Timerlake Manor Parkway

Saint Louis, MO  63017 

T 636.736.7066  

 

www.rgare.com

 

_____________________________

 

This message is intended only for the use of the individual or entity to
which it is addressed, and may contain information that is privileged,
confidential, and exempt from disclosure under applicable law. If the
reader of this message is not the intended recipient, or the employee or
agent responsible for delivering the message to the intended recipient,
you are hereby notified that any dissemination, distribution, or copying
of this communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by telephone and
return the original message to its sender. Thank you for your
cooperation and assistance.

Re: [Codenarc-user] Question about Using New Size Features

[Corum, M. <mc...@rg...>]

Please ignore this question.  It was a GString rather than a java
string.  Once I put that in, this one worked.

 

I'm still interested in the question of how to get the new features that
were added in 0.11 to work properly.  For instance, I put
MethodSize.maxLines=8 in my codenarc.properties file and it isn't
catching any long methods.

 

Thanks,

 

Mike Corum

 

 

From: Corum, Michael [mailto:mc...@rg...] 
Sent: Monday, November 15, 2010 2:56 PM
To: cod...@li...
Subject: Re: [Codenarc-user] Question about Using New Size Features

 

Since upgrading from 0.6.1 to 0.11, I'm seeing lots of new violations.
Many of them don't really make sense.  One example is the use of the
"multiply" method on a string.  The idea that this is a violation makes
no sense.  Here is some example code from a test where I was testing a
long string:

 

def longString = "Long String!".multiply(201)

 

CodeNarc flags this with ExplicitCallToMultiplyMethod.  Since using
multiply is correct in this case (in fact, the recommended Groovy way of
doing it), I wanted to turn this one off.  So, I added the following
line to codenarc.properties:

 

ExplicitCallToMultiplyMethod.doNotApplyToClassNames=java.lang.String

 

However, after running codenarc again, it still flags that line of code
with ExplicitCallToMultiplyMethod.  What can I do to make this work
correctly?

 

 

Michael Corum  

Consultant

Software Architect 

 

RGA Reinsurance Company

1370 Timerlake Manor Parkway

Saint Louis, MO  63017 

T 636.736.7066  

 

www.rgare.com

 

_____________________________

 

This message is intended only for the use of the individual or entity to
which it is addressed, and may contain information that is privileged,
confidential, and exempt from disclosure under applicable law. If the
reader of this message is not the intended recipient, or the employee or
agent responsible for delivering the message to the intended recipient,
you are hereby notified that any dissemination, distribution, or copying
of this communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by telephone and
return the original message to its sender. Thank you for your
cooperation and assistance.

Re: [Codenarc-user] Question about Using New Size Features

[Corum, M. <mc...@rg...>]

Since upgrading from 0.6.1 to 0.11, I'm seeing lots of new violations.
Many of them don't really make sense.  One example is the use of the
"multiply" method on a string.  The idea that this is a violation makes
no sense.  Here is some example code from a test where I was testing a
long string:

 

def longString = "Long String!".multiply(201)

 

CodeNarc flags this with ExplicitCallToMultiplyMethod.  Since using
multiply is correct in this case (in fact, the recommended Groovy way of
doing it), I wanted to turn this one off.  So, I added the following
line to codenarc.properties:

 

ExplicitCallToMultiplyMethod.doNotApplyToClassNames=java.lang.String

 

However, after running codenarc again, it still flags that line of code
with ExplicitCallToMultiplyMethod.  What can I do to make this work
correctly?

 

 

Michael Corum  

Consultant

Software Architect 

 

RGA Reinsurance Company

1370 Timerlake Manor Parkway

Saint Louis, MO  63017 

T 636.736.7066  

 

www.rgare.com

 

_____________________________

 

This message is intended only for the use of the individual or entity to
which it is addressed, and may contain information that is privileged,
confidential, and exempt from disclosure under applicable law. If the
reader of this message is not the intended recipient, or the employee or
agent responsible for delivering the message to the intended recipient,
you are hereby notified that any dissemination, distribution, or copying
of this communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by telephone and
return the original message to its sender. Thank you for your
cooperation and assistance.

[Codenarc-user] Question about Using New Size Features

[Corum, M. <mc...@rg...>]

I'm trying to get complexity and size violations based on CodeNarc 0.11.
Here is what I'm putting into my codenarc.properties file.

 

AbcComplexity.maxMethodComplexity=25

CyclomaticComplexity.maxMethodComplexity=8

MethodSize.maxLines=8

 

I know I have plenty of methods that would exceed these but I'm getting
nothing.  I have the GMetrics 0.3 jar in my /lib directory of my Grails
project.  It is running on Hudson.  I know that 0.11 is being used
because my violations count shot up from 6 to 48.  However, none of them
were about the new ones above that I'm trying to get.  

 

What else needs to be done to turn these on besides adding GMetrics to
/lib?

 

Michael Corum  

Consultant

Software Architect 

 

RGA Reinsurance Company

1370 Timerlake Manor Parkway

Saint Louis, MO  63017 

T 636.736.7066  

 

www.rgare.com

 

_____________________________

 

This message is intended only for the use of the individual or entity to
which it is addressed, and may contain information that is privileged,
confidential, and exempt from disclosure under applicable law. If the
reader of this message is not the intended recipient, or the employee or
agent responsible for delivering the message to the intended recipient,
you are hereby notified that any dissemination, distribution, or copying
of this communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by telephone and
return the original message to its sender. Thank you for your
cooperation and assistance.

[Codenarc-user] [ANN] Announcing CodeNarc 0.11

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

The CodeNarc Team is proud to announce the release of version 0.11.
 
CodeNarc is a static analysis tool for Groovy source code.  Version 0.11 
adds over 50 new rules to the product (bringing the total to 130+ rules) 
and a few really great features. See The CodeNarc 0.11 Unofficial Guide.
 
New Features
@SuppressWarnings Support. All rules now recognize the 
java.lang.SuppressWarnings annotation on fields, methods, and classes. If 
this annotation is added then there will be no violations produced. 
Better "codenarc create-rule" support. 
CodeNarc is now on the Google App Engine! The CodeNarc Web Console lets 
you enter source code and execute CodeNarc to see the violations. There 
are also predefined example scripts such as ReturnFromFinallyBlock.
New Rules
  (Basic Rules)
BooleanMethodReturnsNull Rule (basic): Checks for a method with Boolean 
return type that returns an explicit null. 
DeadCode Rule (basic) :  Checks for dead code that appears after a return 
statement or after an exception is thrown. 
DoubleNegative Rule (basic) :  Checks for using a double negative, which 
is always positive. 
DuplicateCaseStatement Rule (basic) :  Check for duplicate case statements 
in a switch block, such as two equal integers or strings. 
ExplicitArrayListInstantiation Rule (basic) :  This rule checks for the 
explicit instantiation of an ArrayList. In Groovy, it is best to write new 
ArrayList() as [], which creates the same object. 
ExplicitCallToAndMethod Rule (basic) :  This rule detects when the 
and(Object) method is called directly in code instead of using the & 
operator. 
ExplicitCallToCompareToMethod Rule (basic) :  This rule detects when the 
compareTo(Object) method is called directly in code instead of using the 
<=>, >, >=, <, and <= operators. 
ExplicitCallToDivMethod Rule (basic) :  This rule detects when the 
div(Object) method is called directly in code instead of using the / 
operator. 
ExplicitCallToEqualsMethod Rule (basic) :  This rule detects when the 
equals(Object) method is called directly in code instead of using the == 
or != operator. 
ExplicitCallToGetAtMethod Rule (basic) :  This rule detects when the 
getAt(Object) method is called directly in code instead of using the [] 
index operator. 
ExplicitCallToLeftShiftMethod Rule (basic) :  This rule detects when the 
leftShift(Object) method is called directly in code instead of using the 
\<\< operator. 
ExplicitCallToMinusMethod Rule (basic) :  This rule detects when the 
minus(Object) method is called directly in code instead of using the - 
operator. 
ExplicitCallToMultiplyMethod Rule (basic) :  This rule detects when the 
multiply(Object) method is called directly in code instead of using the * 
operator. 
ExplicitCallToModMethod Rule (basic) :  This rule detects when the 
mod(Object) method is called directly in code instead of using the % 
operator. 
ExplicitCallToOrMethod Rule (basic) :  This rule detects when the 
or(Object) method is called directly in code instead of using the | 
operator. 
ExplicitCallToPlusMethod Rule (basic) :  This rule detects when the 
plus(Object) method is called directly in code instead of using the + 
operator. 
ExplicitCallToPowerMethod Rule (basic) :  This rule detects when the 
power(Object) method is called directly in code instead of using the ** 
operator. 
ExplicitCallToRightShiftMethod Rule (basic) :  This rule detects when the 
rightShift(Object) method is called directly in code instead of using the 
\>\> operator. 
ExplicitCallToXorMethod Rule (basic) :  This rule detects when the 
xor(Object) method is called directly in code instead of using the ^ 
operator. 
ExplicitHashMapInstantiation Rule (basic) :  This rule checks for the 
explicit instantiation of a HashMap. In Groovy, it is best to write new 
HashMap() as [:], which creates the same object. 
ExplicitHashSetInstantiation Rule (basic) :  This rule checks for the 
explicit instantiation of a HashSet. In Groovy, it is best to write new 
HashSet() as [] as Set, which creates the same object. 
ExplicitLinkedListInstantiation Rule (basic) :  This rule checks for the 
explicit instantiation of a LinkedList. In Groovy, it is best to write new 
LinkedList() as [] as Queue, which creates the same object. 
ExplicitStackInstantiation Rule (basic) :  This rule checks for the 
explicit instantiation of a Stack. In Groovy, it is best to write new 
Stack() as [] as Stack, which creates the same object. 
ExplicitTreeSetInstantiation Rule (basic) :  This rule checks for the 
explicit instantiation of a TreeSet. In Groovy, it is best to write new 
TreeSet()>> as [] as SortedSet, which creates the same object. 
GStringAsMapKey Rule (basic)  A GString should not be used as a map key 
since its hashcode is not guaranteed to be stable. 
InvertedIfElse Rule (basic) :  An inverted if-else statement is one in 
which there is a single if statement with a single else branch and the 
boolean test of the if is negated. 
RemoveAllOnSelf Rule (basic) : Don't use removeAll to clear a collection. 
ReturnsNullInsteadOfEmptyArray Rule (basic) : If you have a method or 
closure that returns an array, then when there are no results return a 
zero-length (empty) array rather than null. 
ReturnsNullInsteadOfEmptyCollection Rule (basic) : If you have a method or 
closure that returns a collection, then when there are no results return a 
zero-length (empty) collection rather than null. 
SerialVersionUID Rule (basic) : A serialVersionUID is normally intended to 
be used with Serialization. It needs to be of type long, static, and 
final. 
  DRY (Don't Repeat Yourself) Rules
DuplicateNumberLiteral Rule (dry) : This rule checks for duplicate number 
literals within the current class. 
DuplicateStringLiteral Rule (dry) : This rule checks for duplicate String 
literals within the current class.
  Exceptions Rules
CatchIllegalMonitorStateException Rule (exceptions) : Dubious catching of 
IllegalMonitorStateException. 
ConfusingClassNamedException Rule (exceptions) : This class is not derived 
from another exception, but ends with 'Exception'. 
ReturnNullFromCatchBlock Rule (exceptions) : Returning null from a catch 
block often masks errors and requires the client to handle error codes. 
  Concurrency Rules
UseOfNotifyMethod Rule (concurrency) : Checks for code that calls notify() 
rather than notifyAll(). 
SynchronizedOnGetClass Rule (concurrency) : Checks for synchronization on 
getClass() rather than class literal. 
  JUnit Rules
UseAssertEqualsInsteadOfAssertTrue Rule (junit) : This rule detects JUnit 
assertions in object equality. 
UseAssertTrueInsteadOfAssertEqualsRule Rule (junit) : This rule detects 
JUnit calling assertEquals where the first parameter is a boolean. 
UseAssertNullInsteadOfAssertEquals Rule (junit) : This rule detects JUnit 
calling assertEquals where the first or second parameter is null. 
UseAssertSameInsteadOfAssertTrue Rule (junit) : This rule detects JUnit 
calling assertTrue or assertFalse where the first or second parameter is 
an Object#is() call testing for reference equality. 
JUnitFailWithoutMessage Rule (junit) : This rule detects JUnit calling the 
fail() method without an argument. 
JUnitStyleAssertions Rule (junit) : This rule detects calling JUnit style 
assertions like assertEquals, assertTrue, assertFalse, assertNull, 
assertNotNull.
  Naming Rules
ConfusingMethodName Rule (naming) : Checks for very confusing method 
names. The referenced methods have names that differ only by 
capitalization. 
ObjectOverrideMisspelledMethodName Rule (naming) : Verifies that the names 
of the most commonly overridden methods of Object: equals, hashCode and 
toString, are correct.
  Size Rules
MethodCount Rule (size) : Checks if the number of methods within a class 
exceeds the number of lines specified by the maxMethod property.
  Unnecessary Code Rules
UnnecessaryConstructor Rule (unnecessary) : This rule detects when a 
constructor is not necessary; i.e., when there's only one constructor, 
it's public, has an empty body, and takes no arguments. 
UnnecessaryCollectionCall Rule (unnecessary) : Checks for useless calls to 
collections. 
UnnecessaryOverridingMethod Rule (unnecessary) : Checks for an overriding 
method that merely calls the same method defined in a superclass. 
UnnecessaryReturnKeyword Rule (unnecessary) :  In Groovy, the return 
keyword is often optional. 
Potential Breaking Changes
CodeNarc now requires Groovy 1.7. Keep in mind that it can still run 
against (analyze) older Groovy code. 
The following three rules were moved from the "basic" ruleset into the new 
"unnecessary" ruleset. Likewise, the three rule classes were moved from 
the org.codenarc.rule.basic package into org.codenarc.rule.unnecessary. 
You will need to adjust your ruleset configuration if you included one of 
these rules specifically in a custom ruleset, or configured them as part 
of the "basic" ruleset.  
UnnecessaryBooleanExpressionRule 
UnnecessaryIfStatementRule 
UnnecessaryTernaryExpressionRule
AbstractAstVisitor - If you implemented your own rule by subclassing 
AbstractAstVisitor then your code might break. It is a compile error and 
the breakage will be clear and obvious. In order to support 
@SuppressWarnings, we needed to change AbstractAstVisitor. The method 
visitMethodNode became visitMethodNodeEx, visitClass became visitClassEx, 
visitConstructorOrMethod became visitConstructorOrMethodEx, visitField 
became visitFieldEx, visitProperty became visitPropertyEx, and 
visitConstructor became visitConstructorEx. From within these new methods 
there is no need to call super.visitX. In the rare case that the simple 
renaming does not fix your problem then please contact the mailing list.
Vote for CodeNarc at DZone
Vote for IDEA Support for CodeNarc
Visit the CodeNarc Home Page 

Re: [Codenarc-user] new codenarc logo?

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

How about this idea for a logo:

An armadillo with a badge wearing a cowboy hat. Just like an old west
sheriff, except a feakin' armadillo.

That there is a good idea. Anyone out there got some photoshop skills?

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





On Sat, Nov 6, 2010 at 12:43 AM, Chris Mair <chr...@ea...> wrote:
> Yes, I absolutely agree. I have wanted a cool logo/icon since the start. I
> would have done something like this long ago if I had even a bit of artistic
> ability. Thanks for the promising icon-builder site, Hamlet.
>
> Chris
>
> -----Original Message-----
> From: Hamlet D'Arcy [mailto:ham...@gm...]
> Sent: Friday, November 05, 2010 12:11 PM
> To: Cod...@li...
> Subject: [Codenarc-user] new codenarc logo?
>
>
> You know what CodeNarc really needs?
>
> YES a new Logo!
>
> Checkout out this photoshop tutorial on how to make a shield:
> http://vforvectors.com/create-a-shiny-shield-icon/
>
> Wouldn't it be great to have a shield like this with the word CodeNarc in
> front of it (in the Groovy Font). Answer: yes it would be.
>
> Can somebody please get on this ASAP?
>
> --
> Hamlet D'Arcy
> ham...@gm...
>
> ----------------------------------------------------------------------------
> --
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper David
> G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>
>

[Codenarc-user] codenarc in IntelliJ IDEA please upvote

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

There is a feature request in IDEA to add CodeNarc support:
http://youtrack.jetbrains.net/issue/IDEA-61209?projectKey=IDEA

Your upvotes appreciated (click the little star)

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

[Codenarc-user] CodeNarc Web Console

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

You can play with the newest snapshot of CodeNarc online using:
http://meetcodenarc.appspot.com/

You cannot save scripts yet or view saved scripts, there is a bug I am
working on.

But still, it is fun to play with. Code is out on github for those
interested. User name HamletDRC

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

[Codenarc-user] codenarc on thristyhead

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

i gave an interview on thirsty head with about 7 minutes of codenarc
content. Codenarc starts around minute 20.

http://thirstyhead.com/watch/show/Hamlet_D'Arcy_on_Groovy_Compile-time_Metaprogramming

Enjoy!

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

[Codenarc-user] "Improving Your Groovy Code Quality" presentation at Spring 2GX

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

Just a heads up that Venkat's "Improving Your Groovy Code Quality"
presentation at Spring 2GX (Oct 2010) included a discussion of several code
smells and whether or not CodeNarc handles them, including a couple
omissions that I plan on looking into.
 
The slides can be downloaded at:    http://agiledeveloper.com/downloads.html
 
Chris
 
 

Re: [Codenarc-user] new codenarc logo?

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

Yes, I absolutely agree. I have wanted a cool logo/icon since the start. I
would have done something like this long ago if I had even a bit of artistic
ability. Thanks for the promising icon-builder site, Hamlet.

Chris

-----Original Message-----
From: Hamlet D'Arcy [mailto:ham...@gm...] 
Sent: Friday, November 05, 2010 12:11 PM
To: Cod...@li...
Subject: [Codenarc-user] new codenarc logo?


You know what CodeNarc really needs?

YES a new Logo!

Checkout out this photoshop tutorial on how to make a shield:
http://vforvectors.com/create-a-shiny-shield-icon/

Wouldn't it be great to have a shield like this with the word CodeNarc in
front of it (in the Groovy Font). Answer: yes it would be.

Can somebody please get on this ASAP?

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

----------------------------------------------------------------------------
--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper David
G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Codenarc-user mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-user

[Codenarc-user] new codenarc logo?

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

You know what CodeNarc really needs?

YES a new Logo!

Checkout out this photoshop tutorial on how to make a shield:
http://vforvectors.com/create-a-shiny-shield-icon/

Wouldn't it be great to have a shield like this with the word CodeNarc
in front of it (in the Groovy Font). Answer: yes it would be.

Can somebody please get on this ASAP?

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

Re: [Codenarc-user] CodeNarc - Philosophy of the Basic Ruleset

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

Thanks Hamlet. I'll try to stay benevolent. :-)

Chris

-----Original Message-----
From: Hamlet D'Arcy [mailto:ham...@gm...] 
Sent: Saturday, October 30, 2010 10:56 AM
To: Chris Mair
Cc: Cod...@li...
Subject: Re: CodeNarc - Philosophy of the Basic Ruleset


Having too many rules and difficulties categorizing them is a good problem
to have. For anyone else out there on this mailing list, the last month has
added almost 20(!) new rules. Wonderful!!!

I don't care how they are organized, just as long as the rules exist. In my
opinion, you (Chris) should act as benevolent dictator when it comes to
naming the rules, grouping the rules, and setting default priorities on the
rules.  Unilateral action is OK with me, especially for rules that have been
checked in but not put into a formal release!


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



On Sat, Oct 30, 2010 at 2:39 PM, Chris Mair <chr...@ea...> wrote:
> Hamlet (and anybody else),
>
> In many ways, I patterned CodeNarc after PMD. That included creating a 
> "basic" ruleset. The intent was that these were "standard" rules that 
> everyone could agree on. That is typically the first ruleset that 
> people turn on, and no one would argue that the violations need to be 
> fixed.
>
> I may have strayed a bit from that intent when I added the 
> Unnecessary*Rules (e.g. UnnecessaryBooleanExpressionRule, 
> UnnecessaryIfStatementRule, etc.), or perhaps other rules in the basic 
> ruleset.. When I first started this project, I knew that 
> categorization of rules would be challenging sometimes.
>
> A few days ago, I attended a presentation/discussion of the Sonar tool 
> at my company. We were discussing PMD and Checkstyle, and a couple 
> people indicated that even the PMD "basic" ruleset is somewhat 
> subjective, in terms of being universal or not. Several people 
> (including me) agreed that using tools like this eventually requires 
> customization of the chosen rule set, since there really can't be a 
> one-size-fits-all.
>
> All that being said... I am ok continuing with what we have, and 
> leaving the current rules where they are. But if anyone has strong 
> opinions about a better categorization, it would be better to consider 
> reorganizing now rather than later.
>
> Thanks.
> Chris

Re: [Codenarc-user] CodeNarc - Philosophy of the Basic Ruleset

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

Having too many rules and difficulties categorizing them is a good
problem to have. For anyone else out there on this mailing list, the
last month has added almost 20(!) new rules. Wonderful!!!

I don't care how they are organized, just as long as the rules exist.
In my opinion, you (Chris) should act as benevolent dictator when it
comes to naming the rules, grouping the rules, and setting default
priorities on the rules.  Unilateral action is OK with me, especially
for rules that have been checked in but not put into a formal release!


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



On Sat, Oct 30, 2010 at 2:39 PM, Chris Mair <chr...@ea...> wrote:
> Hamlet (and anybody else),
>
> In many ways, I patterned CodeNarc after PMD. That included creating a
> "basic" ruleset. The intent was that these were "standard" rules that
> everyone could agree on. That is typically the first ruleset that people
> turn on, and no one would argue that the violations need to be fixed.
>
> I may have strayed a bit from that intent when I added the Unnecessary*Rules
> (e.g. UnnecessaryBooleanExpressionRule, UnnecessaryIfStatementRule, etc.),
> or perhaps other rules in the basic ruleset.. When I first started this
> project, I knew that categorization of rules would be challenging sometimes.
>
> A few days ago, I attended a presentation/discussion of the Sonar tool at my
> company. We were discussing PMD and Checkstyle, and a couple people
> indicated that even the PMD "basic" ruleset is somewhat subjective, in terms
> of being universal or not. Several people (including me) agreed that using
> tools like this eventually requires customization of the chosen rule set,
> since there really can't be a one-size-fits-all.
>
> All that being said... I am ok continuing with what we have, and leaving the
> current rules where they are. But if anyone has strong opinions about a
> better categorization, it would be better to consider reorganizing now
> rather than later.
>
> Thanks.
> Chris

[Codenarc-user] CodeNarc - Philosophy of the Basic Ruleset

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

Hamlet (and anybody else),
 
In many ways, I patterned CodeNarc after PMD. That included creating a
"basic" ruleset. The intent was that these were "standard" rules that
everyone could agree on. That is typically the first ruleset that people
turn on, and no one would argue that the violations need to be fixed.
 
I may have strayed a bit from that intent when I added the Unnecessary*Rules
(e.g. UnnecessaryBooleanExpressionRule, UnnecessaryIfStatementRule, etc.),
or perhaps other rules in the basic ruleset.. When I first started this
project, I knew that categorization of rules would be challenging sometimes.
 
A few days ago, I attended a presentation/discussion of the Sonar tool at my
company. We were discussing PMD and Checkstyle, and a couple people
indicated that even the PMD "basic" ruleset is somewhat subjective, in terms
of being universal or not. Several people (including me) agreed that using
tools like this eventually requires customization of the chosen rule set,
since there really can't be a one-size-fits-all.
 
All that being said... I am ok continuing with what we have, and leaving the
current rules where they are. But if anyone has strong opinions about a
better categorization, it would be better to consider reorganizing now
rather than later.
 
Thanks.
Chris

Re: [Codenarc-user] can I change the compiler phase my rule runs in?

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

Hi Chris,

Concerning a CompilePhase, here is what I tell people: if you want to write
new AST do it in an early phase. If you want to read AST then do it in a
later phase. More information is available in later phases so you have
better information like resolved types when possible. The "tree is more
dense" later on and more sparse earlier on.

I would say just run everything in CLASS_GENERATION. The downside is that it
might break any custom rules implemented, but honestly how likely is
that...


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


On Sun, Oct 24, 2010 at 8:17 AM, Chris Mair <chr...@ea...> wrote:

>  Hamlet,
>
> As I'm sure you saw in the code, that compiler phase is used in the
> AbstractSourceCode class. And the AST for a SourceCode instance for a file
> is only built once and then cached. So, to support different compiler
> phases, I would lean toward having the SourceCode instance maintain a Map of
> AST objects, keyed by the compiler phase, and pass the desired phase from
> the Rule into the SourceCode object. I can work on that.
>
> That being said, what is the downside of having all of the rules use the
> later compiler phase (CLASS_GENERATION)? I just tried to change the default
> to CLASS_GENERATION, and it broke a bunch of code/tests. But, at least for a
> few of the failures, I was able to adjust the AST manipulation in the code
> and fix the tests. It might be a lot of work, but if I could do that
> everywhere, would that be the "right" thing to do?
>
> Chris
>
>  -----Original Message-----
> *From:* Hamlet D'Arcy [mailto:ham...@gm...]
> *Sent:* Friday, October 22, 2010 2:39 PM
> *To:* chr...@wa...
> *Cc:* Cod...@li...
> *Subject:* Re: [Codenarc-user] can I change the compiler phase my rule
> runs in?
>
> I am quite sure it is hardcoded as well. That's what I saw in the code :)
>
> Can we make it an optional property on AbstractAstVisitorRule, like this:
>
>  class CouldReturnZeroLengthArrayRule extends AbstractAstVisitorRule {
>     String name = 'CouldReturnZeroLengthArray'
>     int priority = 2
>     Class astVisitorClass = CouldReturnZeroLengthArrayAstVisitor
>     CompilePhase phase = CompilePhase.CLASS_GENERATION
> }
>
> I could take a look at adding this feature if you want, but I'd rather
> concentrate on writing new rules. Can you handle this?
>
> --
> Hamlet D'Arcy
> ham...@gm...
>
>
>
> On Fri, Oct 22, 2010 at 1:24 PM, <chr...@wa...> wrote:
>
>>
>> Hmmm. Not currently. That is hard-coded right now, I think. I'll take a
>> look.
>>
>>
>>
>>    *"Hamlet D'Arcy" <ham...@gm...>*
>>
>> 10/22/2010 02:11 PM
>>    To
>> Cod...@li...
>> cc
>>   Subject
>> [Codenarc-user] can I change the compiler phase my rule runs in?
>>
>>
>>
>>
>>  can I change the compiler phase my rule runs in?
>>
>> I need to see ReturnStatement objects and those are only present in
>> the Class Generation phase.
>>
>> Can I make my rule run in that phase?
>>
>> --
>> Hamlet D'Arcy
>> ham...@gm...
>>
>>
>> ------------------------------------------------------------------------------
>> Nokia and AT&T present the 2010 Calling All Innovators-North America
>> contest
>> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
>> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
>> marketing
>> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
>> http://p.sf.net/sfu/nokia-dev2dev
>> _______________________________________________
>> Codenarc-user mailing list
>> Cod...@li...
>> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>>
>> ForwardSourceID:NT000CCCDE
>>
>
>
>
>

[Codenarc-user] And... RE: can I change the compiler phase my rule runs in?

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

And don't the later phases require that all the class references within the
code being parsed are found on the classpath? I think that was why I
originally chose that compiler phase -- anything later would mean that I'd
have to configure it to run with all of the application code (being
analyzed) on the classpath. Or am I missing something?
 
Chris
-----Original Message-----
From: Chris Mair [mailto:chr...@ea...] 
Sent: Sunday, October 24, 2010 8:18 AM
To: 'Hamlet D'Arcy'; 'chr...@wa...'
Cc: 'Cod...@li...'
Subject: RE: [Codenarc-user] can I change the compiler phase my rule runs
in?



Hamlet,
 
As I'm sure you saw in the code, that compiler phase is used in the
AbstractSourceCode class. And the AST for a SourceCode instance for a file
is only built once and then cached. So, to support different compiler
phases, I would lean toward having the SourceCode instance maintain a Map of
AST objects, keyed by the compiler phase, and pass the desired phase from
the Rule into the SourceCode object. I can work on that.
 
That being said, what is the downside of having all of the rules use the
later compiler phase (CLASS_GENERATION)? I just tried to change the default
to CLASS_GENERATION, and it broke a bunch of code/tests. But, at least for a
few of the failures, I was able to adjust the AST manipulation in the code
and fix the tests. It might be a lot of work, but if I could do that
everywhere, would that be the "right" thing to do?
 
Chris

-----Original Message-----
From: Hamlet D'Arcy [mailto:ham...@gm...] 
Sent: Friday, October 22, 2010 2:39 PM
To: chr...@wa...
Cc: Cod...@li...
Subject: Re: [Codenarc-user] can I change the compiler phase my rule runs
in?


I am quite sure it is hardcoded as well. That's what I saw in the code :) 

Can we make it an optional property on AbstractAstVisitorRule, like this: 

class CouldReturnZeroLengthArrayRule extends AbstractAstVisitorRule {
    String name = 'CouldReturnZeroLengthArray'
    int priority = 2
    Class astVisitorClass = CouldReturnZeroLengthArrayAstVisitor
    CompilePhase phase = CompilePhase.CLASS_GENERATION
}

I could take a look at adding this feature if you want, but I'd rather
concentrate on writing new rules. Can you handle this? 

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



On Fri, Oct 22, 2010 at 1:24 PM, <chr...@wa...> wrote:



Hmmm. Not currently. That is hard-coded right now, I think. I'll take a
look. 








"Hamlet D'Arcy" <ham...@gm...> 

10/22/2010 02:11 PM 



To
Cod...@li... 	

cc
	

Subject
[Codenarc-user] can I change the compiler phase my rule runs in?	

		





can I change the compiler phase my rule runs in?

I need to see ReturnStatement objects and those are only present in
the Class Generation phase.

Can I make my rule run in that phase?

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


----------------------------------------------------------------------------
--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Codenarc-user mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-user

ForwardSourceID:NT000CCCDE     

Re: [Codenarc-user] can I change the compiler phase my rule runs in?

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

Hamlet,
 
As I'm sure you saw in the code, that compiler phase is used in the
AbstractSourceCode class. And the AST for a SourceCode instance for a file
is only built once and then cached. So, to support different compiler
phases, I would lean toward having the SourceCode instance maintain a Map of
AST objects, keyed by the compiler phase, and pass the desired phase from
the Rule into the SourceCode object. I can work on that.
 
That being said, what is the downside of having all of the rules use the
later compiler phase (CLASS_GENERATION)? I just tried to change the default
to CLASS_GENERATION, and it broke a bunch of code/tests. But, at least for a
few of the failures, I was able to adjust the AST manipulation in the code
and fix the tests. It might be a lot of work, but if I could do that
everywhere, would that be the "right" thing to do?
 
Chris

-----Original Message-----
From: Hamlet D'Arcy [mailto:ham...@gm...] 
Sent: Friday, October 22, 2010 2:39 PM
To: chr...@wa...
Cc: Cod...@li...
Subject: Re: [Codenarc-user] can I change the compiler phase my rule runs
in?


I am quite sure it is hardcoded as well. That's what I saw in the code :) 

Can we make it an optional property on AbstractAstVisitorRule, like this: 

class CouldReturnZeroLengthArrayRule extends AbstractAstVisitorRule {
    String name = 'CouldReturnZeroLengthArray'
    int priority = 2
    Class astVisitorClass = CouldReturnZeroLengthArrayAstVisitor
    CompilePhase phase = CompilePhase.CLASS_GENERATION
}

I could take a look at adding this feature if you want, but I'd rather
concentrate on writing new rules. Can you handle this? 

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



On Fri, Oct 22, 2010 at 1:24 PM, <chr...@wa...> wrote:



Hmmm. Not currently. That is hard-coded right now, I think. I'll take a
look. 








"Hamlet D'Arcy" <ham...@gm...> 

10/22/2010 02:11 PM 



To
Cod...@li... 	

cc
	

Subject
[Codenarc-user] can I change the compiler phase my rule runs in?	

		





can I change the compiler phase my rule runs in?

I need to see ReturnStatement objects and those are only present in
the Class Generation phase.

Can I make my rule run in that phase?

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


----------------------------------------------------------------------------
--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Codenarc-user mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-user

ForwardSourceID:NT000CCCDE     

Re: [Codenarc-user] can I change the compiler phase my rule runs in?

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

I am quite sure it is hardcoded as well. That's what I saw in the code :)

Can we make it an optional property on AbstractAstVisitorRule, like this:

class CouldReturnZeroLengthArrayRule extends AbstractAstVisitorRule {
    String name = 'CouldReturnZeroLengthArray'
    int priority = 2
    Class astVisitorClass = CouldReturnZeroLengthArrayAstVisitor
    CompilePhase phase = CompilePhase.CLASS_GENERATION
}

I could take a look at adding this feature if you want, but I'd rather
concentrate on writing new rules. Can you handle this?

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



On Fri, Oct 22, 2010 at 1:24 PM, <chr...@wa...> wrote:

>
> Hmmm. Not currently. That is hard-coded right now, I think. I'll take a
> look.
>
>
>
>  *"Hamlet D'Arcy" <ham...@gm...>*
>
> 10/22/2010 02:11 PM
>   To
> Cod...@li...
> cc
>   Subject
> [Codenarc-user] can I change the compiler phase my rule runs in?
>
>
>
>
> can I change the compiler phase my rule runs in?
>
> I need to see ReturnStatement objects and those are only present in
> the Class Generation phase.
>
> Can I make my rule run in that phase?
>
> --
> Hamlet D'Arcy
> ham...@gm...
>
>
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America
> contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
> marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>
> ForwardSourceID:NT000CCCDE
>

Re: [Codenarc-user] can I change the compiler phase my rule runs in?

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

Hmmm. Not currently. That is hard-coded right now, I think. I'll take a 
look.




"Hamlet D'Arcy" <ham...@gm...> 
10/22/2010 02:11 PM


To
Cod...@li...
cc

Subject
[Codenarc-user] can I change the compiler phase my rule runs in?






can I change the compiler phase my rule runs in?

I need to see ReturnStatement objects and those are only present in
the Class Generation phase.

Can I make my rule run in that phase?

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

------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America 
contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in 
marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Codenarc-user mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-user

ForwardSourceID:NT000CCCDE 

[Codenarc-user] can I change the compiler phase my rule runs in?

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

can I change the compiler phase my rule runs in?

I need to see ReturnStatement objects and those are only present in
the Class Generation phase.

Can I make my rule run in that phase?

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