crunch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Micah Whitacre (JIRA)" <>
Subject [jira] [Commented] (CRUNCH-276) Apply static analysis fixes, improvements
Date Mon, 07 Oct 2013 16:02:43 GMT


Micah Whitacre commented on CRUNCH-276:

+1 for using Findbugs as long as we configure the report with it.  The Findbugs output without
the HTML is pretty hard to read.

For some of the code styling you can look at the maven-checkstyle-plugin[1].  You should be
able to generate a report without failing the build.

[1] -

> Apply static analysis fixes, improvements
> -----------------------------------------
>                 Key: CRUNCH-276
>                 URL:
>             Project: Crunch
>          Issue Type: Task
>    Affects Versions: 0.7.0
>            Reporter: Sean Owen
>            Priority: Minor
> Browsing through the Crunch code with a static analyzer, I see a number of minor issues
that can be cleaned up, even automatically, by the same tools. 
> Most are likely completely non-controversial since they do not affect the functionality
of the code:
> - Remove unused imports
> - Fix bad javadoc
> - Typos
> - Unnecessary casts
> - Redundant modifiers on interface methods
> - Access modifiers that have no effect (public constructor in private class)
> - Missing @Override, @ Deprecated
> - Bad literals like 0d
> Others are also likely uncontroversial although might be termed a matter of style, although
the changes would be towards standard Sun style; for example:
> - Braces around all blocks
> - No unnecessarily final on locals
> - Unnecessarily inverted conditions
> Some are signature changes, although only for entirely private elements:
> - Making methods static
> - Type weakening
> - Remove use of old classes like Hashtable
> - Declare collections by interface
> - Raw use of generic types
> And finally, there are a few which could conceivably break a caller, but only if doing
something unintended. I want to avoid these unless the likelihood of an issue is very remote:
> - Making utility classes final and non-instantiable -- should not be subclassed or instantiated
> Before I get way into this -- it will likely touch 200+ files -- thoughts? I believe
Josh was broadly supportive but here are the specifics.

This message was sent by Atlassian JIRA

View raw message