Development Thoughts

These notes are extremely old, but still applicable.

Every tech support question is a failure in the software, the software design or the documentation

The software should tell you what it can do and how to do it.

Determining the quality of OO design

During development there is often a time when the dependence on other objects lessens, the number of public functions and members decreases and the code size shrinks.

These are signs that the design is correct.

The increase in power should exceed the increase in complexity

This is easiest described by a negative example: don’t add an obscure capability that is only used by a minority of users, but that has a complex setting that appears to ‘break’ the program for the average user.

Develop the tools, test suites and debugging aids early on

You will have developed them by the end of the project anyway, so you might as well have them throughout.

Never write the same line of code twice

This used to be done to save space.
Now it is done for maintainability.
If the functionality exists in more than one place, it must be maintained in more than one place.
Bad!
Calling code from multiple places is acceptable, but executing code at multiple places isn’t.

Don’t keep data in more than one place at once

This is the data equivalent of the above code precept.
For example, don’t attempt to maintain a tree and its representation in a dialog simultaneously.
Put the entire tree in the dialog and recover it afterwards, or refer the dialog to the original tree.
Using two structures means that they must both be amended when you edit, move, sort, delete, insert or otherwise amend one of the structures.
And if the second amendment fails (political reference unintended), you’ll need to reverse the first amendment as necessary to reflect it!

Almost never have any constants in the code

OK:

        while (--count >= 0)
        return 1 << bitposition;
        width += 2 * borderwidth;

Not OK:

        rectangle.width = 10;
        if (usertype == 0)
        char temp[256];

References

Apart from the classics such as Brooks, Knuth, K&R and the ARM, these are good, or at the very least, thought-provoking:

• Alger, Jeff, “Secrets of the C++ Masters”, AP Professional, 1995
• Coplien, James, “Advanced C++”, Addison-Wesley, 1992
• Demarco & Lister, “Peopleware : Productive Projects and Teams”, Dorset House, 1987
• Gamma, Helm, Johnson, Vlissides, “Design Patterns”, Addison-Wesley, 1995
• Maguire, Steve, “Writing Solid Code”, Microsoft Press, 1993
• McConnell, Steve, “Code Complete”, Microsoft Press, 1993
• Meyers, Scott , “Effective C++”, Addison-Wesley, 1992
• Meyers, Scott, “More Effective C++”, Addison-Wesley, 1996
• Tognazzini, Bruce, “Tog on Software Design”, Addison-Wesley, 1996