Variations in Programs

Solution Preview

Even though every program that is created is different from every other program, there are known programming guidelines we can look for in every program.

General Programming Guidelines:
- Writing Clearly
- Writing Modular Code
- Breaking Complex Equations into Smaller Pieces
- Overloading Functions
- Making it Work, THEN Making it Fast
- Using Parenthesis
- Using Memory de-allocation
- Exception Handling
- Error Catching - assert and verify
- Using Goto Statements
- Using Templates
- Using Standard Template Libraries (STL)
- Using Variables
- Using Public Member Class Variables
- Using Functions
- Using Constant

* Writing Clearly
Just because you can do something in a single line of code doesn't mean you should. Do not write code just for the compiler; write the code for you and your fellow programmers. It may be you who returns to this code days, months, or years later and can't remember what that complex statement does. Never sacrifice clear code for "efficient" code.
Clearly written code is 'self' commenting, there should be no need for blocks of comments to describe what is going on. If that isn't the case, consider using more descriptive variable names, and breaking the code up into more distinct modules.

* Writing Modular Code
Code should be broken down into smaller pieces in order to make testing easier and to facilitate re-use of code. Functions that span several pages of printed text are hard to follow, harder to debug and are less likely to be reusable in alternative applications. As a general rule, a function should not span more than 2 pages (or 100 lines). Furthermore, two or more functions can be adapted by others for a wider range of uses than one single function.

* Breaking Complex Equations into Smaller Pieces
Complex equations containing many operators should be broken down into smaller pieces, with suitably name local variables to describe the individual portions of the code. This not only makes the code more understandable (self documented), but it is also easier to analyse the values of specific parts of the equation during debugging.

If only locally defined variables are used then writing code in this way is NOT less efficient - the code will run just as fast. However, it is important to constrain the scope of these local variables, which is achieved when you code in a modular fashion. To further aid the compiler you can encapsulate the locally used variables with { }.

// poor
double num=(A * 2 * cos(w * t)) * sin(k * x) * cosh(k * d) + 2 * B * sin(k * x - w * t);

// better
...
double num;
{
double Amp_A = A * 2 * cos(w * t);
double Wave_A = Amp_A * sin(k * x) * cosh(k * d);
doule Amp_B = B * 2;
Wave_B = Amp_B * sin(k * x - w * t);
num = Wave_A + Wave_B
}
...

* Overloading Functions
Overloading functions can be a powerful tool for creating a family of related functions that only differ in the type of data provided as arguments. If not used properly (such as using functions with the same name for different purposes) they can, however, cause considerable confusion. When overloading functions all variations should have the same semantics (be used for the same purpose).

* Making it Work, THEN Making it Fast
Often during development, developers want to get the most "bang" for their money. If you write code that works, and the interface is clear and correct, you can always go back later and make it faster. Strive to make it correct and readable first and fast second. Fast wrong code is still wrong code.

* Using Parenthesis
It is generally a good idea to use parentheses liberally in expressions involving mixed operators to avoid operator precedence problems. Even if the operator precedence seems clear to you, it might not be to others - you should not assume that other programmers know precedence as well as you do.

if(a == b && c == d) // avoid
if((a == b) && (c == d)) // good

x >= 0 ? x : -x; // avoid
(x >= 0) ? x : -x; // good

* Using Memory de-allocation
If you know that a pointer variable is ...