Programming Rules of Thumb (2024)

a) Subprogram behavior andlength: Subprograms should do precisely ONE conceptual task andnomore. The length of a subprogram should allow it to be easily visuallyinspected; generally no more that one page in length. Similarlyyou should generally not mix input/output andalgorithmic logic in the same subprogram; it is alway a goal toseparate I/O from logic.

b) If a problem is can be decomposed into two or more independently solvableproblems, then solve them independently and after you have implemented and tested theindependent solutions, then combine them into the larger result.This is sometimes known as "Gall's Law":

"Acomplex system that works is invariably found to have evolved from asimple system that worked. The inverse proposition also appears to betrue: A complex system designed from scratch never works and cannot bemade to work. You have to start over, beginning with a working simplesystem."

is a code refactoring rule of thumb todecide when a replicated piece of code should be replaced by a newprocedure. It states that you are allowed to copy and paste the codeonce, but that when the same code is replicated three times, it shouldbe extracted into a new procedure. The rule was introduced by MartinFowler in his text "Refactoring" and attributed to Don Roberts.

Duplication in programming is almost always in indication of poorlydesigned code or poor coding habits. Duplication is a bad practicebecause it makes codeharder to maintain. When the rule encoded in a replicated piece of codechanges, whoever maintains the code will have to change it in allplaces correctly. This process is error-prone and often leads toproblems. If the code exists in only one place, then it can be easilychanged there. This rule is can even be applied to small number oflines of code, or even single lines of code. For example, if you wantto call a function, and then call it again when it fails, it's OK tohave two call sites; however, if you want to try it five times beforegiving up, there should only be one call site inside a loop rather than5 independent calls.

The ninety-ninety rule is a humorous aphorism that states:

"The first 90 percent of the codeaccounts for the first 90 percent of the development time. Theremaining 10 percent of the code accounts for the other 90 percent ofthe development time."
—Tom Cargill, Bell Labs

That the total development time sums to 180% is a wry allusion to thenotorious tendency of software development projects to significantlyoverrun their original schedules. It expresses both the roughallocation of time to easy and hard portions of a programming projectand the cause of the lateness of many projects (that is, failure toanticipate the hard parts). In other words, it takes both more time andmore coding than expected to make a project work.

Never sacrifice clarity for someperceived efficiency. One of the biggest mistakes that newprogrammers make is tweaking code to remove a couple of textual linesof high level code and replace it with a much more complex single lineof code. This is commonly called "bit twiddling". Alwaysremember that most compilers optimize code. Further, there is acorollary to the 90-90 rule known as the "Pareto Principle":

In computer science, the Pareto principlecan be applied to resource optimization by observing that 80% of theresources are typically used by 20% of the operations. In softwareengineering, it is often a better approximation that 90% of theexecution time of a computer program is spent executing 10% of the code(known as the 90/10 law in this context).

Given this knowledge, most "bit twiddling" will have no perceivableimpact on the runtime of most programs as most of them will likely bein the 90% of code that has little impact on the run-time of theprogram. The real efficiency gains come from changing the order ofcomplexity of the algorithm, such as changing from O(N^2) to O(NlogN)complexity. Keep your code clearly and cleanly written and itwill usually be reasonably efficient. Occasionally, after theprogram is written and tested, it might prove to be slower than theproblem specification calls for. On the these few occasions, andonly after you have first optimized the complexity of the algorithm,then instrument or profile the code and find the 10% or less of thecode that PROVABLY causes slow runtime and then optimize that smallcode segment.

Comments on this topic from well respected computer scientists and software engineers:

In computer programming, a namingconvention is a set of rules for choosing the character sequence to beused for identifiers which denote variables, types and functions etc.in source code and documentation. Reasons for using a naming convention(as opposed to allowing programmers to choose any character sequence)include the following:

1) to reduce the effort needed to read and understand source code which supports its maintainability
2) to enhance source code appearance (for example, by disallowing overly long names or unclear abbreviations)

There are lots of naming conventions that are strongly argued for oragainst by various engineers; in reality these are mostly religiousarguments. However, whatever you do, you should follow someconsistent naming style. There is one thing that is common to mostall naming conventions, and that is that the name should be descriptiveof the contents, or a name that is in common programming practice forthe language (such as using i, j, k for loop and array indexes).

Commonly, subprograms should have verb/verb phrase names as asubprogram should specify one specific task (see KISS rule) whichshould be an activity description. Variables should have noun oradjective names as variables represent things or attributes ofsomething. When choosing a name, if you have difficulty in coming upwith adescriptive name this is an indication that your code needsfurther refactoring to improve the clarity of the design and the purpose of subprograms and variables.