35 Books Like Effective Modern C++

Every "computer person" should read GEB at least once. Preferably in high school, when you still have the free time to dive deep into all the recreational math exercises. If you're already working 40-hour weeks and wonder who has time for Hofstadter's 750-page "metaphorical fugue on minds and machines," all I can say is: Better late than never!

This book greatly influenced my philosophy around style. Norman's ostensible subject is the design of physical objects, like emergency exits, shower faucets, and refrigerators, but most of what he says is directly applicable to software design and API design, too.

For example: Whatever you expose or document about your interface, the user will take that and form a mental model of the implementation—and he'll program against that mental model, not against your documentation. So you'd better make sure that your interface—by exposing certain details and deemphasizing others, appropriate naming, and so on—suggests a mental model that will be useful to the user (even if it is not correct in every particular).

For example, a horizontal rod mounted on a door affords pushing (a bit of jargon that's entered my technical vocabulary), while a vertical rod affords pulling. If you use the design language of a horizontal rod, people will… show more.

This tour de force probably couldn't get written today. Kernighan and Plauger take snippets of Fortran and PL/I code from real, published textbooks and find things to fix about them. Now, many of their specific concerns are relics of the "structured programming" wars of the 1960s (overuse of arithmetic IF and GOTO) or quirks of the programming languages in question (undeclared variables silently getting the wrong type); but this is educational in itself. If you wonder what's so bad about GOTO, or why we need to declare functions and variables before use, this book may enlighten you. And despite its age, almost every example finds some present-day analog. For example, Kernighan and Plauger's advice to avoid manually counted Hollerith strings in Fortran applies equally to manually counted array bounds in C++: don't write "int a[5]" when you can write "int a[]". The authors boil every couple of pages down to… show more.

Next to Fred Brooks' The Mythical Man-Month, this is perhaps the most classic of all classic programming books.

The authors write: "Besides showing how to make effective use of the language, we have also tried where possible to illustrate useful algorithms and principles of good style and sound design."

The book is astoundingly practical as a tutorial, which is itself a testament to the Unix "pipe" model of programming: By page 13, they've introduced getchar and putchar, and by the end of Chapter 1, twenty pages later, you've implemented a host of useful utilities including cat, wc, and detab. In Chapter 5 you implement a function recognizable as the now-standard qsort; in Chapter 8 you implement malloc itself.

Now, I recommend "K&R1," not the more popular "K&R2." The first edition was issued in 1978 at a slim 225 pages; the second edition, a decade later, added conformance with ANSI… show more.

This is one of the best books I’ve read on how to write better code and build more maintainable software in Python. It is well-written, concise, and to the point.

Brett’s book is a perfect companion to the other books on this list, which are more focused on data analysis and using specific libraries to build data systems.

I'm a devoted advocate of functional programming and a passionate Haskell enthusiast.

Ironically, there was a time in my life when I was a student and held the belief that functional programming was merely an impractical academic pursuit.

However, I soon had a revelation that the techniques I employed in C++ to mitigate the inherent unsafety of the language actually aligned with the core principles of functional programming: immutability, purity, and composability.

This realization left a profound impression on me, prompting me to delve into learning Haskell. It proved to be a pivotal moment that significantly shaped my entire career trajectory.

As I delved deeper into functional programming, I discovered a significant void in terms of software engineering practices that were prevalent in the realm of object-oriented programming.

Drawing from my experiences in C++ and C#, I noticed numerous gaps in our understanding of how to build robust applications using… show more.

C++ is a tricky, beastly language, and there are no end of ways to program either incorrectly or inefficiently with it. Meyer's 1991 book set the bar high for similar books to come, providing great, detailed explanations about the language's pitfalls and how to avoid them. After reading Effective C++, though, you might find yourself wondering why you are coding in C++: The tips reveal so many insidious ways to shoot yourself in the foot, and worse, sometimes in a way that you won't even notice that your little toe is missing.

Effective C++ and the two follow-ons are essential reading for anyone working in C++. Nowadays you can purchase a digital edition that provides 140 total ways—adding in 50 additional tips from More Effective C++ and 40 from Effective STL.

Unless you are writing a greenfield app, you have legacy code around. And even if you are on a greenfield app, you are writing legacy code right now.

This book gives you techniques for working on such a codebase. It is a really good read for learning how to refactor safely so you can work with what you are inheriting. You might notice this book is 20 years old. It’s just as relevant today as when I first read it in 2004. The concepts don’t depend on the exact language syntax.

In fact, some of the examples are in a mix of Java, C#, and C++. I really appreciate the perspective on testing that I got by reading this book.

Not only does this book provide insight into the planning and development of one of the first visual IDEs, it’s overflowing with hilarious, profound, and pragmatic real-life lessons for how to manage a software team and deliver a complex project.

As a product of its time, the writing isn’t always politically correct. However, many of the lessons and memes are still part of our vernacular today: Don’t flip the bozo bit; If you build it, it will ship; and [Love] the customer.

Some of its lessons should be memes: Beware of [an engineer] in a room, Be an authority, not an authority figure, and Don’t trade a bad date for an equally bad date.

Some sections show their age in our current world of continuous delivery, but few current books have the humor and concise insight of this remarkable work.

This weighty tome delves deep into the low-level working of computer programs.

This book is a great resource for professional programmers who work close to the machine in such fields as embedded software, cybersecurity, and device drivers. Assuming a basic knowledge of the C language, Bryant and O’Hallaron, two CMU professors, teach how to read and understand compiled code, how to optimize it for better performance, and how to avoid common pitfalls.

This is a hard-core technical book, written by engineers for engineers, in a dense style that is nonetheless accessible and practical. I like the numerous applied problems, each accompanied by a worked-out solution.