codenarc-developer — CodeNarc Developers

Re: [Codenarc-developer] Some additional rules

[Rafael L. L. <raf...@os...>]

Thank you Hamlet.

And, you are right about the CopyrightComment rule.

Bests,

Rafael Luque

2011/6/22 Hamlet DArcy <ham...@ca...>

> Very cool, I am sure we can use these.
>
> However, the CopyrightComment.groovy can be replaced by the standard
> "RequiredRegex" rule.
>
>
>
> ----- Original Message -----
> >
> >
> > Hi all,
> >
> > At OSOCO we are using CodeNarc some time ago and our intention is to
> > be able to write our corporate coding conventions as a CodeNarc
> > ruleset. For that purpose we have written some extra rules that we
> > need and have pushed them to our public repo at GitHub:
> >
> > https://github.com/osoco/extra-codenarc-rules
> >
> > Perhaps you can find some of these rules useful in a general way and
> > we can contribute them to the project.
> >
> > Best regards,
> >
> > Rafael Luque
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Simplify data backup and recovery for your virtual environment with
> > vRanger.
> > Installation's a snap, and flexible recovery options mean your data
> > is safe,
> > secure and there when you need it. Data protection magic?
> > Nope - It's vRanger. Get your free trial download today.
> > http://p.sf.net/sfu/quest-sfdev2dev
> > _______________________________________________
> > Codenarc-developer mailing list
> > Cod...@li...
> > https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> >
>

Re: [Codenarc-developer] Some additional rules

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

Very cool, I am sure we can use these. 

However, the CopyrightComment.groovy can be replaced by the standard "RequiredRegex" rule. 



----- Original Message -----
> 
> 
> Hi all,
> 
> At OSOCO we are using CodeNarc some time ago and our intention is to
> be able to write our corporate coding conventions as a CodeNarc
> ruleset. For that purpose we have written some extra rules that we
> need and have pushed them to our public repo at GitHub:
> 
> https://github.com/osoco/extra-codenarc-rules
> 
> Perhaps you can find some of these rules useful in a general way and
> we can contribute them to the project.
> 
> Best regards,
> 
> Rafael Luque
> 
> 
> 
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data
> is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> 

[Codenarc-developer] Some additional rules

[Rafael L. L. <raf...@os...>]

Hi all,

At OSOCO we are using CodeNarc some time ago and our intention is to be able
to write our corporate coding conventions as a CodeNarc ruleset. For that
purpose we have written some extra rules that we need and have pushed them
to our public repo at GitHub:

https://github.com/osoco/extra-codenarc-rules

Perhaps you can find some of these rules useful in a general way and we can
contribute them to the project.

Best regards,

Rafael Luque

[Codenarc-developer] New release support branch for 0.14

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

I have created a release support branch for 0.14.x (bug fix) point releases
(if any):

 

https://codenarc.svn.sourceforge.net/svnroot/codenarc/branches/ReleaseBranch
-0.14

 

[Codenarc-developer] [ANN] Announcing CodeNarc 0.14

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

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

CodeNarc <http://codenarc.sourceforge.net/>  is a static analysis tool for
Groovy source code. Version 0.14 adds 35 new rules (bringing the total to
241 rules). Try it out on the CodeNarc web console
<http://meetcodenarc.appspot.com/edit/14001> , running on Google App Engine.

New Features 

*	Groovy 1.8 Support - CodeNarc continues to be built with Groovy 1.7,
but should be able to be run with a Groovy 1.8 Runtime.

New and Updated Rules 

·         ExplicitLinkedHashMapInstantiation rule (basic) - This rule checks
for the explicit instantiation of a LinkedHashMap using the no-arg
constructor. In Groovy, it is best to write "new LinkedHashMap()" as "[:]",
which creates the same object.

·         DuplicateMapKey rule (basic) - A map literal is created with
duplicated key. The map entry will be overwritten.

·         DuplicateSetValue rule (basic) - A Set literal is created with
duplicate constant value. A set cannot contain two elements with the same
value.

·         EqualsOverloaded rule (basic) - The class has an equals method,
but the parameter of the method is not of type Object. It is not overriding
equals but instead overloading it.

·         ForLoopShouldBeWhileLoop (basic) - A for-loop without an init and
an update statement can be simplified to a while loop. 

·         NonFinalSubclassOfSensitiveInterface rule (security) - The
permissions classes such as java.security.Permission and
java.security.BasicPermission are designed to be extended. Classes that
derive from these permissions classes, however, must prohibit extension.
This prohibition ensures that malicious subclasses cannot change the
properties of the derived class. Classes that implement sensitive interfaces
such as java.security.PrivilegedAction and
java.security.PrivilegedActionException must also be declared final for
analogous reasons.

·         ImportFromSunPackages rule (imports) - Avoid importing anything
from the 'sun.*' packages. These packages are not portable and are likely to
change.

·         UnnecessaryFinalOnPrivateMethod rule (unnecessary) - A private
method is marked final. Private methods cannot be overridden, so marking it
final is unnecessary.

·         InsecureRandom rule (security) - Reports usages of
java.util.Random, which can produce very predictable results. If two
instances of Random are created with the same seed and sequence of method
calls, they will generate the exact same results. Use
java.security.SecureRandom instead, which provides a cryptographically
strong random number generator. SecureRandom uses PRNG, which means they are
using a deterministic algorithm to produce a pseudo-random number from a
true random seed. SecureRandom produces non-deterministic output.

·         DirectConnectionManagement rule (jdbc) - The J2EE standard
requires that applications use the container's resource management
facilities to obtain connections to resources. Every major web application
container provides pooled database connection management as part of its
resource management framework. Duplicating this functionality in an
application is difficult and error prone, which is part of the reason it is
forbidden under the J2EE standard.

·         ComparisonWithSelf (basic) - Checks for using a comparison
operator or equals() or compareTo() to compare a variable to itself, e.g.: x
== x, x != x, x <=> x, x < x, x > x, x <= x, x >= x, x.equals(x), or
x.compareTo(x), where x is a variable.

·         ComparisonOfTwoConstants (basic) - Checks for using a comparison
operator or equals() or compareTo() to compare two constants to each other
or two literals that contain only constant values.

·         FileCreateTempFile rule (security) - The File.createTempFile()
method is insecure, and has been deprecated by the ESAPI secure coding
library. It has been replaced by the ESAPI
Randomizer.getRandomFilename(String) method.

·         SystemExit rule (security) - Web applications should never call
System.exit(). A call to System.exit() is probably part of leftover debug
code or code imported from a non-J2EE application.

·         ObjectFinalize rule (security) - The finalize() method should only
be called by the JVM after the object has been garbage collected.

·         JavaIoPackageAccess rule (security) - This rule reports violations
of the Enterprise JavaBeans specification by using the java.io package to
access files or the file system.

·         UnsafeArrayDeclaration rule (security) - Triggers a violation when
an array is declared public, final, and static. Secure coding principles
state that, in most cases, an array declared public, final and static is a
bug because arrays are mutable objects.

·         PublicFinalizeMethod rule (security) - Creates a violation when
the program violates secure coding principles by declaring a finalize()
method public.

·         NonFinalPublicField rule (security) - Finds code that violates
secure coding principles for mobile code by declaring a member variable
public but not final.

·         UnnecessaryElseStatement rule (unnecessary) - When an if statement
block ends with a return statement the else is unnecessary. The logic in the
else branch can be run without being in a new scope.

·         StaticConnection rule (concurrency) - Creates violations when a
java.sql.Connection object is used as a static field. Database connections
stored in static fields will be shared between threads, which is unsafe and
can lead to race conditions.

·         UnnecessaryPackageReference (unnecessary) - Checks for explicit
package reference for classes that Groovy imports by default, such as
java.lang.String, java.util.Map and groovy.lang.Closure.

·         AbstractClassWithPublicConstructor (design) - Checks for abstract
classes that define a public constructor, which is useless and confusing.

·         StaticSimpleDateFormatField (concurrency) - Checks for static
SimpleDateFormat fields. SimpleDateFormat objects are not threadsafe, and
should not be shared across threads.

·         IllegalPackageReference (generic) - Checks for reference to any of
the packages configured in packageNames.

·         SpockIgnoreRestUsed rule (junit) - If Spock's @IgnoreRest appears
on any method, then all non-annotated test methods are not executed. This
behaviour is almost always unintended. It's fine to use @IgnoreRest locally
during development, but when committing code, it should be removed.

·         SwallowThreadDeath rule (exceptions) - Detects code that catches
java.lang.ThreadDeath without rethrowing it

·         MisorderedStaticImports rule (imports) - Static imports should
never be declared after nonstatic imports.

·         ConfusingMethodName (naming) - Existing rule updated to analyze
fields and field names as well as just methods.

·         PublicInstanceField rule (design) - Using public fields is
considered to be a bad design. Use properties instead.

·         UnnecessaryNullCheck (unnecessary) - Updated rule to flag null and
not-null checks against the this reference. The this reference can never be
null. 

·         ClassForName rule (basic) - Using Class.forName(...) is a common
way to add dynamic behavior to a system. However, using this method can
cause resource leaks because the classes can be pinned in memory for long
periods of time.

·         StatelessSingleton rule (design) - Rule finds occurrences of the
Singleton pattern where the object has no state (mutable or otherwise).
There is no point in creating a stateless Singleton, just make a new
instance with the new keyword instead.

·         InconsistentPropertySynchronization rule (concurrency) - The rule
is a little smarter now and flags code that defines a synchronized getter
without any setter and vice versa. Those methods will be generated in
unsynchronized from by the Groovy compiler later.

·         ClosureAsLastMethodParameter rule (basic) - If a method is called
and the last parameter is an inline closure then it can be declared outside
of the method call brackets.

·         SerialPersistentFields rule (serialization) - To use a
Serializable object's serialPersistentFields correctly, it must be declared
private, static, and final.

·         UnnecessaryParenthesesForMethodCallWithClosure rule (unnecessary)
- If a method is called and the only parameter to that method is an inline
closure then the brackets of the method call can be omitted.

 

Bug Fixes 

·         #3290486 - AbstractClassWithoutAbstractMethod no longer flags
marker interfaces as abstract classes that do not define a method.

·         #3202691 - ClassNameRule rule is changed to handle $ in the class
name, which is in Inner and Nested classes by default.

·         #3206167 - VariableNameRule now has a violation message that
states the name of the variable and the regex it did not match.

·         #3206667 - FieldName, VariableName, MethodName, ParameterName,
UnusedVariable, PropertyName, and UnusedPrivateField violations message now
contains the class name of the enclosing class. This helps you configure an
exclude.

·         #3206258 - LoggerForDifferentClass rule now accepts MyClass.name
as a valid name for the logger.

·         #3206238 - The DuplicateNumberLiteral rule now allows you to
ignore literals in the 1.2d, 1.2f, and 1.2G format.

·         #3207628 - The UnusedPrivateMethodParameter rule now allows you to
ignore parameters by name. By default, parameters named 'ignore' and
'ignored' do not trigger a violation. You can configure this with the
'ignoreRegex' property on the rule.

·         #3205696 - The ConsecutiveStringConcatenation rule no longer
suggesting that you join numbers together, it only suggests joining strings
together.

·         #3206150 - Fixed UnusedGroovyImport rule so that imports with
aliases are ignored and do not cause violations.

·         #3207605 - Fixed UnusedPrivateMethod rule to recognize static
method references.

·         #3207607 - Fixed UnusedPrivateMethod rule to recognize access of
privately defined getters and setters as properties.

·         #3205697 - Fixed bug where the source line displayed for annotated
nodes was sometimes showing just the annotation and not the node.

·         #3288895 - Expand default test file regex pattern to include
*TestCase

·         #3291474 - Enhance StaticDateFormatFieldRule to also check for
static fields initialized to a DateFormat, e.g. static final DATE_FORMAT =
DateFormat.getDateInstance(DateFormat.LONG)

·         #3291559 - Enhance StaticCalendarFieldRule to also check for
untyped static fields that are initialized to a Calendar, e.g. static final
CALENDAR = Calendar.getInstance()

·         #3293429 - Fix UnnecessaryNullCheck duplicate violations.

·         #3295887 - Fix AddEmptyString duplicate violations.

·         #3299713 - Fix ImportFromSamePackage, UnnecessaryGroovyImport:
Star import.

·         #3300225 - Fix UnnecessaryGroovyImport: Check static imports.

·         #3290324 - Fix UnnecessarySemicolon: the contents of multiline
strings and GStrings are no longer checked, just the strings themselves. For
example, embedding JavaScript or Java within a Multi-line String would
previously trigger the violation.  

·         #3305896 - Fix LoggerForDifferentClass: The rule now correctly
handles inner classes (that are not static)

·         #3305019 - Updated the EmptyCatchBlockRule so that exceptions
named ignore or ignored will not trigger errors. The name is configurable. 

·         #3309062 - UnnecessaryGroovyImportRule handles static imports
incorrectly

-          Fixed the Explicit[Collection]Instantiation rules so that the
error messages are more descriptive.  

-          Fixed the InconsistentPropertySynchronization rule so that it
recognizes the new @Synchronized annotation.

·         #3308930 - LoggerWithWrongModifiersRule now contains a parameter
'allowProtectedLogger' so that loggers can also be instantiated as
'protected final LOG = Logger.getLogger(this.class)'. Also, it has a
'allowNonStatic' logger property, that allows you to create a non static
logger.

·         #3308930 - LoggerForDifferentClassRule now contains a parameter
'allowDerivedClasses'. When set, a logger may be created about
this.getClass(). 

·         #3309748 - FieldName:Do not treat non-static final fields as
constants

·         #3310413 - Fix UnnecessaryPublicModifier does not catch public on
constructors.

·         #3310521 - For all ExplicitCallToXxxMethod rules: Ignore calls to
super.Xxx(). Patch from René Scheibe

·         #3313550 - Some HTML violation descriptions in the properties
files were not well-formed HTML. This has been fixed.

·         #3205688 - Fixed false positives in
UseAssertEqualsInsteadOfAssertTrue when using the JUnit assertFalse method.

Breaking Changes **** 

·         Moved the following rules out of the "basic" ruleset into the new
"serialization" ruleset:

o   SerialVersionUID

o   SerializableClassMustDefineSerialVersionUID

·         [Developer] Moved import-specific helper methods out of
AbstractRule into ImportUtil.

·         [Developer] The ExplicitTypeInstantiationAstVisitor is now an
abstract class that requires you to specify a custom violation message. This
should affect no one, but it is a backwards breaking change.

Thanks 

*	Thank you to Victor Savkin for sending in a patch with the
ForLoopShouldBeWhileLoop, UnnecessaryElse, StatelessSingleton,
PublicInstanceField, and EmptyCatchBlock rules.
*	Thank you to Jan Ahrens and Stefan Armbruster for the
SpockIgnoreRestUsed rule.
*	Thank you to Rob Fletcher and Klaus Baumecker for the
SwallowThreadDeath rule.
*	Thank you to Erik Pragt for the MisorderedStaticImports rule.
*	Thank you to Marcin Erdmann for the MisorderedStaticImports,
ClosureAsLastMethodParameterInBracketsRule, and
UnnecessaryBracketsForMethodWithClosureCall rules.
*	Thank you to Hubert 'Mr. Haki' Klein Ikkink for updating the
ConfusingMethodName rule.
*	Thank you to René Scheibe for the ExplicitLinkedHashMapInstantiation
rule and UnnecessaryGroovyImportRule and ExplicitCallToXxxMethod patches.

Visit the CodeNarc Home Page <http://codenarc.sourceforge.net/> 

 

[Codenarc-developer] Renamed UnnecessaryBracketsForMethodWithClosureCall

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

FYI.  I renamed the UnnecessaryBracketsForMethodWithClosureCall rule to
UnnecessaryParenthesesForMethodCallWithClosure. The word "brackets" is often
used to (also) refer to [ ] or < >. The Groovy docs seem to use
"parentheses" or "parens" (e.g. h
<http://groovy.codehaus.org/Groovy+style+and+language+feature+guidelines+for
+Java+developers#GroovystyleandlanguagefeatureguidelinesforJavadevelopers-Om
ittingparentheses>
ttp://groovy.codehaus.org/Groovy+style+and+language+feature+guidelines+for+J
ava+developers#GroovystyleandlanguagefeatureguidelinesforJavadevelopers-Omit
tingparentheses)

 

Holy crap that is a long name, though.

 

Chris

Re: [Codenarc-developer] Preparing for CodeNarc 0.14?

[<chr...@we...>]

I agree. That occurred to me as well.

-----Original Message-----
From: Hamlet DArcy [mailto:ham...@ca...] 
Sent: Wednesday, June 08, 2011 1:11 PM
To: Mair, Christopher
Cc: cod...@li...
Subject: Re: [Codenarc-developer] Preparing for CodeNarc 0.14?

Why don't we actually create a branch when the release happens? 
It's not that hard in subversion. 



----- Original Message -----
> Great. I suggest we move forward with 0.14 and not write any new
> rules for the next week or so. That way if bugs come in we can fix
> them quickly and make a release of bug fixes without worrying about
> mixing new features and bug fixes into a point release.
> 
> 
> 
> ----- Original Message -----
> > Excellent. Thanks very much for doing that and for fixing the
> > outstanding bugs.
> >
> > Right now, my preference is to just go ahead and move toward the
> > 0.14
> > release.
> >
> > -----Original Message-----
> > From: Hamlet DArcy [mailto:ham...@ca...]
> > Sent: Wednesday, June 08, 2011 3:34 AM
> > To: Chris Mair
> > Cc: cod...@li...
> > Subject: Re: [Codenarc-developer] Preparing for CodeNarc 0.14?
> >
> > I am good to go with 0.14.
> >
> > I have tested it fairly extensively against Groovy 1.8.
> >
> > I will try to fix the 3 open bugs in the next day or two.
> >
> > Do you think it is worth it to release a SNAPSHOT or Beta version
> > in
> > Maven so that people can test it out and report defects before the
> > official release? If we publish a SNAPSHOT/Beta and update the
> > Grails & Griffon plugins, then I think a handful of people would
> > test it out.
> >
> > --
> > Hamlet
> >
> > ----- Original Message -----
> > >
> > >
> > >
> > > I am finishing up my intended to do’s leading up to the CodeNarc
> > > 0.14
> > > release.
> > >
> > >
> > >
> > > I know we have a few outstanding bug issues. I may take a look at
> > > fixing one or two of those.
> > >
> > >
> > >
> > > Other than that, is there anything else we are going to try to
> > > get
> > > into this release? I’d like to take a final pass of CodeNarc
> > > “acceptance” testing against a bunch of projects at work.
> > >
> > >
> > >
> > > Chris
> >
> > ------------------------------------------------------------------------------
> > EditLive Enterprise is the world's most technically advanced
> > content
> > authoring tool. Experience the power of Track Changes, Inline Image
> > Editing and ensure content is compliant with Accessibility
> > Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Codenarc-developer mailing list
> > Cod...@li...
> > https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> >
> 

Re: [Codenarc-developer] Preparing for CodeNarc 0.14?

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

Why don't we actually create a branch when the release happens? 
It's not that hard in subversion. 



----- Original Message -----
> Great. I suggest we move forward with 0.14 and not write any new
> rules for the next week or so. That way if bugs come in we can fix
> them quickly and make a release of bug fixes without worrying about
> mixing new features and bug fixes into a point release.
> 
> 
> 
> ----- Original Message -----
> > Excellent. Thanks very much for doing that and for fixing the
> > outstanding bugs.
> >
> > Right now, my preference is to just go ahead and move toward the
> > 0.14
> > release.
> >
> > -----Original Message-----
> > From: Hamlet DArcy [mailto:ham...@ca...]
> > Sent: Wednesday, June 08, 2011 3:34 AM
> > To: Chris Mair
> > Cc: cod...@li...
> > Subject: Re: [Codenarc-developer] Preparing for CodeNarc 0.14?
> >
> > I am good to go with 0.14.
> >
> > I have tested it fairly extensively against Groovy 1.8.
> >
> > I will try to fix the 3 open bugs in the next day or two.
> >
> > Do you think it is worth it to release a SNAPSHOT or Beta version
> > in
> > Maven so that people can test it out and report defects before the
> > official release? If we publish a SNAPSHOT/Beta and update the
> > Grails & Griffon plugins, then I think a handful of people would
> > test it out.
> >
> > --
> > Hamlet
> >
> > ----- Original Message -----
> > >
> > >
> > >
> > > I am finishing up my intended to do’s leading up to the CodeNarc
> > > 0.14
> > > release.
> > >
> > >
> > >
> > > I know we have a few outstanding bug issues. I may take a look at
> > > fixing one or two of those.
> > >
> > >
> > >
> > > Other than that, is there anything else we are going to try to
> > > get
> > > into this release? I’d like to take a final pass of CodeNarc
> > > “acceptance” testing against a bunch of projects at work.
> > >
> > >
> > >
> > > Chris
> >
> > ------------------------------------------------------------------------------
> > EditLive Enterprise is the world's most technically advanced
> > content
> > authoring tool. Experience the power of Track Changes, Inline Image
> > Editing and ensure content is compliant with Accessibility
> > Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Codenarc-developer mailing list
> > Cod...@li...
> > https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> >
> 

Re: [Codenarc-developer] Util Classes

[<chr...@we...>]

That sounds pretty sweet.

-----Original Message-----
From: Hamlet DArcy [mailto:ham...@ca...] 
Sent: Wednesday, June 08, 2011 9:15 AM
To: Mair, Christopher
Cc: cod...@li...
Subject: Re: [Codenarc-developer] Util Classes

I am definitely waiting until after 0.14. 

The point of a ClassNodeUtil is to eventually apply it as a category or mixin onto ClassNode itself. You could even package a .gdsl file with the CodeNarc jar to make IntelliJ IDEA aware of the addition. 

Beyond ClassNodeUtil I don't see any obvious decompositions though. 

----- Original Message -----
> I view *Util classes as potential code smells anyway -- always
> subject to refactoring. If you feel like a ClassNodeUtil class makes
> sense, that sounds fine to me. I'd be inclined to wait until after
> 0.14 to make that change (even though I am confident our test suite
> would catch errors if it introduced any).
> 
> -----Original Message-----
> From: Hamlet DArcy [mailto:ham...@ca...]
> Sent: Wednesday, June 08, 2011 9:04 AM
> To: Mair, Christopher
> Cc: cod...@li...
> Subject: Re: [Codenarc-developer] Util Classes
> 
> I thought about breaking apart AstUtil... but I am not sure about it.
> There is value in having all those methods all in the same place.
> But there would also be value in having a ClassNodeUtil that works
> on ClassNodes.
> 
> ----- Original Message -----
> > I prefer a separate SourceCodeUtil class.
> > 
> > -----Original Message-----
> > From: Hamlet DArcy [mailto:ham...@ca...]
> > Sent: Wednesday, June 08, 2011 5:32 AM
> > To: cod...@li...
> > Subject: [Codenarc-developer] Util Classes
> > 
> > THere is a new SourceCodeUtil class in the codebase (pulled in from
> > a
> > patch).
> > 
> > Marcin asked if this code should be in a parent class somewhere, or
> > what. Chris, do you have an opinion on this?
> > 
> > --
> > Hamlet D'Arcy
> > ham...@ca...
> > 
> > 
> > ------------------------------------------------------------------------------
> > EditLive Enterprise is the world's most technically advanced
> > content
> > authoring tool. Experience the power of Track Changes, Inline Image
> > Editing and ensure content is compliant with Accessibility
> > Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Codenarc-developer mailing list
> > Cod...@li...
> > https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> > 
> 

Re: [Codenarc-developer] Util Classes

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

I am definitely waiting until after 0.14. 

The point of a ClassNodeUtil is to eventually apply it as a category or mixin onto ClassNode itself. You could even package a .gdsl file with the CodeNarc jar to make IntelliJ IDEA aware of the addition. 

Beyond ClassNodeUtil I don't see any obvious decompositions though. 

----- Original Message -----
> I view *Util classes as potential code smells anyway -- always
> subject to refactoring. If you feel like a ClassNodeUtil class makes
> sense, that sounds fine to me. I'd be inclined to wait until after
> 0.14 to make that change (even though I am confident our test suite
> would catch errors if it introduced any).
> 
> -----Original Message-----
> From: Hamlet DArcy [mailto:ham...@ca...]
> Sent: Wednesday, June 08, 2011 9:04 AM
> To: Mair, Christopher
> Cc: cod...@li...
> Subject: Re: [Codenarc-developer] Util Classes
> 
> I thought about breaking apart AstUtil... but I am not sure about it.
> There is value in having all those methods all in the same place.
> But there would also be value in having a ClassNodeUtil that works
> on ClassNodes.
> 
> ----- Original Message -----
> > I prefer a separate SourceCodeUtil class.
> > 
> > -----Original Message-----
> > From: Hamlet DArcy [mailto:ham...@ca...]
> > Sent: Wednesday, June 08, 2011 5:32 AM
> > To: cod...@li...
> > Subject: [Codenarc-developer] Util Classes
> > 
> > THere is a new SourceCodeUtil class in the codebase (pulled in from
> > a
> > patch).
> > 
> > Marcin asked if this code should be in a parent class somewhere, or
> > what. Chris, do you have an opinion on this?
> > 
> > --
> > Hamlet D'Arcy
> > ham...@ca...
> > 
> > 
> > ------------------------------------------------------------------------------
> > EditLive Enterprise is the world's most technically advanced
> > content
> > authoring tool. Experience the power of Track Changes, Inline Image
> > Editing and ensure content is compliant with Accessibility
> > Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Codenarc-developer mailing list
> > Cod...@li...
> > https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> > 
> 

Re: [Codenarc-developer] Preparing for CodeNarc 0.14?

[<chr...@we...>]

Agreed.

-----Original Message-----
From: Hamlet DArcy [mailto:ham...@ca...] 
Sent: Wednesday, June 08, 2011 9:05 AM
To: Mair, Christopher
Cc: cod...@li...
Subject: Re: [Codenarc-developer] Preparing for CodeNarc 0.14?

Great. I suggest we move forward with 0.14 and not write any new rules for the next week or so. That way if bugs come in we can fix them quickly and make a release of bug fixes without worrying about mixing new features and bug fixes into a point release. 



----- Original Message -----
> Excellent. Thanks very much for doing that and for fixing the
> outstanding bugs.
> 
> Right now, my preference is to just go ahead and move toward the 0.14
> release.
> 
> -----Original Message-----
> From: Hamlet DArcy [mailto:ham...@ca...]
> Sent: Wednesday, June 08, 2011 3:34 AM
> To: Chris Mair
> Cc: cod...@li...
> Subject: Re: [Codenarc-developer] Preparing for CodeNarc 0.14?
> 
> I am good to go with 0.14.
> 
> I have tested it fairly extensively against Groovy 1.8.
> 
> I will try to fix the 3 open bugs in the next day or two.
> 
> Do you think it is worth it to release a SNAPSHOT or Beta version in
> Maven so that people can test it out and report defects before the
> official release? If we publish a SNAPSHOT/Beta and update the
> Grails & Griffon plugins, then I think a handful of people would
> test it out.
> 
> --
> Hamlet
> 
> ----- Original Message -----
> > 
> > 
> > 
> > I am finishing up my intended to do’s leading up to the CodeNarc
> > 0.14
> > release.
> > 
> > 
> > 
> > I know we have a few outstanding bug issues. I may take a look at
> > fixing one or two of those.
> > 
> > 
> > 
> > Other than that, is there anything else we are going to try to get
> > into this release? I’d like to take a final pass of CodeNarc
> > “acceptance” testing against a bunch of projects at work.
> > 
> > 
> > 
> > Chris
> 
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> 

Re: [Codenarc-developer] Util Classes

[<chr...@we...>]

I view *Util classes as potential code smells anyway -- always subject to refactoring. If you feel like a ClassNodeUtil class makes sense, that sounds fine to me. I'd be inclined to wait until after 0.14 to make that change (even though I am confident our test suite would catch errors if it introduced any).

-----Original Message-----
From: Hamlet DArcy [mailto:ham...@ca...] 
Sent: Wednesday, June 08, 2011 9:04 AM
To: Mair, Christopher
Cc: cod...@li...
Subject: Re: [Codenarc-developer] Util Classes

I thought about breaking apart AstUtil... but I am not sure about it. There is value in having all those methods all in the same place. But there would also be value in having a ClassNodeUtil that works on ClassNodes. 

----- Original Message -----
> I prefer a separate SourceCodeUtil class.
> 
> -----Original Message-----
> From: Hamlet DArcy [mailto:ham...@ca...]
> Sent: Wednesday, June 08, 2011 5:32 AM
> To: cod...@li...
> Subject: [Codenarc-developer] Util Classes
> 
> THere is a new SourceCodeUtil class in the codebase (pulled in from a
> patch).
> 
> Marcin asked if this code should be in a parent class somewhere, or
> what. Chris, do you have an opinion on this?
> 
> --
> Hamlet D'Arcy
> ham...@ca...
> 
> 
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> 

Re: [Codenarc-developer] Preparing for CodeNarc 0.14?

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

Great. I suggest we move forward with 0.14 and not write any new rules for the next week or so. That way if bugs come in we can fix them quickly and make a release of bug fixes without worrying about mixing new features and bug fixes into a point release. 



----- Original Message -----
> Excellent. Thanks very much for doing that and for fixing the
> outstanding bugs.
> 
> Right now, my preference is to just go ahead and move toward the 0.14
> release.
> 
> -----Original Message-----
> From: Hamlet DArcy [mailto:ham...@ca...]
> Sent: Wednesday, June 08, 2011 3:34 AM
> To: Chris Mair
> Cc: cod...@li...
> Subject: Re: [Codenarc-developer] Preparing for CodeNarc 0.14?
> 
> I am good to go with 0.14.
> 
> I have tested it fairly extensively against Groovy 1.8.
> 
> I will try to fix the 3 open bugs in the next day or two.
> 
> Do you think it is worth it to release a SNAPSHOT or Beta version in
> Maven so that people can test it out and report defects before the
> official release? If we publish a SNAPSHOT/Beta and update the
> Grails & Griffon plugins, then I think a handful of people would
> test it out.
> 
> --
> Hamlet
> 
> ----- Original Message -----
> > 
> > 
> > 
> > I am finishing up my intended to do’s leading up to the CodeNarc
> > 0.14
> > release.
> > 
> > 
> > 
> > I know we have a few outstanding bug issues. I may take a look at
> > fixing one or two of those.
> > 
> > 
> > 
> > Other than that, is there anything else we are going to try to get
> > into this release? I’d like to take a final pass of CodeNarc
> > “acceptance” testing against a bunch of projects at work.
> > 
> > 
> > 
> > Chris
> 
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> 

Re: [Codenarc-developer] Util Classes

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

I thought about breaking apart AstUtil... but I am not sure about it. There is value in having all those methods all in the same place. But there would also be value in having a ClassNodeUtil that works on ClassNodes. 

----- Original Message -----
> I prefer a separate SourceCodeUtil class.
> 
> -----Original Message-----
> From: Hamlet DArcy [mailto:ham...@ca...]
> Sent: Wednesday, June 08, 2011 5:32 AM
> To: cod...@li...
> Subject: [Codenarc-developer] Util Classes
> 
> THere is a new SourceCodeUtil class in the codebase (pulled in from a
> patch).
> 
> Marcin asked if this code should be in a parent class somewhere, or
> what. Chris, do you have an opinion on this?
> 
> --
> Hamlet D'Arcy
> ham...@ca...
> 
> 
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> 

Re: [Codenarc-developer] Preparing for CodeNarc 0.14?

[<chr...@we...>]

Excellent. Thanks very much for doing that and for fixing the outstanding bugs.

Right now, my preference is to just go ahead and move toward the 0.14 release.

-----Original Message-----
From: Hamlet DArcy [mailto:ham...@ca...] 
Sent: Wednesday, June 08, 2011 3:34 AM
To: Chris Mair
Cc: cod...@li...
Subject: Re: [Codenarc-developer] Preparing for CodeNarc 0.14?

I am good to go with 0.14. 

I have tested it fairly extensively against Groovy 1.8. 

I will try to fix the 3 open bugs in the next day or two. 

Do you think it is worth it to release a SNAPSHOT or Beta version in Maven so that people can test it out and report defects before the official release? If we publish a SNAPSHOT/Beta and update the Grails & Griffon plugins, then I think a handful of people would test it out. 

--
Hamlet

----- Original Message -----
> 
> 
> 
> I am finishing up my intended to do’s leading up to the CodeNarc 0.14
> release.
> 
> 
> 
> I know we have a few outstanding bug issues. I may take a look at
> fixing one or two of those.
> 
> 
> 
> Other than that, is there anything else we are going to try to get
> into this release? I’d like to take a final pass of CodeNarc
> “acceptance” testing against a bunch of projects at work.
> 
> 
> 
> Chris

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Codenarc-developer mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-developer

Re: [Codenarc-developer] Util Classes

[<chr...@we...>]

I prefer a separate SourceCodeUtil class.

-----Original Message-----
From: Hamlet DArcy [mailto:ham...@ca...] 
Sent: Wednesday, June 08, 2011 5:32 AM
To: cod...@li...
Subject: [Codenarc-developer] Util Classes

THere is a new SourceCodeUtil class in the codebase (pulled in from a patch). 

Marcin asked if this code should be in a parent class somewhere, or what. Chris, do you have an opinion on this? 

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


------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Codenarc-developer mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-developer

[Codenarc-developer] Util Classes

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

THere is a new SourceCodeUtil class in the codebase (pulled in from a patch). 

Marcin asked if this code should be in a parent class somewhere, or what. Chris, do you have an opinion on this? 

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

Re: [Codenarc-developer] Preparing for CodeNarc 0.14?

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

All the open bugs in CodeNarc are now closed. 

Do you know of bugs that are not in the version tracker? If you do, be sure to put them in there. I can fix a few. 

Thanks, 



----- Original Message -----
> I am good to go with 0.14.
> 
> I have tested it fairly extensively against Groovy 1.8.
> 
> I will try to fix the 3 open bugs in the next day or two.
> 
> Do you think it is worth it to release a SNAPSHOT or Beta version in
> Maven so that people can test it out and report defects before the
> official release? If we publish a SNAPSHOT/Beta and update the
> Grails & Griffon plugins, then I think a handful of people would
> test it out.
> 
> --
> Hamlet
> 
> ----- Original Message -----
> >
> >
> >
> > I am finishing up my intended to do’s leading up to the CodeNarc
> > 0.14
> > release.
> >
> >
> >
> > I know we have a few outstanding bug issues. I may take a look at
> > fixing one or two of those.
> >
> >
> >
> > Other than that, is there anything else we are going to try to get
> > into this release? I’d like to take a final pass of CodeNarc
> > “acceptance” testing against a bunch of projects at work.
> >
> >
> >
> > Chris
> 

Re: [Codenarc-developer] Preparing for CodeNarc 0.14?

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

I am good to go with 0.14. 

I have tested it fairly extensively against Groovy 1.8. 

I will try to fix the 3 open bugs in the next day or two. 

Do you think it is worth it to release a SNAPSHOT or Beta version in Maven so that people can test it out and report defects before the official release? If we publish a SNAPSHOT/Beta and update the Grails & Griffon plugins, then I think a handful of people would test it out. 

--
Hamlet

----- Original Message -----
> 
> 
> 
> I am finishing up my intended to do’s leading up to the CodeNarc 0.14
> release.
> 
> 
> 
> I know we have a few outstanding bug issues. I may take a look at
> fixing one or two of those.
> 
> 
> 
> Other than that, is there anything else we are going to try to get
> into this release? I’d like to take a final pass of CodeNarc
> “acceptance” testing against a bunch of projects at work.
> 
> 
> 
> Chris

[Codenarc-developer] Preparing for CodeNarc 0.14?

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

I am finishing up my intended to do's leading up to the CodeNarc 0.14
release.

 

I know we have a few outstanding bug issues. I may take a look at fixing one
or two of those.

 

Other than that, is there anything else we are going to try to get into this
release? I'd like to take a final pass of CodeNarc "acceptance" testing
against a bunch of projects at work. 

 

Chris

Re: [Codenarc-developer] UnnecessaryEqualityWithNull rule

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

I think, as is currently stands, you are correct. 
For it to be useful we need to find things like: 

def x = 'x'
def y = 'y'
x = null
if (y.equals(x)) {
    ...
}

Which we don't have yet (but at some point would be nice). 



----- Original Message -----
> I prefer x == null, too. But that "preference" is already handled by
> the ExplicitCallToEqualsMethod rule, right?
> 
> I'm not sure I see the value in the UnnecessaryEqualityWithNull rule,
> given how Groovy does let you call equals() on null.
> 
> -----Original Message-----
> From: Hamlet DArcy [mailto:ham...@ca...]
> Sent: Monday, June 06, 2011 1:31 AM
> To: Chris Mair
> Cc: cod...@li...
> Subject: Re: [Codenarc-developer] UnnecessaryEqualityWithNull rule
> 
> I never thought of this scenario.
> 
> However, isn't
>   x.equals(null)
> and
>   x == null
> the same thing?
> 
> I'd prefer the latter.
> 
> 
> ----- Original Message -----
> > 
> > 
> > 
> > 
> > The documentation for UnnecessaryEqualityWithNull says
> > 
> > The expression object.equals(null) is always false and is
> > unnecessary.
> > 
> > The object.equals(null) comparison will always return false, since
> > the object is not null. (If the object is null, the program will
> > throw a NullPointerException). This is the basic contract of the
> > equals() method.
> > 
> > 
> > 
> > But this prints true in the GroovyConsole, rather than throwing a
> > NPE:
> > 
> > 
> > 
> > def x = null
> > 
> > println x.equals(null)
> > 
> > 
> > 
> > Any thoughts on what to do with this rule?
> > ------------------------------------------------------------------------------
> > Simplify data backup and recovery for your virtual environment with
> > vRanger.
> > Installation's a snap, and flexible recovery options mean your data
> > is safe,
> > secure and there when you need it. Discover what all the cheering's
> > about.
> > Get your free trial download today.
> > http://p.sf.net/sfu/quest-dev2dev2
> > _______________________________________________
> > Codenarc-developer mailing list
> > Cod...@li...
> > https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> > 
> 
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data
> is safe,
> secure and there when you need it. Discover what all the cheering's
> about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> 

Re: [Codenarc-developer] UnnecessaryEqualityWithNull rule

[<chr...@we...>]

I prefer x == null, too. But that "preference" is already handled by the ExplicitCallToEqualsMethod rule, right?

I'm not sure I see the value in the UnnecessaryEqualityWithNull rule, given how Groovy does let you call equals() on null. 

-----Original Message-----
From: Hamlet DArcy [mailto:ham...@ca...] 
Sent: Monday, June 06, 2011 1:31 AM
To: Chris Mair
Cc: cod...@li...
Subject: Re: [Codenarc-developer] UnnecessaryEqualityWithNull rule

I never thought of this scenario. 

However, isn't 
  x.equals(null)
and 
  x == null
the same thing? 

I'd prefer the latter. 


----- Original Message -----
> 
> 
> 
> 
> The documentation for UnnecessaryEqualityWithNull says
> 
> The expression object.equals(null) is always false and is
> unnecessary.
> 
> The object.equals(null) comparison will always return false, since
> the object is not null. (If the object is null, the program will
> throw a NullPointerException). This is the basic contract of the
> equals() method.
> 
> 
> 
> But this prints true in the GroovyConsole, rather than throwing a
> NPE:
> 
> 
> 
> def x = null
> 
> println x.equals(null)
> 
> 
> 
> Any thoughts on what to do with this rule?
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data
> is safe,
> secure and there when you need it. Discover what all the cheering's
> about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> 

------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
_______________________________________________
Codenarc-developer mailing list
Cod...@li...
https://lists.sourceforge.net/lists/listinfo/codenarc-developer

Re: [Codenarc-developer] InconsistentPropertySynchronization

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

Ah, this looks like a false positive. 

There is no "properties" property, just a getter. So the rule things that setProperties is being generated downstream, which it is not. 

Definitely a false positive and needs to be fixed in the rule. 


----- Original Message -----
> >> That is the intent of the rule.
> >>
> >> It is so that someone doesn't see the value of a property in the
> >> middle
> of a state change.
> 
> But in this case, it looks like the synchronized method is there to
> ensure
> safe lazy-initialization of a read-only cached value. And it is a
> private
> method. That lazy-initialization method just happens to be called
> getProperties(). Is that still an "inconsistent property
> synchronization"?
> 
> e.g.,
> class DbConfigurationProperties {
>         
>         private static final LOG =
> Logger.getLogger(DbConfigurationProperties)
>         private static final DBCONFIGURATION_KEY =
> "DbConfigurationProperties"
>         
>         String dbConfigurationFile
>         Cache cache
>         
>         boolean isEnabled(Client client, Channel channel) {
>                 assert cache
>                 assert client
>                 assert channel
>                 
>                 def properties = getProperties()
>                 def propertyValue =
> properties.getProperty(propertyKey(client, channel.getId()))
>                 propertyValue = propertyValue ?:
> properties.getProperty(propertyKey(client, "*"))
>                 return isTrue(propertyValue)
>         }
>  
>         private synchronized Properties getProperties() {
>                 Properties dbConfigurationProperties =
> cache.get(DBCONFIGURATION_KEY)
>                 if (dbConfigurationProperties == null) {
>                         dbConfigurationProperties =
>                         loadDbConfiguration()
>                         cache.put(DBCONFIGURATION_KEY,
> dbConfigurationProperties)
>                 }
>                 return dbConfigurationProperties
>         }
>                 
>         private String propertyKey(Client client, String channelId) {
>                 return "datasource.${client.id}.${channelId}"
>         }
>         
>         private boolean isTrue(String value) {
>                 return value == null || value.toLowerCase() == "true"
>         }
>  
>         private Properties loadDbConfiguration() {
>                 assert dbConfigurationFile
>                 def props = new Properties();
>                 try {
>                         new File(dbConfigurationFile).withInputStream
>                         {
>                                 inputStream ->
>                                 props.load(inputStream)
>                         }
>                 }
>                 catch (FileNotFoundException e){
>                         LOG.error("Error loading
>                         $dbConfigurationFile: $e")
>                 }
>                 LOG.info "Loaded DBConfiguration properties=$props"
>                 return props
>         }
> }
>  
> --------------------------------------------------------------
> > Hamlet,
> >
> > Is the intent that InconsistentPropertySynchronization cause a
> > violation if the class defines a synchronized getXXX() method but
> > no
> > matching setXXX() method or like-named property exists? I ran into
> > a
> > violation for that for a class at work.
> >
> > Chris
> 
> 
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data
> is safe,
> secure and there when you need it. Discover what all the cheering's
> about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> 

Re: [Codenarc-developer] UnnecessaryEqualityWithNull rule

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

I never thought of this scenario. 

However, isn't 
  x.equals(null)
and 
  x == null
the same thing? 

I'd prefer the latter. 


----- Original Message -----
> 
> 
> 
> 
> The documentation for UnnecessaryEqualityWithNull says
> 
> The expression object.equals(null) is always false and is
> unnecessary.
> 
> The object.equals(null) comparison will always return false, since
> the object is not null. (If the object is null, the program will
> throw a NullPointerException). This is the basic contract of the
> equals() method.
> 
> 
> 
> But this prints true in the GroovyConsole, rather than throwing a
> NPE:
> 
> 
> 
> def x = null
> 
> println x.equals(null)
> 
> 
> 
> Any thoughts on what to do with this rule?
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data
> is safe,
> secure and there when you need it. Discover what all the cheering's
> about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> 

Re: [Codenarc-developer] Considering new "serializable" ruleset

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

It is fine as long as we're explicit in the release notes about it. 

----- Original Message -----
> 
> 
> 
> 
> I am considering creating a new “serialization” ruleset, and
> including these three rules:
> 
> 
> 
> · SerialPersistentFields (0.14)
> 
> · SerialVersionUID (0.11)
> 
> · SerializableClassMustDefineSerialVersionUID (0.13)
> 
> 
> 
> That implies moving the last two rules, which were released in
> previous versions of CodeNarc. The SerialPersistentFields rule is
> included in the upcoming 0.14 release.
> 
> 
> 
> If I do that, I realize that might cause some (hopefully minor)
> breakage for users that already configured the two existing rules
> within the context of an included rulesets, but not if they are only
> configured within “codenarc.properties” or as individual rules.
> 
> 
> 
> Anyone have opinions on that, one way or another?
> 
> 
> 
> Chris
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data
> is safe,
> secure and there when you need it. Discover what all the cheering's
> about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer
>