Oh, sure we'll use eclipse or whatnot to refactor really big jobs. This one I figured I could do by hand :-)
BTW, I've used FindBugs on both ECJ and MASON in the past (heck, my PhD is from U Maryland). It finds a LOT of non-bugs. But it's found little useful things here and there for us too. We should go through it again.
On Feb 17, 2014, at 5:55 PM, Warren Henning <[log in to unmask]> wrote:
> By the way, a question: when you say you did the refactoring by hand, would it be more reliable to do it using an IDE's refactoring tools (e.g., IntelliJ's)? AFAIK IntelliJ has built-in support for this specific kind of refactoring: https://www.jetbrains.com/idea/webhelp/type-migration.html . They offer free licenses for open source projects.
> Also, you could run the code through a static analysis tool like FindBugs ( http://findbugs.sourceforge.net/ ), which is integrated into all the major Java IDEs, before and after the refactor to see if the refactor introduces any easily-detectable bugs.
> On Mon, Feb 17, 2014 at 10:55 AM, Sean Luke <[log in to unmask]> wrote:
> Inspired by Raymond's discovery, I decided to pull the trigger and perform the long-awaited upgrade of all floats to doubles in Fitness classes. This entailed:
> - Changing floats to doubles
> - Changing various FLOAT.. to DOUBLE..
> - Changing float literals (0.0f, etc.) to double just in case
> - Removing unnecessary casts
> - Slight tweaks to the documentation
> This will be *sort* of non-backward compatible: you'll want to modify your applications so that you don't cast stuff to floats before setting the fitness or else you'll lose out on the extra expressivity.
> It was a lot of by-hand refactoring and I'm sure I messed something up. I'm a bit spooked about committing it, and haven't done so, unless I can get a few people to do some testing for me. Here's the classes which were affected. Can anyone volunteer for me?
> FITNESS METHODS
> SELECTION METHODS
> APPLICATION EXAMPLES