Re: Perl Code Quality

This is one of the most frustrating topics simply because you can't take *anyone's* word on it, you have to check yourself or find someone you really trust and have them check it. I took a new job in December and talking to the lead programmer (who I replaced), he told me that the code was very clean and well written, nice standards, etc.

When I got there, the code was just insane. Every variable in the entire program is stored in a huge, arbitrarily nested hash that's passed into and out of every function.

I think some of the most important things are:

Make sure there aren't a lot of anonymous functions that are hard to reuse.
Look for clearly defined function libraries with small functions that take arguments related to the calculations the function will make and returns a value that's related to the functions name.
If it's a web-based project, make sure the HTML and perl code isn't mingled much, if at all.
Make sure any part of code that is potentially confusing to someone who isn't necessarily a perl guru is documented.
A decent gauge of a good perl programmer is one who uses a lot of CPAN modules for core functionality.
The program, if large, should be split into appropriately named modules or classes (which should both be stored in simple reusable .pm files).
Anything the programmer does to make the code more readable and more resuable is A Good Thing and is a testament to the coder.
Of course, if there is a huge time crunch, some of the things mentioned above won't be done or won't be done correctly. However, a good programmer *always* shows effort to make sure code is elegant and reusable.

Comment on Re: Perl Code Quality

Replies are listed 'Best First'.
Re^2: Perl Code Quality by ihb (Deacon) on Sep 26, 2004 at 19:51 UTC
Make sure there aren't a lot of anonymous functions that are hard to reuse. I use a lot of anonymous functions, and that doesn't make it hard to reuse them. On the contrary, I do it to easier reuse code. I use it as an local abstraction technique, and we agree on that abstraction is good, while I at the same time don't want to pollute the global namespace for a function that would only be confusing there since it only has value where it is. In the future, if that piece of code has value outside the lexical scope it's defined in, it's easy to move it out. Sometimes these functions are closures, sometimes they're not. Using anonymous functions is a good sign for me, if done right. I see it as the programmer appreciates abstractions and tight scoping. `ihb` Read argumentation in its context!	[reply] [d/l]
Re^3: Perl Code Quality by FoxtrotUniform (Prior) on Sep 26, 2004 at 23:30 UTC
Make sure there aren't a lot of anonymous functions that are hard to reuse. I use a lot of anonymous functions, and that doesn't make it hard to reuse them. On the contrary, I do it to easier reuse code. I use it as an local abstraction technique, and we agree on that abstraction is good, while I at the same time don't want to pollute the global namespace for a function that would only be confusing there since it only has value where it is. In the future, if that piece of code has value outside the lexical scope it's defined in, it's easy to move it out. Sometimes these functions are closures, sometimes they're not. Edit: I'm not arguing with ihb, I'm adding to the above argument. See also Is it possible to create a sub exclusive to a sub?. Further, function generators often allow a level of abstraction that "ordinary" programming techniques don't: the ability to build code from data, not just operate on data. Look at Specializing Functions with Currying for a simple example of how higher-order functions can promote reuse and remove redundant code. I agree with ihb that anonymous functions (well, let's say "lots of coderefs") are a good sign, not a bad one. I'm sure there are exceptions, but functional abstraction isn't the kind of thing I can easily imagine a mediocre programmer doing. `-- F o x t r o t U n i f o r m Found a typo in this node? /msg me % man 3 strfry`	[reply]