Every moderately proficient Perl programmer will eventually be faced with the horror that is old code written by people who still thought golf was good programming style. Very recently, my worst experience until now was with code that had the friendly warning "use 5.002;" in the first line. As if that wasn't enough to scare the hell out of me, I was told the code had been written only in 2006 or so. Not just that: It had been devised by somebody I highly respect and know to be extremely intelligent. But an individual who simply hadn't known Perl when he wrote the program.
Here's one of the biggest downsides of the language in action. Somebody who isn't proficient but smart and creative will be able to craft complicated programs that (kind of) serve their complicated purpose and won't be readable by anyone but their inventor. Hackers who know the language well could do the same, but they know better ways to solve the problem at hand than resorting to unnecessary cleverness.
At this point, you already know the program in question doesn't use strictures.
Instead, it does interesting stuff like using the file handles (GLOBs!) of
literal name "0" to N to process N+1 files synchronously or using $_ implicitly
in a scope that spans way over 100 lines. Variables are named appropriately
as $a1, $a2, $a3, $a4 and $aa1, $aa2, $aa3, $aa4. But I mustn't forget my favorite: $hwww!
If you've ever had to deal with a complicated program that uses only globals, you will most certainly agree that the first step to understanding it is to declare those variables lexically in the tightest scope possible. That isolation of contexts makes it a damn sight easier to grok what's happening.
But I digress. This is about how Padre helped me fix this. I'd love to say that I
simply opened the document in the editor, positioned my cursor on one of those
pesky pseudo-globals and hit the "convert this global to a lexical in the tightest
sensible scope" action in the Perl-specific-features menu. You know, it
would walk the scope tree from the occurrence of the variable I highlighted and
find the tightest scope that contains all occurrences of the variable and declare
it there. Furthermore, if it's used as a loop variable a la for($i=0;$i<...;++$i),
it'd detect that its value likely not depended on outside the loop and declare
it there for me, too. But I haven't had the time to actually write that feature yet*.
I still had to figure out the scope of each variable manually. Instead,
once I had declared a variable *somewhere*, I could simply hit "replace this
lexical variable" in the aforementioned Perl menu and have all occurrences
(including "${aa1}" in strings) replaced with a less meaningless name.
This was particularly useful for loop variables which tend to be reused in different
scopes and thus meanings. A normal search/replace would require user interaction
to stop it after the current section of the code. One distraction less
while trying to understand some complicated piece of code.
But this isn't really how Padre saved my day. It's that when this heavy use of the lexical replacement feature triggered a couple of bugs in it, I was able to dive into the implementation head-first and simply fix it. It's just Perl and most of it is actually quite accessible! That's how Padre made my day less miserable. it helped my fix that ugly code and gave me the warm, fuzzy feeling of being in full control of my tools and particularly being able to improve them when I need to.
* The key here is: I could! So could you or any other Perl programmer.
What does not knowing Perl when he wrote the program have to do with naming variables badly or using globals all over the place? I mean, those are things I'd expect a good programmer to avoid in any language. (Especially the variable naming, which doesn't even require knowledge of 'my' or 'local'.)
Re:not knowing Perl or not knowing good practice?
tsee on 2009-03-28T17:12:34
You're right, of course. It's two things at work:
a) not knowing Perl
b) not caring about good practice in programming since programming is seen only as an annoying means to an end.
