More on this book
Community
Kindle Notes & Highlights
The process of distilling abstract concepts from real-world entities is non-deterministic, and different designers will abstract out different generalities.
If you're passing a parameter among several routines, that might indicate a need to factor those routines into a class that share the parameter as object data.
A class that has only behavior but no data is generally not really a class.
The routine makes modern programming possible.
Some verbs are elastic, stretched to cover just about any meaning.
To name a function, use a description of the return value. A
To name a procedure, use a strong verb followed by an object. A
In object-oriented languages, you don't need to include the name of the object in the procedure name because the object itself is included in the call.
If you pass a parameter to a routine, use it.
Put status or error variables last. By
Assigning the input value to a working variable emphasizes where the value comes from.
If you are passing the same data to many different routines, group the routines into a class and treat the frequently used data as class data.
Actual parameters are the variables, constants, or expressions used in the actual routine calls.
If the anticipated performance gain doesn't justify the bother of profiling the code to verify the improvement, it doesn't justify the erosion in code quality either.
Does the routine's parameter list, taken as a whole, present a consistent interface abstraction?
Does the routine avoid using input parameters as working variables?
In defensive programming, the main idea is that if a routine is passed bad data, it won't be hurt, even if the bad data is another routine's fault.
Assertions check for conditions that should never occur.
Assertions are used to handle errors that should never occur in the code.
Robustness means always trying to do something that will allow the software to keep operating, even if that leads to results that are inaccurate sometimes.
Exceptions are a specific means by which code can pass along errors or exceptional events to the code that called it.
Exceptions weaken encapsulation by requiring the code that calls a routine to know which exceptions might be thrown inside the code that's called.
Don't throw an uncaught exception in a section of code if you can handle the error locally.
Defining some parts of the software that work with dirty data and some that work with clean data can be an effective way to relieve the majority of the code of the responsibility for checking for bad data
Convert input data to the proper form as soon as possible after it's input.
Completely fill any memory allocated so that you can detect memory allocation errors.
Are all exceptions at the appropriate levels of abstraction for the routines that throw them?
Describe the meaning of the approach rather than how the approach will be implemented in the target language.
If you have trouble creating a good name, that usually indicates that the purpose of the routine isn't clear.
Understand the role of each line of code and why it's needed.
If you find yourself staring at the computer screen not knowing where to start, that's a surefire sign that the PPP would make your programming life easier.
Have you defined the problem that the class will solve?
Have you designed each routine by using detailed pseudocode?