That's a good start, thezip. I'd like to focus on the process a bit.

First off, a project must have an adequate requirements specification. The most deadly danger to production quality code comes from allowing fungible requirements, also known as "marketing really neeeds this in the release," waaaay toooo late.

Second, and this is dramatically more important as teams grow, make absolutely sure all design documents and API's interlock completely and fulfill all required specifications. This is the most crucial step of all, and must precede schedule definition. I think that's where we programmers let planners screw us: we let them create schedules BEFORE we have our design interlock and reviews.

Finally, insist on source control and rigid code review requirements. Again, the larger the team, the more delay caused by uncaught bugs breaking the build.

One could use a number of descriptions for what constitutes well-crafted code depending on what methodology one follows and what the end product is. My deterministic driver code is going to be a lot leaner than an object oriented GUI would be, but I can follow good data separation practices by building data isolation into my meta-data, headers and build structures.

No matter what language, methodology, or end product, you can and should spend the time to craft good self-documenting code. I side with BrowserUK in that the variable names, the declarations, and control structures you choose make a huge difference in the understandability and readability of your code. Variable names such as $invoice_table_index are a lot easier to keep track of than $ii. Proper use of named constants makes a huge difference in understanding data structure indices. When sorting, for example, $a[AGE] <=> $b[AGE] is clear. Similarly, if ( $invoice_table_index < MAX_TABLE_INDEX ) { ... } is easily followed. It's important to lay out your control structures and loops consistently, and it helps to use subroutines to minimize code in the top few levels of branching structures to maintain clarity. I like to define error conditions and recursive termination clauses first, and then build the main-line path. In cases where my code needs to be too tight for layers of subroutines, using macros performs the same code-hiding purpose without sacrificing speed. It is up to me to structure my files such that the macros are as readily available for perusal as subroutines, of course.

There is always the caveat that even the best code is opaque to a "programmer" (quotes intended) who can't be bothered to study code before whacking.

Don Wilde
"There's more than one level to any answer."

In reply to Re: What is "Production Code" ? by samizdat
in thread What is "Production Code" ? by thezip

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


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.