Computer Programming Best Practices

April 11, 2010

This is a collection computer programming best practices.  I’ve developed these rules gradually through nearly 30 years of software engineering and coding practice, and I continue to refine them.

I am well aware that not everyone will agree with them.  After all, opinion runs strong within the software development community!  I publish them despite this because they truly ARE best practice.  Following them has produced some of the most effective, bug free, and efficient software of my career, and this is a substantial accomplishment.

My hope is that you’ll read them, learn from them, use them to improve your skills, and find them to be an invaluable reference for your next programming project.  They’ve certainly been an asset to my work, and I am eager to share them with folks who pursue excellence in their software development work.

Best Regards,

-Andrew B. Bartels

General Rules of Computer Programming:

Bartels’ First Rule of Computer Programming:  Start with a plan.  No code should be written until the programmer has (a) a good idea what the requirements are, and (b) a valid technical plan for how to efficiently implement a solution.

Bartels’ Second Rule of Computer Programming:  Be petite.  Code that isn’t written doesn’t have execution time, nor does it need to be debugged.

 

Rules of Software Architecture:

Bartels’ Rule of 3 for Software Architecture:  A well thought out class hierarchy is mandatory; an overly intellectualized class hierarchy becomes a real mess. Keep class structures simple, in general with no more than 3 layers of inheritance.  If you find yourself having to add a fourth layer, go back and re-think the class hierarchy because chances are there will be an advantage to simplify it.

Bartels’ Rule of 90% Code Reuse:  Only about 10% of your application’s code is actually unique in function to your business rules.  The other 90% should be implemented in a reusable code library that can be used in a different context by many other applications.  Re-examine your software design until at least 90% of it comes from generic code libraries.  If you do, you’ll find that you’re writing amazing software in only a fraction of the time!

 

Rules of Data Processing:

Bartels’ First Rule of Data Processing: Touch the data once and only ONCE.  This rule applies double for multithreaded applications.  This simple application model works best:  read the data, process it clear to the finish, then output the result.  Do not hand data off between various threads or code modules, or you’ll introduce unnecessary performance problems.

Bartels’ Second Rule of Data Processing:  Be I/O efficient.  Access only the data you actually need to get the job done, and only access it once (see First Rule of Data Processing).  If that’s not possible with your current data structure, re-organize the data so that it is possible.

Bartels’ Third Rule of Data Processing:  Be platform efficient:  Use native word and memory page sizes that are efficient for the computing platform your program will run on.  For example, some platforms process 32-bit quantities faster than 8-bit or 16-bit values (take Java, for instance).  As a programmer, be informed enough to know what the efficient sizes are for your platform and programming language of choice.

 

Rules of Data Storage:

Bartels’ First Rule of Data Storage:  Store data in the smallest native data unit available for the platform.  A boolean value should be stored as a bit, a small numeric value should be stored as a byte, etc.   This avoids unnecessary ‘data bloating’ in your database.

Bartels’ First Rule for XML:  Don’t use it.  Nope.  Just don’t do it!  Not even if you’ve been taught that it’s a good idea.  XML is terribly inefficient (see First Rule of Data Storage).  Any benefits that come from its ‘flexibility’ are handily outweighed by the extra unnecessary space it occupies and the unnecessary text parsing effort required to process it.

Bartels’ Second Rule for XML:  If you still feel that you need to use XML after reading the First Rule for XML, then think again!  For example you might be forced to use XML when it is an expected format for a third party interface that you cannot change – but even then, carefully consider the other alternatives.

 

Rules of Computing Performance:

Bartels’ First Rule for Computing Performance:  When speed is an issue, test and tune performance on the slowest computer you can find.  Doing so magnifies the areas that are causing the bottle neck, allowing you to more readily see and fix the problems.  Once you’re satisfied with performance on a slow computer, load your software on a fast one and watch it fly!

Bartels’ Second Rule for Computing Performance:  Standard code libraries (that come with C, C++, Java, etc) are almost never the most efficient.  When it absolutely HAS to be faster than anything else, it’s possible to increase performance by writing your own code (see Second Rule of Computer Programming and Rule of 90% Code Reuse).

Leave a Comment