in reply to Meaning of Maintanability and Functionality in Coding Perl

I really appreciate the question and, while being no master, will give some of my own crutches.

The first crutch is seeking peer-review, even if said peer isn't really your peer, but your better in the given field.
There are monks around, who breathe, what I'striving for. To get their critical comments is a premium. If one isn't willing to post ones code to the monastery -- due of whatever reasons. Mine are false pride and cowardice. -- one can go for peers in an more familiar, more comfortable environment that an online community might provide.
Personal note: I dare to discuss most of my code with the two developers at my site. That's good. But I know, when I'm able to face the wrath -- or more plausibly the giggle -- of my fellow monks, my personal maturation has done a quantum leap -- and my code will follow suite.

The second crutch is commenting. Don't go for the meaning of "comment" in an arbitrary programming language (and drop that lore of "real programmers don't comment" -- I rather like to be a good programmer instead of a real one, if those a the choices), but go for the meaning of "comment" in the press. There, a comment is an opinion -- or, at least, an opinionated summary -- of a factual event.
The first comment, I wrote, is my opinion, what the code should do, what I dreamed of its functionality. Sometimes, while writing down those fantasies, I'll see my error in plain language. The second comment isn't a comment following the above definition, but a report. It merely state, what my code has done in a test run.
Now for the hard part: Leave those comments in your code. It's much easier to follow ones intention, if the path from imagination to reality is laid down. As a consultant, who had to review some of my programm, once said after serveral time silently staring on the screen: "Whatever you smoke, I want some of it."

  • Comment on Re: Meaning of Maintanability and Functionality in Coding Perl