First off, I apologize for the OT. This question is more on the topic of programming in general than Perl.
We've all seen difficult to read code...You know the kind, undescriptive variable names, e.g. $x,$x1,...$xn (where the contents bear no relation to each other), routines that painstakingly produde elaborate results only to have those results later undef'ed without ever being used, comments that are absent or unintelligible, etc.
The list is long, and there are many here who are better qualified to explain obfuscation than I...
However, I am not referring to code in our excellent Obfuscation section. What I am referring to is actual inherited production code. (and I'm not exaggerating)
Dealing with such code can be difficult at best, and after a some time repeatedly throwing up my arms in disgust with a deadline looming, I decided to meditate on ways to approach such code and ways in which one can keep one's sanity in doing so (before quitting my job and becoming a sheepherder or gasp! a PHP web developer). The fact that there are many programmers with many more years of experience than I have, who are still at it, suggests that there must be ways to get the job done without being forcefully relocated to a padded room (although I'm sure that they are comfortable, I rather like living in my apartment).
Here are two resolutions that I have come up with to deal with the situation; I thankfully welcome any additions or suggestions...
When reviewing, maintaining, and adding features to code matching my description above, I often find myself frustrated and angry. Starting now, I resolve that when reviewing code, I will no longer ask "WHY!?" when I don't understand the purpose of a chunk of code, but will instead ask "why?". Since this is working production code, it does work. I will make sure that I understand the code, it's inputs and outputs, and it's place in the larger scheme. Also, it's only work, and it's not worth giving myself an ulcer at an early age.
Even if every important variable is named based on some variation of "temp", the important thing is to produce working code in the timeframe given by my employer. Plus when that variable $a72 that looks like an intermediate variable is used in a routine 100 lines further down the code, resisting the urge to rewrite the code in a more understandable and sane (from my viewpoint) way will reduce the work that I have to do down the line. With that said, I will not hesitate to rewrite code where thoughtful analysis shows that I can do so without a cascading negative effect, and I will take every reasonable opportunity to identify places where I can add code that will assist in debugging.
Whew! (Only two resolutions, but what can I say?) With that said, I would like to say that this is a job, and I realize that, as the saying goes, "If you can't stand the heat...". I welcome any suggestions that I (or another rookie in the same situation) can follow to simplify the task at hand or any resolutions that any of you have come up with when in a similar situation. If there are any good books/articles/etc out there that will help, any references to such would be greatly appreciated.
Thanks,
C
update fixed minor typo.
In reply to Difficult code (Resolutions) by xChauncey
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |