Design for tests section
book-code-complete-2#design-for-tests1 2 "A thought process that can yield interesting design insights is to ask what the system will look like if you design it to facilitate testing. Do you need to separate the user interface from the rest of the code so that you can exercise it independently? Do you need to organize each subsystem so that it minimizes the dependencies on other subsystems? Designing for test tends to result in more formalized class interfaces, which is generally beneficial." book-code-complete-2#design-for-tests1 2
have someone review your pseudocode
book-code-complete-2#one-right-place1 "P.J. Plauger says his major concern is "the principle One Right Place - there should be One Right Place to look for any nontrivial keys of code, and One Right Place to make a likely maintenance change" (Plauger 1993) book-code-complete-2#one-right-place1
book-code-complete-2#keep-less-in-mind-to-not-forget1 2 "The less you have to keep in mind, the smaller the chance that you'll make an error because you forgot one of the many details you needed to remember." book-code-complete-2#keep-less-in-mind-to-not-forget1 2
book-code-complete-2#simple-data-parameter-coupling1 If the abstraction is that the routine expects you to have three specific data elements, and it is only a coincidence that those three elements happen to be provided by the same object, then you should pass the three specific data elements individually. However, if the abstraction is that you will always have that particular object in hand and the routine will do something or other with that object, then you truly do break the abstraction when you expose the three specific data elements. book-code-complete-2#simple-data-parameter-coupling1
book-code-complete-2#microsoft-word-invariant-testing1 2 "In debug mode, Microsoft Word contains code in the idle loop that checks the integrity of the document object every few seconds. This helps to detect data corruption quickly, and it makes for easier error diagnosis." book-code-complete-2#microsoft-word-invariant-testing1 2
book-code-complete-2#members-of-objects-to-routine1 From section 7.5 "How to Use Routine Parameters" (Page 179)
"There are two competing schools of thought about how to pass members of an object to a routine. Suppose you have an object that exposes data through 10 access routines and the called routine needs three of those data elements to do its job. Proponents of the first school of thought argue that only the three specific elements needed by the routine should be passed. They argue that doing this will keep the connections between routines to a minimum; reduce coupling; and make them easier to understand, reuse, and so on. They say that passing the whole object to a routine violates the principle of encapsulation by potentially exposing all 10 access routines to the routine that's called."
"If the abstraction is that the routine expects you to have three specific data elements, and it is only a coincidence that those three elements happen to be provided by the same object, then you should pass the three specific data elements individually. However, if the abstraction is that you will always have that particular object in hand and the routine will do something or other with that object, then you truly do break the abstraction when you expose the three specific data elements." book-code-complete-2#members-of-objects-to-routine1
book-code-complete-2#variable-name-length1 Gorla, Benander, and Benander found that the effort required to debug a program was minimized when variables had names that averaged 10 to 16 characters (1990) book-code-complete-2#variable-name-length1
book-code-complete-2#convention1 The key is that any convention at all is often better than no convention. The convention may be arbitrary. The power of naming conventions doesn't come from the specific convention chosen but from the fact that a convention exists, adding structure to the code and giving you fewer things to worry about. book-code-complete-2#convention1