I prefer to minimize the logic in my code. More specifically, I don't really like code that has to do a bunch of testing and branching depending upon all sorts of conditions.
sub foo {
my $thing = shift;
if ('ARRAY' eq ref $thing) {
do_stuff($_) foreach (@$thing);
}
else {
do_stuff($thing);
}
}
That's ugly. I prefer this:
sub foo {
my $thing = shift;
$thing = [$thing] unless 'ARRAY' eq ref $thing;
do_stuff($_) foreach @$thing;
}
In other words, I prefer to enforce consistency as early as possible. There are problems with the above code due to Perl's poor argument handling, but the basic outline is there and you can see how a bit of duplicate code has been removed and the logic is a tad simpler. When conditions become even more complicated, this can be quite a win in code simplicity.
Taking this further, I also don't like hard-coded data in my code. Hard-coded data is likely to change and conditions based upon it break. What I prefer, where hard-coded data are likely to be used, is to ask the objects what the data are. However, given Perl's lack of robust introspection, working with large-scale object models can be trying.
For Bricolage 2.0, David Wheeler has extended Class::Meta to create an OO-RDMBS mapper which pushes most of the mapping logic into the database and provides a rich introspection layer for the objects. The win is not immediately obvious if you haven't worked on the code, but in the Web interface, the win is huge. My REST server and the class it dispatches to, if one ignores the POD and simple getters/setters, is less than 250 lines of code.
For 250 lines of code, we get the ability to search our entire data store via a Web interface, with automatic paging of data sets, ordering of results, etc. Eventually, we'll be adding updating of the data store and that will expand the code, but being able to use introspection means very little hard-coded data.
To drive all of this, I've been learning XSLT. That's where development has, at times, slowed to a crawl. The stylesheets read the XML that's presented and transform the page into HTML (on the client side, but it's done on the server side if the client doesn't support XSLT). Unfortunately, this means that gradual changes to my XSLT affect all of the test outout for the REST system and I have to go back and change many tests. Oops. Time for some refactoring to make this problem go away.
If you're an emacs users, I strongly recommend looking at nxml-mode. It's a great authoring environment for XSLT, because it knows what elements go where. This stops (me, anyway) from having to look up what does what every 5 minutes.
-Dom