Link Details

If I could, I would vote this down twice. What a load of crap. If you have methods that are 200 lines long, then it is hard to keep track of local variables. But then you shouldn't have methods that are 200 lines long. Local variables help you keep track of temporary state. Of course if you have lots of local variables that are related and need to be passed around, you can put them in an object of some sort. But creating special objects or closures just so you don't have mutable variables is stupid. The thing that makes me mad about this kind of drivel is buzzword programmers will start parroting this garbage and we will start seeing unnecessary layer of abstraction, indirection and complexity because "local variables are bad"

Thanks for your refershingly candid response.

If you think that the way to get rid of local variables is to create closures or special objects, you are very much missing the point of the post. The point of the post was to reduce local state. Representing local state as an object does not accomplish this goal. I agree that if people parrot "local variables are bad," this is not good. But that's WHY I wrote the article: it isn't enough to say that they are a code smell, you need to understand why they are a code smell.

p.s. I am using the "rhetorical you," as in "someone," not you personally!

My point was that local state is not bad. My point was local state is good. Now if you have huge functions than it is very easy to abuse what local means. Variables should have as limited scope as possible. I do agree that there are certainly abuses of local variables. One that I find especially irritating is when there is a variable called "returnValue" or some such thing that is declared at the top of a function and then 200 lines later it is returned at the bottom of the function because "returning from more that one place in a function is bad" and going through contortions to not return a value that you have already figured out is good.

In an OO language, I personally use Local State only when I am backed into a corner. But if you have a different feeling about that, rock on. I agree totally with you about "Pascal Style," where variables are declared at the top of a method, and for the contortions people go through to avoid "multiple returns."

The way I think of it is this: if multiple returns are confusing, the problem really is the structure of the method being confusing. Using a "return" variable does not cure the underlying structural problem.

Good article, but October 2006 isn't exactly a "fresh link" for developers