Why write a style checker to gain the protection of final when you've got the keyword?
1) Say what you want, but spreading 50 gazillion instances of 'final' in your source file is a pretty fundamental source smell. Even if, for arguments sake, we all agree that final is just the right way to go, then it would STILL be annoying. Eclipse already has an option to consider any changing of parameters (explicitly marked final or not) as a warning/error IIRC). Some sort of ant script or continuous build tool that also includes this rule (as a warning, not an error*) would be a clearly superior solution IMO. 2) Because, as we've been going over and over and over again, I strongly believe your code is cleaner if you allow modification of parameters, but only at the very top of the method. There's no java keyword for this in the first place. *) I consider any warning rolling out of the build process as effectively an error for virtually all intents and purposes, but when in doubt, if the compile/build process CAN produce a working build, then it should produce it and not just stop. On Feb 16, 6:39 pm, Robert Fischer <[email protected]> wrote: > Reinier Zwitserloot wrote: > > > 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. > > > > Why write a keyword style checker to gain "the protection of final" when > you've got "final"? > > At this point, it seems like you're disagreeing to be disagreeable -- you've > admitted that there's a > protection of "final" which is good (and is a shame to lose), you've once > claimed that there was > great harm in using final but failed to demonstrate any real case of that > (and have since abandoned > the claim), and your one major counter-example has been shown to be a code > smell that "final" neatly > exposes. > > If you've changed your mind through the course of this conversation, that's > cool. If not, I'm > apparently missing something and I'd appreciate a refresher of the argument > you're laying out. > > ~~ Robert Fischer. > Grails Training http://GroovyMag.com/training > Smokejumper Consultinghttp://SmokejumperIT.com > Enfranchised Mind Bloghttp://EnfranchisedMind.com/blog > > Check out my book, "Grails Persistence with GORM and > GSQL"!http://www.smokejumperit.com/redirect.html > > Reinier Zwitserloot wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
