Phantom Menace: Driving forces behind sloppy code/architecture.

[vladb]

While a lot of our discussions in this monastery revolves around such ever-lasting subjects as CGI Programming and the use of the File::Find module (as per recent statistics displayed here), only a handful touch bases on broader academic subjects ranging from coding styles to design patterns. For an instance, I have a keen interest in specific topics such as Design by Contract. However, the only place in the monastery where I saw a mentioning of this was in the An example of programming by contract post by princepawn, and briefly in Larry vs. Joel vs. Ovid by Ovid.

Yet, I sincerely believe that we should concentrate our meditations on common programming methodologies and approaches in order to curb the still prevailing dominance of sloppy code and poor architecture in numerous scripts/applications crafted by fellow Perl practitioners. In my web consulting business (aside from my full-time job as a programmer), I encounter enough poor scripts that make me shriek in pure agony. Every time I see such code, I recall a quote from the infamous article on Big Ball of Mud:

Indeed, one of the reasons that architecture is neglected is that much of it is "under the hood", where nobody can see it. If the system works, and it can be shipped, who cares what it looks like on the inside?

And…

One reason that software architectures are so often mediocre is that architecture frequently takes a back seat to more mundane concerns such as cost, time-to-market, and programmer skill.

So, aside from a few obvious driving forces behind ‘muddy’ code such as the cost and ‘time-to-market’ factor, programmer skill plays a role as well. Therefore, one of the ways in which we can improve our code quality is to improve our programming skill. But the only way we may hope to improve this skill is through persistent meditation. To this point, I have learnt a lot from PerlMonks. Since the first day I downed my monk robe, I have seen constant improvement in my ability to reduce proportion of ‘muddy’ code in my applications and by this achieve greatly reliable systems. There are other monks who share similar experiences. Take for example coreolyn’s On the Road to Perl Enlightenment, My 100th Post, and New Year's Resolutions post.

Unfortunately, even despite of wealth of information contained within the walls of this holy monastery, there are still a lot of areas left uncovered. To make up for this loss, I often find myself scavenging the vast dumps of the Web for bits and pieces of occasional wisdom. Further, many discussions on the web bring up examples of code written in languages other than Perl, thereby greatly reducing (ease of) applicability of certain methodologies in my programs built entirely in Perl. That’s why I greatly appreciate the work of stephen, for example. He’s done a good job on picking up the subject of Refactoring and describing it to his fellow monks in the language they understand the best – Perl! ;-)

_____________________

$"=q;grep;;$,=q"grep";for(`find . -name ".saves*~"`){s;$/;;;/(.*-(\d+)
+-.*)$/;$_=&#91"ps -e -o pid | "," $2 | "," -v "," "]`@$_`?{print"
++ $1"}:{print"- $1"}&&`rm $1`;print"\n";}

[Sinister]

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

[tjh]

++ vladb

I thoroughly enjoy and use nodes containing programming style, architecture and other like data and also look for it. I usually only find small bits as side comments in various posts.

I've considered starting a series of nodes to solicit data from talented monks on issues like this, but the OT-ness discussions pretty much derailed my urge :) I'll get over the 'derailed' concept, but it's excellent that you brought it up!

I had titles in mind such as:

• Best Practices: OO Architecture Basics
• ": Separating Code, Data, Presentation
• ": Commenting & Docs (POD)
• ": Code Efficiencies, algorithm comparisons
• ": CGI
• ": CGI Security

It's really more of a list than that. I obviously am aware of the excellent collection of nodes on the CGI issues, but it seemed to me to get it all in one thread or node would be a really excellent resource. Very often what looks like a reasonable way to do something doesn't even closely compare to the answers given by real-world-experienced folks here on PM. And seeing samples in Perl is much preferred in my case. Studying algorithms in texts using languages I'm unfamiliar with isn't always helpful.

I guess I'm in a mode for "what are some commonly accepted best practices for ____?"