Industrial Strength C++
Mats Henricson & Erik Nyquist
Prentice Hall, PB, 215 pp.
Every development team has a set of coding guidelines — written or unwritten. Every development team should have a written set of coding guidelines so that newcomers can learn the standard explicitly instead of by osmosis. A consistent set of standards for naming functions (being able to tell who has responsibility for deallocating objects returned by a function, for instance), classes, variables, and resources makes code easier to read AND easier to write. In my opinion, the point of coding guidelines is twofold — teach new team members what's expected, and remove unnecessary decisions from all team members (if there is a plan for how you name variables, it takes less effort to name variables). Code walkthroughs often focus much of their time on issues of coding standards because code which doesn't adhere to the standard is more likely (statistically) to be incorrect. Standards for code formatting are possibly more difficult (more religious, really) than naming conventions (I've always found them so, for reasons which escape me), but the increased use of IDEs which enforce (or attempt to enforce) consistency may be making this concern obsolete.
Industrial Strength C++ is a single-volume set of coding guidelines divided into 15 sections: Naming; Organizing the Code; Comments; Control Flow; Object Life Cycle; Conversions; The Class Interface; new and delete; Static Objects; OOP; Assertions; Error Handling; Parts of C++ to avoid; Size of executables; Portability; and an Appendix on Style. Each section contains from two to twenty specific rules or recommendations along with a series of explanations and examples. The rules and recommendations are both prescriptive (Do This) and proscriptive (Don't Do This).
Many of the recommendations are "common" sense to those of us who have written code for a few years (Rule 11.1 — do not let assertions change the state of the program, or Rule 4.1 — do not change a loop variable inside a for loop block) — but if common sense were actually common there wouldn't be much need for coding guidelines, would there?
Industrial Strength C++ arises from the Ellemtel c++ coding guidelines first written by the authors in 1990 and published to the Internet in 1991 or 1992. As noted in the Introduction, C++ has changed a lot since then. I've had occasion to look back at a couple of my early texts on C++ recently, and I am amazed at the changes in our "standard" language. But that's another column ;-). Suffice to say that there are recommendations in this book about elements of the language that I never use, and have never used — of course I'm no longer an every-day programmer :-(. But even those recommendations make sense once I dig through them.
I can't say that I agree with all of the rules and recommendations here, but I could manage to work with them. And if you wanted to create an "exceptions" document ("We use these guidelines, but here are the changes we‚ve made in them"), you could tailor them easily enough. Given the difficulty of writing a truly useful and reasonably comprehensive set of coding guidelines for a team or a company (or distilling a set from a larger volume like McConnell's Code Complete or Davis' 201 Principles of Software Development), I heartily recommend Industrial Strength C++.
Introduction to the Personal Software Process
Watts S. Humphrey
Addison-Wesley, PB, 278 pp.
I first used a time log when I was a TD at Electronic Arts and had to account for my time so that it could be billed to various projects. The first surprise was in how easy it was to do. The second surprise was in where my time was actually going. Once we had information about where our time was going, the next step was to prioritize projects, and pretty soon we could say "sorry, you're below the line and I do not have time to do that" (a wonderful thing in a company that wants to take every second of your life). If you log your time and find out where it's going, you too may suddenly discover that you have MORE time in your life — or at least that you can make better choices about how you spend the time you do have.
Time logging is probably the central thrust of this book. Watts Humphrey has written a number of significant volumes on software engineering and management, including Managing Technical People, Managing the Software Process, and A Discipline for Software Engineering. Introduction to the Personal Software Process (hereafter, IntroPSP) is his latest and I find it a worthwhile addition to his section of my bookshelf.
I was first introduced to Humphrey's writing by A Discipline for Software Engineering (hereafter, DSE), which introduced the PSP (Personal Software Process) for engineers to improve their ability to create code and to schedule their creation of code. I didn't agree with everything in DSE, especially the emphasis on Lines of Code (LOC) as a productivity metric. But I did (and do) agree with the fundamental idea that you must measure your productivity and your daily activities in order to improve your efficiency. Lord Kelvin is generally credited with the quote "You can't control what you can't measure", and Humphrey takes the idea to heart both in DSE and in IntroPSP.
The heart of the PSP is record what you do and use that information to plan your time. Once you know how long it has previously taken you to do a task of a given size, you can use that knowledge to plan how long a task yet-to-be-done will take. Of course, then you have to accurately estimate the size of a task before you've done it. The PSP covers that, too, although I think it's better covered in DSE than in IntroPSP.
Once you have information on your daily activities, you can use it to determine useful tidbits of information like the number of minutes you spend per debugged LOC, the number of LOC per hour, and so forth. These numbers give you a reasonable idea of your productivity (albeit in a given language, even a given development environment) so that you can correctly determine if a change in your techniques or behavior generates a positive or negative effect upon your efficiency. Without good data you're really just guessing whether that new tool you started using really helps you produce code faster or just moves time from writing code the first time to debugging it later....
IntroPSP is just what it says — a nice little introduction to a more precise (OK, some people would say compulsive) method of time management and what I might call "productivity engineering". I don't really think it takes the place of DSE, but it's a much lighter introduction and contains quite a bit of useful information — the survey or course notes, if you will, to DSE's textbook. It will certainly give you enough information about the PSP to decide if you want to proceed with it or not.
One caveat, however — it appears that Watts Humphrey is now teaching courses in the PSP, which gives him an additional financial incentive in it's popularity and success. I would think carefully (and read both volumes very carefully) before committing myself (or my entire department) to training in any technique claimed to be an across-the-board benefit. It smacks of Silver Bullet Syndrome (see Assessment and Control of Software Risks, by Capers Jones). If you're going to try it, try it with a single person, or a couple of people, first and see what it does for them.
See you next time....
Evan Robinson is the Director of Games Engineering at Rocket Science Games, Inc. Before becoming a manager he was a consultant, programmer, Technical Director, and game developer. You can email him to talk about books, software, development, or the meaning of life.
Copyright © Evan Robinson. All Rights Reserved.