Yes, you may say. But I just realised a couple of reasons why this is more than a platitude. Maybe they're not new realisations to you, but they made me happy, and the background of my realising them (getting slightly better at doing this stuff) also made me happy, so I thought I'd share the moment.
Good Programming is [not just good, it's even] Better [than that]
If I do stuff right, then I find later on to my delight that I can re-use it easily, and it all fits together nicely. The trivial example that gave rise to this realisation was:
(A) I have a function InsertMultipleValues (see below) that I use all the time to insert stuff into db tables. To make it flexible, it accepts arguments in a hashref.
(B) Then just now I was getting some stuff together for insertion into a db, and I thought "what's the best data structure" and I thought "an array of hashes" so that's what I did.
(C) then I came to put it all together and imagine my delight when I found that instead of a half dozen lines I'd expected to have to write at this point, it came down to InsertMultipleValues($dbh,'tbl_name',$_) for @Values;
Good Programming is [readily identifiable, at least in hindsight, as programming that keeps making things] Better
The other thing I realised was - well, it's often a bit contentious what's good programming, but *I* think one way of telling if something is good programming is whether, over time, one finds that it gives rise to happy events like the above. So one can look back and see "huh, that was good programming, as I now know because it did this and that as well as the other". NOW: my challenge is to be able to smell, sense, figure out, whatever, programming choices that will do that, before I write them, rather than noticing them in retrospect. But noticing them in retrospect is a step in the right direction.
§ George Sherston
Good Programming is [not just good, it's even] Better [than that]
If I do stuff right, then I find later on to my delight that I can re-use it easily, and it all fits together nicely. The trivial example that gave rise to this realisation was:
(A) I have a function InsertMultipleValues (see below) that I use all the time to insert stuff into db tables. To make it flexible, it accepts arguments in a hashref.
(B) Then just now I was getting some stuff together for insertion into a db, and I thought "what's the best data structure" and I thought "an array of hashes" so that's what I did.
(C) then I came to put it all together and imagine my delight when I found that instead of a half dozen lines I'd expected to have to write at this point, it came down to InsertMultipleValues($dbh,'tbl_name',$_) for @Values;
Good Programming is [readily identifiable, at least in hindsight, as programming that keeps making things] Better
The other thing I realised was - well, it's often a bit contentious what's good programming, but *I* think one way of telling if something is good programming is whether, over time, one finds that it gives rise to happy events like the above. So one can look back and see "huh, that was good programming, as I now know because it did this and that as well as the other". NOW: my challenge is to be able to smell, sense, figure out, whatever, programming choices that will do that, before I write them, rather than noticing them in retrospect. But noticing them in retrospect is a step in the right direction.
sub InsertMultipleValues { #----------------------------------------------------------- # Inserts contents of a hashref into the db table specified # (owes a lot to discussion in SOPW (which I looked for # just now but couldn't find, alas) #----------------------------------------------------------- my $dbh = shift; my $table = shift; my $Inserts = shift; my @cols = keys %$Inserts; my @vals = @$Inserts{@cols}; my $cols = join ',', @cols; my $places = '?,' x @vals; chop $places; my $sth = $dbh->prepare("INSERT INTO $table ($cols) VALUES ($place +s)") or die $dbh->errstr; $sth->execute(@vals) or die $dbh->errstr; }
Back to
Meditations