Perl Monk, Perl Meditation | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
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
|
|