There's more than one way to do things | |
PerlMonks |
Re^2: coding rulesby Anonymous Monk |
on Jun 10, 2005 at 16:57 UTC ( [id://465603]=note: print w/replies, xml ) | Need Help?? |
I respectfully disagree: if you introduce variables "when they're needed", then it's harder to find out all the variables that are in use in a given function, and what they do. In addition, you need to worry about scoping mistakes, variable masking, and other subtleties that just don't come up when everything is within a single scope.
The full list of variables used in a function is a decent metric for code complexity; the more state information the function needs, the more complicated it is. When you have too many variables in a given function, you should probably refactor it: it's easier to do this when you realize up front how much state your function has embeded in it. If you document the purpose of all your variables up front as well, then the coder has some idea of how much information he'll have to juggle to understand the function. If you keep surprising him with a new working set of data, it's more confusing. And, then you run into issues with variables being accidentally declared in the wrong scope, or masking the wrong variable, or some stupid side effect using my and assignment at the same time. Why risk that kind of annoyance when you don't need to? What's more, having everything commented up front has a slight psychological benefit: it reminds to the maintainer that when he adds a new variable, he should comment it, just like all the others. When the declarations are scattered all over the place, that visual reminder is lost. It's also harder to scan for unused variables: you have to run through the function, find all the declarations, figure out all the scopes, figure out all the shadowing, and decide if the variable is still in use, and if so, are there any scopes in which the variable is not in use. Contrast this with a simpler code layout: where all variables are at the start of the code, and only used within a single scope (the function). Run through the list of variables at the start: grep through the rest of the lines of the function for the variable's name. If it's not in use, just delete the variable. Perhaps it's just because I've just been burned by several thousands of lines of bad code written in this style (multi-thousand line loops, inconsistant indentation, unused variables, multiply shadowed variables, scoping errors in production code, etc.), but I sometimes wonder why anyone really likes just in time declarations. What's the appeal of witholding information? If a section of code is complex enough to introduce a variable into a new scope, it's usually complex enough to deserve it's own name and it's own function. Why not just always put it there in the first place? Better to have a bunch of small, overly simple functions that you can prove correct than one overly-complex function that you can't, or so I've always felt. I normally don't argue with saints on PerlMonks, especially Randal, but I'm curious about the justification for this one. To me, as a casting director, I'd rather see the cast of characters "up front" from reading the programme, rather than wading through the play every time a new character (variable) comes up. Could you please clarify in more detail what the strengths of your method are, and how you avoid the drawbacks I've outlined? I'm genuinely curious as to whether I'm missing something...
--
In Section
Meditations
|
|