Misses the point - with a single modification the code doesn't really get any smellier, and you still don't have to look if the method itself refers to the original variable or not. You still haven't proved the harm in making a single modification up top, other than losing the protection of final, which is indeed a shame and I'd love some sort of keyword or style checker for it. I may write one sometime.
On Feb 16, 4:41 pm, "Robert Fischer, Smokejumper Consulting" <[email protected]> wrote: > On Feb 14, 11:22 pm, Reinier Zwitserloot <[email protected]> wrote: > > > And when we need to make another modification, we.... rename the > > parameter to 'reallyOldConfigKey'? > > To deal with this case (configured once, and then configured again), > you've got four options: > 1) Remove final, which you should train yourself to be a sign you're > probably doing something wrong. > 2) Nest method calls ( translateNewerKeyNames(translateOldKeyNames > (oldConfigKey)) ) > 3) Add another intermediate variable (your "reallyOldConfigKey") > 4) *Refactor the code* so you get one method. > > That pain you're seeing? That weird code smell of > "reallyOldConfigKey"? That's the sign you should be refactoring so > that your increasingly complex parameter mangling can get some unit > tests wrapped around it. That sign is obvious when you're using > "final", but easily obscured when you don't. These kinds of signs are > exactly the reason I'm such a fan of 'final': it rapidly exposes bad > coding practices and points when things should be refactored and > cleaned up. > > ~~ Robert. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
