Good Jigs
My mother made furniture when she was a young woman. At first thought, the process seems quite artistic. Indeed, the furniture was pretty. But the real skill was in making the jigs, which made the cutting of the curves and grooves into a nearly mechanical process. The jigs made her steady hand all the more skilled. The jigs helped her please herself when repeating a process, like making the legs of a French Provincial chair.
Within the realm of computer programming, similar principles affect the over all results.
Reading source code should be like reading good music. The eye sees familiar patterns; the code meets the expectations of the reader. Unusual fingerings have notes, as do unusual code snippets.
At Munson, some programmers wanted binary logic trees for interpreting errors; some one had persuaded them that binary was the fastest. For example, if the error is greater than 100 go one way else the other. At the code for 100, more logic would branch again. The branching could expand and expand.
Doyle and I argued for linear, as in this example. The programmer sees the familiar style and reacts. On the other hand, a binary logic tree requires more analysis by the programmer. Unsnarling a binary logic tree for maintenance might consume more time than ever saved by the binary logic. Indeed, we discovered that linear decision trees could process faster when the most likely conditions came first.
if db_stx = 0 then
process as found
else
if db_stx = 17 then
process as not found
else
if db_stx = 22 then call
else
if db_stx = 50 then call
else
if db_stx = 15 then call
else
really unusual and call crash.
Paradigms
All programs contain a header which identifies the program, its descriptive details, and its function.
All programs write log records for beginning, ending, and important events.
All programs follow department policies concerning syntax and layout.
Programs trap all errors. An inquiry into a database should generate Found or Not Found. The program should report any unexpected result.
Programs follow correct procedures for round-off, table lookups, formatting, and parsing. Unusual algorithms require proof of correctness and approval.
A hundred lines of standard paradigms has far more merit than a thousand lines of cryptic code.
Libraries require good packaging and good doc. David Doyle wrote many complex routines; some had embedded assembly code. His testing was complete; his doc was clear and thorough; his interfaces were straight forward and familiar. We all benefited.
Patterns
When I have had control over programming at a business, I have encouraged that creativity be confined and controlled. For example, usually I aim to have only six kinds of reports. Simple listings, the standard Cascade report, a label printing report, a comparison report, a document creator, and the few complex reports, like Student Accounts Receivable. In the same vein, at National Electronics Corp, Doug Larson wrote a report that created graphs; all other graphs followed the same logic and pattern.
Java Design Patterns
The authors and advocates of Java have formalized many patterns. In COBOL, I have aimed for similar.
Within the realm of computer programming, similar principles affect the over all results.
Reading source code should be like reading good music. The eye sees familiar patterns; the code meets the expectations of the reader. Unusual fingerings have notes, as do unusual code snippets.
At Munson, some programmers wanted binary logic trees for interpreting errors; some one had persuaded them that binary was the fastest. For example, if the error is greater than 100 go one way else the other. At the code for 100, more logic would branch again. The branching could expand and expand.
Doyle and I argued for linear, as in this example. The programmer sees the familiar style and reacts. On the other hand, a binary logic tree requires more analysis by the programmer. Unsnarling a binary logic tree for maintenance might consume more time than ever saved by the binary logic. Indeed, we discovered that linear decision trees could process faster when the most likely conditions came first.
if db_stx = 0 then
process as found
else
if db_stx = 17 then
process as not found
else
if db_stx = 22 then call
else
if db_stx = 50 then call
else
if db_stx = 15 then call
else
really unusual and call crash.
Paradigms
All programs contain a header which identifies the program, its descriptive details, and its function.
All programs write log records for beginning, ending, and important events.
All programs follow department policies concerning syntax and layout.
Programs trap all errors. An inquiry into a database should generate Found or Not Found. The program should report any unexpected result.
Programs follow correct procedures for round-off, table lookups, formatting, and parsing. Unusual algorithms require proof of correctness and approval.
A hundred lines of standard paradigms has far more merit than a thousand lines of cryptic code.
Libraries require good packaging and good doc. David Doyle wrote many complex routines; some had embedded assembly code. His testing was complete; his doc was clear and thorough; his interfaces were straight forward and familiar. We all benefited.
Patterns
When I have had control over programming at a business, I have encouraged that creativity be confined and controlled. For example, usually I aim to have only six kinds of reports. Simple listings, the standard Cascade report, a label printing report, a comparison report, a document creator, and the few complex reports, like Student Accounts Receivable. In the same vein, at National Electronics Corp, Doug Larson wrote a report that created graphs; all other graphs followed the same logic and pattern.
Java Design Patterns
The authors and advocates of Java have formalized many patterns. In COBOL, I have aimed for similar.