Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

comment on

( #3333=superdoc: print w/replies, xml ) Need Help??
As the title says, this is in no particular order, a number of random points about programming that I think are of exceptional importance.
  1. The most cost-effective method of testing is code reviews. This is true even before you count in benefits in terms of knowledge transfer etc.
  2. The bug is probably in your code. Failing that it is probably in something that changed recently.
  3. You are using version control software and have backups, aren't you?
  4. The hardest class of bugs, and one of the most common causes of failure for large projectgs lies in keeping track of interactions at interfaces. This has been known since the 70's and The Mythical Man-Month.
  5. Most software projects fail. The odds of failure rise sharply with how hard it is for one person to keep track of what is going on. The more people you have, and the longer it is expected to take, the worse your odds are.
  6. When we start a project we inevitably do not know as much as we will learn. Therefore we will make decisions that in hindsight would be better being changed. Plan ahead. If your interfaces hide information (as recommended in references like Code Complete) then you are going to have an easier time in revisiting decisions. This will be even easier if you have a good set of unit tests like the XP people recommend. (Thanks clemburg.)
  7. Programming is about keeping track of ideas. How can you make this easier on yourself?
  8. Have you thought through your boundary cases in detail? Methodically walk through your code and test them, you may be shocked...
  9. One of the most common errors is to reverse the meaning of a flag. This is both an easy error to make, and is hard to catch in reviews. But name variables as yes/no questions and you will almost never make this mistake. Consider starting the name of your next flag with "is"...
  10. Don't make an ass of you and me.
  11. It is typically impossible to list all things that could go wrong. It is generally fairly easy to list conditions under which your code should behave correctly. This observation has enormous consequences for how you should validate user input...
  12. The basic outline of a transaction is that you note that there is work to be done. create a private work area, work in it, and then when the work is complete you make it public. The really nice thing about thinking in terms of transactions is that virtually all failure situations are easy to handle, just log the issue, save your private space (directory etc) somewhere for later inspection, and abort the transaction. If you in addition make a habit of keeping track of work that needs to be done in a table and retry it periodically, you will be amazed at how the system tends to be robust in the face of unexpected problems. The relevance of these points might not sink in for you until the next time a complex sequence of steps breaks, leaving things in an inconsistent state...
  13. It is likely that more truly innovative ideas have come out of play than serious professionalism. Luckily great software does not need to be particularly innovative.
  14. That is a nice shiny wheel you just reinvented...
  15. ...on the other hand the world needs more than one type of wheel...
  16. ...but the best way to create a new wheel is generally to modify an existing one in unexpected ways. For instance though woodworking could have used a wheel earlier, they didn't get one until Tabitha Babbitt modified her spinning wheel into a circular saw (circa 1813 or so).
  17. That which is not automated does not reliably happen.
  18. Be sure you have error checks...
  19. ...but will your messages make sense if things do go wrong?
I know I missed plenty. So please add to the list.

In reply to Random thoughts on programming by tilly

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or or How to display code and escape characters are good places to start.
Log In?

What's my password?
Create A New User
Domain Nodelet?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (3)
As of 2021-10-28 03:58 GMT
Find Nodes?
    Voting Booth?
    My first memorable Perl project was:

    Results (95 votes). Check out past polls.