![Web Operations: Keeping the Data On Time [Paperback]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_u_gvE-slHuxxrWW2mGTove5bf6yxlhhqoTlXXIjUbdjJ_-lIV6n147SGzDyxGBoNhX5HtXDer47C1Xvwr503wGqhi_OLWRtwZTiJhqL-CRu07ZXZkrkal24luAbptE7slxXTeCCxGnYh0YSh7Jr_zh9vk7YP4eSES2-LfAZbvJx3ZLxMoZp_IG3za6UX-MzRik6j22b3wj2wboX5Jq6DeiUi3C7AU=s0-d)
500 Error AND A Practical Handbook of Software Construction, Second Edition
500 Error AND A Practical Handbook of Software Construction, Second Edition
Code Complete: A Practical Handbook of Software Construction, Second Edition
The tragedy for books that become classics is
that there are many more people who have heard of them (or perhaps also
bought them) than people who have read them. In this case, the fact that
Steve McConnell's "Code Complete" is approximately 900 pages long
doesn't help, either. Even so, this is a book that not only deserves to
be read, but also rewards multiple readings.
The Good: McConnell deserves credit for writing the first (and only?) readable encyclopedia of best practices on software quality, covering topics such as how to build classes, use data and control structures, debug, refactor, and code-tune. Yes, it would be nice if the book was updated to include substantive material on languages like Ruby or Python
The Good: McConnell deserves credit for writing the first (and only?) readable encyclopedia of best practices on software quality, covering topics such as how to build classes, use data and control structures, debug, refactor, and code-tune. Yes, it would be nice if the book was updated to include substantive material on languages like Ruby or Python
(cf. p. 65, Python
"also contains some support for creating larger programs") but, in the
words of Gertrude Stein, "Not everything can be about everything" --
though Code Complete does come pretty close. This book contains an
astonishing number of practical points on a variety of topics. Here is a
quasi-random selection:
a) don't use booleans as status variables (chs.
5, 12), b) when you feel the need to override a function and have it do
nothing, don't; refactor instead (ch. 6),
c) when choosing variable
names, avoid homonyms (ch. 11), d) if you decide to use a goto,
indenting your code properly will be difficult or impossible (ch. 17),
e) trying to improve software quality by increasing the amount of
testing is like trying to lose weight by weighing yourself more often
(ch. 22), f) make your code so good that you don't need comments, and
then comment it to make it even better (ch. 32), and finally the
oft-repeated g) you should try to program into your language, not in it
(ch. 34). McConnell also sprinkles the text with classic words of
wisdom, e.g.
