[
https://issues.apache.org/jira/browse/CRUNCH-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13788230#comment-13788230
]
Gabriel Reid commented on CRUNCH-276:
-------------------------------------
I'm certainly in favour of the uncontroversial stuff -- pretty much all of what
you listed, actually. I'm personally not that crazy about making utility
classes final and non-instantiable, but that's just a matter of taste I think
(I see that stuff more as line noise than anything else).
One thing that I think would definitely be nice to do as part of this would be
to add in automatic static analysis as part of the build process, so that stuff
like this would become automatically visible, and therefore (hopefully) not
start to deteriorate after this big cleanup has been done. There is currently
an Eclipse formatting config file included in the source repo, and it would be
good to have a standard static analysis config as well.
> Apply static analysis fixes, improvements
> -----------------------------------------
>
> Key: CRUNCH-276
> URL: https://issues.apache.org/jira/browse/CRUNCH-276
> 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
(v6.1#6144)
