Almost Code Complete

It is my belief that every good developer must have read or is reading or atleast intends to read Steve McConnell’s Code Complete. The book essentially is considered to be a bible for software developers. For those focusing more on the coding part of software construction process, reading from Chapter 6 onwards makes sense. I have tried to select some important points out of the chapters focused on coding aspects. Although the whole book is made of important points I just want to underline some key thoughts to take away.

• A class is a collection of data and routines that share a cohesive, well-defined responsibility.
• Tap into the power or being able to work in the problem domain rather than at the low-level implementation domain.
• Abstraction is the ability to view a complex operation in a simplified form.
• Each class should implement one and only one abstract data type. If a class implements more than one type or you can’t figure out what ADT a class implements then reorganize  that class into more organized classes.
• When you design a class, check each public routine if there is a need for its complement.
• Each interface consists of a programmatic part and a semantic part. Programmatic part consists of the data types and other attributes of interface that can be enforced by compiler, semantic part contains assumptions about how the interface will be used which cannot be enforced by compiler. Look for ways to convert semantic interface elements to programmatic interface elements using Asserts or other techniques.
• Don’t put a routine into a public interface just because it uses only public routines.
• Code is read far more times than it is written even during initial development.
• To avoid tight coupling, make data private in base classes rather than protected.
• Be critical of classes containing more than about seven data members.
• Follow the Liskov Substitution Principle, which in simple words state that, all the routines defined in the base class should mean the same thing when used in each of it’s derived classes.
• Minimize indirect routine calls, if a object A instantiates an object B, then a routine in A can call routines on object B but should not call any routines of objects provided in object B.
• For better readability, put the parameters in an input modify output order. List the parameters in input only, input and output, and output only order.
• Don’t use routine parameters as working variables, store it in a local copy and use that for modification.
• Use error handling code for conditions you expect to occur, use assertions for conditions that should never occur.
• Use access routines instead of global data. It just makes it easy to modify them at a single place.
• Don’t dump all the global data at a single place. Make sure that information hiding and ADT are maintained, which might result into global data stored into their meaningful classes.
• Don’t make up phony variables to be used for a case statement. Since they are confusing, use if then statements instead.
• If you have a loop, put any initialization required by the loop just before the loop to make it more readable.
• Loop should follow the rule of a routine, they must perform one and only one function. Its better to break a loop into two to perform unrelated things.
• It is bad practice to use the last value of an index of a loop in the code after the loop. Never assume that a loop will be executed until it’s last step.
• The fact that a design uses inheritance and polymorphism does not make it a good design. Table driven methods sometimes can produce elegant solutions instead.
• Use terms named true and false to check boolean value, using 0 and 1 makes code confusing in some cases.