|P is for Practical
Re: Perl aesthetics: the good, the bad, the ugly.by PotPieMan (Hermit)
|on May 01, 2002 at 14:48 UTC
On fuction definition: I prefer specifying the parameters up front. In a way, the function is self-documenting if you force yourself to specify the parameters. Of course, you can document your %args hash, but chances are you'll forget. (In my experience, it's better to be skeptical about one's willingness to document.)
Compare the following (which are directly from your writeup):
If I'm new to a project, or if I'm coming back to a project after a few months working on something else, the second version becomes more difficult to use/modify/understand - the method becomes less of a "black box", in my opinion.
I'm going to be somewhat of a heretic here, and say that function definition in other languages, such as C, C++, and Java, looks better and is easier to understand. For example,
For me, the only issue with this is flexibility. If you don't want one of the parameters (say, scoring), you have to overload createIndex with a second instance of the method. Done wrong, this could lead to code duplication. Done right, there is one "base" method that can handle all cases, meaning no code is duplicated. It's just not as flexible as the Perl version.
A lot of my time recently has been spent considering how another programmer sees my code (another programmer was recently hired where previously I was the only one). We had to come up with certain rules for Perl programming, rules that we sort of took for granted in Java. This suggests, as you say, that Perl allows you to be more creative - but you have to weigh your creativity against your need to get the job done. I'm not saying that you can't have both - I program because I am creative. I've found that on the job, you have to be careful about how you program.
Update: Fixed a typo.