In the office I work, we are slowly progressing towards a more controlled manner of programming, we (me, and our lead-developer mainly) are defining templates for OO programming, etc.
This progression led me in to two funny things today.
1) Our lead-developer was peering a piece of software of mine, completely written according to our OO template. It consists of a number of classes, and the inheritance factor is high. This led to some confusion during the review; "Where does this come from?" or "What on earth... Where is that routine?"
2) I took an old module of mine of the shelf (which was OO already) and poored it into the new template. I cut it down from 400 to 180 rules of code, more readable, and less comments needed.
As you can see there is a good side to this as well as a bad side. This has nothing to do with the template that was choosen, as is was very carefully choosen, but it has to do with perl itself.
Perl allows for many notations, for the same goal (eg:
if ( $foo ) { print "yes" } || print "yes if $foo). A lot of these notations come to the same result, but some are known for the fact to do things slightly different (at least, by the perlmonks frequent-reader).
Because of this (and more of these little, very usefull, things in perl) code tends to get sloppy or to written out (people not using the power of perl eg:
my $foo=""; my $bar=""; my %hash=() instead of
my($foo, $bar, %hash) = (("")x2,());
Because it is so hard to write 'decent' code in perl (i am not innocent myself) I think it is only here where you can find different types of questions then 'CGI Programming' and the immens use of 'File::Find'.
Most in
the community are very easily persuaded that $FOO is bad and $BAR is good, and stick with that believe to the end of days. While the good and/or bad of $FOO and $BAR should be re-evaluated for each module (or even routine) you are going to write.
This also contributes to an other one of perls charms (and/or problems) defensive-programming in the wrong direction.
Adding all of these up, you could conclude that perl is very well suitable for templated programming, directed by a good software-architect. More even then a more strict language such as C(++) where thinking this over is much more forced upon you. Luckily perl is very flexibel (that is our reason for love) and we can still write sloppy code that suits our needs, cause software architecture is not always what we want
er formait hyarya.
"Field experience is something you don't
get until just after you need it."
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.