Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

comment on

( [id://3333] : superdoc . print w/replies, xml ) Need Help??
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."

In reply to Re: Phantom Menace: Driving forces behind sloppy code/architecture. by Sinister
in thread Phantom Menace: Driving forces behind sloppy code/architecture. by vladb

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.