Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Industrial Strength C++: Rules and Recommendations (Prentice Hall Series in Innovative Technology) Paperback – September 1, 1996
"Children of Blood and Bone"
Tomi Adeyemi conjures a stunning world of dark magic and danger in her West African-inspired fantasy debut. Learn more
From the Publisher
This book greatly expands the public domain "Ellemtel" C++ coding standard. Guidelines have been carefully selected and consisely formulated to define a C++ coding standard that should be valid and usable for almost all programmers. Text and code examples explain each individual rule and recommendation. Adopting this book as the company C++ coding standard helps remove an obstacle when trying to be certified for ISO 9000 or CMM. The book covers naming conventions, code organization, resource management, class interface design, object-oriented programming, conversions, error handling, portability, coding style.
Author interviews, book reviews, editors picks, and more. Read it now
Top customer reviews
There was a problem filtering reviews right now. Please try again later.
These authors originated the Ellemtel coding guidelines, the 1992 predecessors to MISRA and lots of others. This 1996 book builds on that earlier set of rules and extends them. Many of these rules seem obvious, like not casting away "const" - I'd add volatile to that rule, as well. Others point out subleties that wouldn't normally occur to most people, like example 7.14 which shows how a const member function can modify the state of its object. Yet other rules don't go far enough, like the ones that recommend against some parts of the standard libraries. Today's list of no-nos includes strcpy and sprintf, because of the well-known malicious attacks that they enable. Of course, I find that some rules need to be taken with a grain of salt. I fully understand the hazards of ill-considered unions, for example. Still, unions can serve useful purposes. They can be helpful when dealing with hardware registers that have different meaning on read access than on write access, or when picking apart floating point numbers for emulation on integer processors. And, depending on the criticality of your application, these rules skip whole ranges of important practices, like checking for numerical overflow in basic arithmetic operations.
The authors do an excellent job of stating each rule and providing motivating examples for it. So why don't I give it that fifth star? The big reason is age - later rule sets spawned by this one have overtaken it. Others rule sets, written for specific environments, address particular needs better than this one-size-fits-all guide, too. Still, if you think that style guides just talk about how many spaces to indent and where to put the capitals, you really need to think again. Despite its age, this will get you thinking in the right direction.
It was translated to English and then released to the community, where it was torn down and tossed around and improved.
Even though there are various places where you can find this book online, it is definitely one that is worth having a physical copy of.
While some of the suggestions in this book do border on stylistic guidelines, the vast majority of it is geared towards making your code readable and easy to debug. The majority of what the author considers to be strictly stylistic is included in an individual appendix at the back of the book.
I will make one simple detracting comment. Some of the information is potentially outdated. The only reason I say this however, is that the book makes the assumption that some operating systems will only support 8.3 format file names. Now that Microsoft Windows has full support for long file names, and Linux has had such support for as long as most of us can remember, this will not often be the case.
These warnings are still good to take into account at times however, as they will let us remember that not every system will be as we expect.
Hands down, I would suggest that every C++ programmer get a copy of this book for their collection.