in reply to Virtues of Software Engineering

I don't write anything big any more, that way I don't have to bother about design :)

I should qualify that remark, things are never that simple. I used to work on huge monolithic systems, with data dictionaries, naming conventionsm APIs and library versions, the whole software engineering circus. Heaps of time was spent up front using reams of papers to produce reports that were then put on a shelf and never consulted again (I am barely exaggerating).

These days, the "design" is much more diffuse. It's not only in the code. It's in the router configuration, the firewall rules, it's reflected in the database, in fact, all the systems the company uses have to be taken into account. The systems I have to deal with are small pieces loosely joined (a term stolen from David Weinberger). And Perl is a natural fit. Taking a new feed from the accounting system into the payroll. Dealing with bank transfers in a new protocol. If I can't write it in a day or two, it's not worth doing. There must be an easier way. A program that can be written in a day or two is easy enough to keep in your head. Once it's done I write a technical paper, drawing up the loose ends, what assumptions were used, what to look for if things go wrong.

The one thing I do do, however, that greatly improves the creation process, is to make sure that the program always compiles. At the lowest level, this means that when I start typing in a control structure, I type the control skeleton first, and then go back and fill in the statements. Something like:

if( defined( my $r = foo() )) { } else { }

Once I enter that opening brace I keep on going until I type the closing brace following the else. The point being that were I to save the file at that instant, what I just typed would not cause any syntax errors.

By extension, I do the same thing with resource acquisition, such as opening a file, and then closing it. So I'll type something like

open IN, $filename or die "Cannot open $filename for input: $!\n"; close IN;

I will then go back and change that to

open IN, $filename or die "Cannot open $filename for input: $!\n"; while( <IN> ) { } close IN;

... and from there...

open IN, $filename or die "Cannot open $filename for input: $!\n"; while( <IN> ) { next if //; } close IN;

And then go back and fill out the regexp. And so on. I believe that writing code this way is a good habit to get into. I can often type in 50 or 60 lines of code and have it run on the first try. That, as much as anything (not having to go back and fix up silly errors like missing a closing parenthesis and thus losing track of your train of thought) is a big productivity boost. I think this is part of what Code Complete was on about (it's been years since I read it).

Template-directed syntax editors, if you can find one you feel comfortable with, can be a great help. Personally, I hate them, but some people swear by them.

--
g r i n d e r
just another bofh

print@_{sort keys %_},$/if%_=split//,'= & *a?b:e\f/h^h!j+n,o@o;r$s-t%t#u';