Fill out the comment-header first, then; that's what I do. That informal-prose chatty summary of what the code does and why, what it takes in and what its outpu

Fill out the comment-header first, then; that's what I do. That informal-prose chatty summary of what the code does and why, what it takes in and what its output is, becomes in my mind the spec for the code while I'm writing it, even in casual one-shot Perl filters. It makes it easier for me to choose variable names which inform rather than mystify, because the master reference is staring me in the face as I write. It's also an attitude-anchor for specific tail-end comments to expand on the summary explanation by detailing why a line is as it is and does what it does. YMMV, but, for me, the payoff is an easier time of drawing thoughts together into code, plus, months down the road, an easier time of deciphering why I wrote the code that way.