Quote:Original post by DevFred
If you cannot tell immediately whether a variable is local to the function, you have a problem: the function is too big. If it does not fit on one screen, it is too big. It does too much. Split it up. I would even argue that functions with more than 10 lines are too big.
Same with classes. If your class has more than, say, 100 lines, it is too big. Remember the single-responsibility principle. Let your class do exactly one thing. If it does multiple things, split it up.
By the way, modern IDEs such as Eclipse display differently scoped variables differently.
That's totally valid when writing new code and you're responsible for that code. It's a completely different issue when you're dealing with Somebody Else's Code well after they've written it. TheDailyWTF is full of such examples :)
Case in point, I am currently porting a *massive* codebase to Android Native. Eclipse point-blank refuses to do anything but the basic syntax highlighting. I am, not kidding, minus any form of intellisense. For example, to find a variable's declaration I have to search the entire codebase using regex based on what I think the type of the variable is.
Oh, and did I mention there are several "key" files in this project that measures around 20k lines, each? One particular function gives me hand cramps every time I scroll through it. It takes about 30 seconds to compile just that one file :(
Luckily the developer used 'm' to designate scope, unluckily he used it inconsistently. Sometimes it means a local variable, sometimes it means a class variable, sometimes it's a global. More often than not it's a class variable but I can't count on it.
Anyway, the point is, if you have a programmer that insists on writing monolithic functions / classes / files, at least enforce a coding convention that will at least help folks without any good tools to navigate the code :P