I find
that when I begin to tackle a problem using sed, I do best if I make a mental list of all the things I want
to do. When I begin coding, I write a script containing a single command that
does one thing. I test that it works, then I add another command, repeating this
cycle until I've done all that's obvious to do. I say what's obvious because my
list is not always complete, and the cycle of implement-and-test often adds
other items to the list. Another approach involves actually typing the list of
tasks into a file, as comments, and then slowly replacing them with sed
commands. If you're one of the rare but highly appreciated breed that actually
documents their code, you can just leave the comments in the script or expand on
them.
It may seem to be a rather tedious process to work this way, and indeed there
are a number of scripts where it's fine to take a crack at writing the whole
script in one pass and then begin testing it. However, the one-step-at-a-time
method is highly recommended for beginners, because you isolate each command and
get to easily see what is working and what is not. When you try to do several
commands at once, you might find that when problems arise, you end up recreating
the recommended process in reverse; that is, removing or commenting out commands
one by one until you locate the problem.
— DD