Originally published in 1993, and revised to second edition in 2004, Code Complete: A Practical Handbook of Software Construction by Steve McConnell has been a popular book for software developers for more than two decades.
|Book title||Code Complete: A Practical Handbook of Software Construction, 2nd edition|
|Publication||2004, ISBN-13: 978-0735619678, ISBN-10: 0735619670|
The book Code Complete: A Practical Handbook of Software Construction (2nd edition) should be fascinating reading for anyone working on code development projects. Although in a first approach the book's thickness may be a little intimidating -- 850+ pages -- its thickness is justified by its scope and depth.
The book is divided into seven parts, starting with some basics about the software development process, and then introducing design concepts for creating high-quality codes, for properly using variables and statements to facilitate maintenance, for improving the quality of the software and development time, for taking the software development effort in a holistic way, and for improving software development skills. These parts total 34 chapters that do not need to be followed in a strict order. A number of examples, some related to real-world problems and unexpected consequences (not necessarily related to software), are used to illustrate the importance of design. Cross-references abound and help sailing through the book. Noteworthy, each chapter ends with a summary of related key points that are very helpful to the reader -- especially a hurried one.
Overall, Code Complete addresses topics that perhaps many of us have thought about but likely not in an organized or persuasive fashion (naming variables, for example). The chapters under code improvements and the holistic development effort should be of particular interest to the HPC community because they deal with collaborative construction, refactoring, tuning strategies, impacts of project size, and integration. The following is an interesting quote from the book: "It is not worth sacrificing clarity for a performance gamble." Here is another: "If you start the [software development] process with designs for a Pontiac Aztec, you can test it all you want to, and it will never turn into a Rolls-Royce."
While going through the book, the reader will find justifications for following software development practices that will certainly pay off -- justifications made in an enjoyable way, since the author is rather neutral in exposing facts and ideas.