in reply to Phantom Menace: Driving forces behind sloppy code/architecture.

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."