This thing is huge
I've been doing code inspections on various projects, and I have seen things I never believed possible. Last year I wrote an article about how I feel about software development. In that post, I explained why I try to keep methods as small as possible. The reason for that is pretty obvious: It keeps your source code readable. At the time of writing that article, I had just reviewed (and refactored!!!) a method that consisted of 900 lines. I never thought that figure could be beaten, but today I found a method that was even worse.
I was running FxCop on a class library. The library, written in VB.Net, consists of a number of objects which are called by a workflow management application. Each object is responsible for a certain piece of functionality in a number of workflow's. I then saw a message I had never seen when running FxCop: Avoid excessive locals.
Let's first look at what the FxCop documentation at MSDN Wiki says about this message:
A method contains more than 64 local variables, some of which might be compiler generated.
And why is this a bad thing? Well:
A common performance optimization is to store a value in a processor register instead of memory, which is referred to as "enregistering" the value. The common language runtime considers up to 64 local variables for enregistration. Variables that are not enregistered are placed on the stack and must be moved to a register before manipulation. To allow the possibility that all local variables get enregistered, limit the number of local variables to 64.
That's sounds pretty reasonable right? So why was FxCop telling me this? Well, the offending method has 144 local variables, 5 of which were generated by the compiler! I immediately opened the code to see why there were this many local variables. I was shocked to see a single method starting at line 67 and ending at line 2020. A single method of more than 1900 lines! Oh, and the entire class is 2060 lines long...
Obviously, the culprit has left the building. So I'll have to consider what to do. Especially since FxCop found another method with similar problems in the same library: 90 local variables, 2 of which were generated by the compiler, method starts at line 31 and ends at 1093. The class itself is 1101 lines line.
I wonder, is there anyone out there that has encountered even longer methods?