>> You're right when you say that if your methods are small then final is >> not neccessary. But when looking at the code in most professional >> projects and even the (existing) qi4j runtime long methods of more that >> 10 lines are ubiquitous. So making all possible local variables and >> parameters final is a first step during refactoring that helps scoping >> the method and extracting methods which are either commands or queries. > > And you are applying the wrong medicine for each problem. Sorry I don't understand that. Who said that I don't fix the problems by breaking down methods and classes? This is about communication and intent. If you use it just sporadically you don't need to use it at all as then the sudden use is just surprising and unexpected for the reader of your code. If you use one style, use it consistently.
The bugs I refer to were mostly long methods with multiple assignments to the variables which could only be broken down by removing the variable/parameter reuse (otherwise there would have been multiple return values per extracted method). The bugs themselves were either just simple typos or copy&paste errors (no correction after pasting) or invalid duplicate assignments of references due to complex logic statements and nested conditionals. And as you surely know bugfixing is not always wanted to be accompanied by refactoring as would have been your choice as developer. > > Problem Description; Blocks are sometimes too long to get a quick overview. > Solution; Break the block and method into smaller chunks. Task do this with multiple reused variables. > > Problem Description; I mistakenly re-use the same variable name, and end up > over-writing the wrong one. > Solution; Don't separate the declaration from the assignment. Task find all correct and incorrect assignments and extract assignments from within deep structures. > > Problem Description; Sometime blocks can't be made smaller, and I am incapable > of keeping declarations and assignments together. > Solution; Use final THERE. This shouldn't be neccessary. > > Problem Description; There are 150,000 local variables and method arguments > cluttered with the "final" filler, making the code harder to read. > Solution; Don't use "final" everywhere, only where it matters. As someone already pointed out, you filter a lot when reading code. Or do you consciently read every access modifier or primitive type declaration? > > I am still -1 to a generic "final" filler. I have asked for a real-world > bug-case, where the code doesn't apply to the "Solutions" above, and a hard > to trace bug could have been avoided. I am tired to argue hypothetical cases. Sorry I was happy to get rid of the bugs, I don't keep them around for showing off :) > That is like doing the Java Puzzle games; Code constructed to be > hard/impossible to understand what will really happen. It is exactly that; > Constructions, not common sense applied programming. No unfortunately real world production code. Most programmers are not that skilled. Michael _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
