-
Notifications
You must be signed in to change notification settings - Fork 0
Code Complete 2
A true classic. This book soothes my OCD so well, it's wonderful. Certainly a must read for anyone who takes themselves seriously as a programmer.
Also, this book contains invaluable Key Points at the end of each chapter and checklists.
This chapter talks about the importance of metaphors in both science and software development. Metaphors can also prove to be harmful so we have to be careful about using and creating them. It's important to know how far you can take the metaphor so that you don't over-extend it.
It also talks about common software metaphors and which ones are valid. Some good metaphors for software development are: building (as in building a house) and accretion (add to your software systems a small amount at a time, like the way a clam makes its pearl).
Serious software requires careful upfront planning and not doing it is just plain stupid. This chapter glosses over the various pre-coding stages of a project and provides very good checklists to go through when you're building a bigger project.
We also learn that it's far more expensive to make changes later in the project building process than at the start or near it.
For really small projects that no one will ever see (but you) you can choose to do no planning (or very little of it) but still I personally tend to make small 'frameworks' around them so I can scale them more easily if I ever need to.
Preparation for code construction is extremely important and since this is not the topic of the book, the author recommends a couple of dozen books (Page 35) to read if you want to dive more deeply into this part of software making.
All the prep work is done at this point and we move on to construction.
Using programming languages that the programmers don't know and aren't comfortable with cause a major fall in productivity and quality of code.
The author goes through the most popular languages (at the time, 2004) and discusses each one and it's best use cases. Generally - use low-level languages for performance and use higher-level languages for expressiveness and productivity.
Defining coding conventions (style guide, testing, code reviews...) is very important. Naming, formatting, commenting etc. should all be standardized for a project, so that the code base doesn't end up looking like a giant mess.
coming...
