Author: J. Guy Davidson and Kate Gregory
Publisher: Addison-Wesley Professional
Date: December 2021
Pages: 352
ISBN: 978-0137647842
Print: 0137647840
Kindle: B09HTH1X38
Audience: C++ developers
Rating: 5
Reviewer: Mike James
Can C++ be beautiful?

I've explained before that I have a love hate relationship with C++ which boils down to - I love it when I write it and I hate it when I have to read someone else's code. There is no language which lends itself more to being personalized and this is a problem when you are trying to understand it. You could say that this is because C++ is extremely flexible, but I'd say that it is too flexible. Hence there is no language more suited to a book of guidelines for how to write clean, safe and fast code. I'd like to add "standard" to this list from the book's subtitle, but the whole point of the book is to get you to adopt best practices.

The book is based on the well known C++ Core Guidelines, but it presents the same ideas in a more readable and less formal way. Sometimes this is a problem as you aren't always 100% clear what the point is of an example, but in the main this is rare and mostly it's an enjoyable read.  The book provides 30 of the best of the C++ Core Guidelines.

Section 1 is called "Bikeshedding is bad" - well I have happy memories of many a bike shed, but that's another story. The meaning here is that you tend to get wrapped up in what color to paint the bike shed rather than more important and technical issues like will it stay up in a wind. Personally I don't get involved much in bikeshedding because I'm a C++ programmer and hence I don't do anything trivial. The section is on things like write ISO standard C++, try to use default arguments rather than overloading, use initializers, don't write a getter or a setter unless it does something, one name per declaration and finally it's ok to use multiple return statements in a function. I've never been sure about the last one. A hard-line structured programmer like me believes implicitly that a single exit point from all control structures is the only way to write clear code.

Section 2 is called "Don't hurt yourself", presumably a warning about C++ being a foot gun. In this section you will find a set of well known pieces of advice - function parameter lists should be small, don't use templates unless you are forced to, don't share writable data, and so on. 

Section 3 is called "Stop using that" - no there isn't a standard construct called "that" just "this". The idea is that things you have been doing for a while might not be the best way to do things any more. Be careful with pointers, don't create singletons, avoid memset and memcopy, and more. I didn't find this very useful because, apart from singletons, I don't use any of that already.

Section 4 "Use this new thing property" and again not "new" the keyword but "new" the English word. Use tuples for multiple return values, use class enums, keep scopes small, use compile time expressions, use templates... What? I thought we were to stay away from templates? Well perhaps this one is worth the complexification in an effort to be abstract.

Section 5, the final section, "Write code well by default"... If I'm writing code it is always written well by default - until I come back to look at it a few hours later when it is clear I should have avoided default and put some effort into it. The first instruction is to try to write code that is statically typesafe, which is another way of saying don't write anything sophisticated. Prefer immutable to mutable data and perhaps slow your system down to a crawl. Don't declare a variable until you have a value to initialize it with - so much for grouping declarations. Design to enable optimization - but wait I thought that optimization was evil. 

Conclusion

You can tell that I don't agree with all of the simple sentiments expressed in this book, but then who says I have to. I enjoyed reading it, even if I did occasionally have to cope with embarrassed looks as I started to talk out loud, voicing my urgent objections. But never mind - I enjoyed reading this book and if you are at the right stage of C++ programming so will you. It isn't going to make your C++ particularly pretty, let alone beautiful, but at least you'll be heading in the right direction.

• For more recommendations of C++ books see Top Choice C and C++ Books in our Programmer's Bookshelf section. 

To keep up with our coverage of books for programmers, follow @bookwatchiprog on Twitter or subscribe to I Programmer's Books RSS feed for each day's new addition to Book Watch and for new reviews.