60 terrible tips for a C++ developer

Today, I want to present a mini book written Andrey Karpov from the PVS-Studio team. This book is educational and entertaining at the same time.

The mini book contains 60 terrible coding tips — and explanations of why they are terrible. It’s a lot of fun to read them. The horrible tips are not fictional but based on actual code examples.

Here are all of the rules:

What makes this mini book even more valuable is that it often refers to additional resources that let you drill deeper.

I don’t know which is my favorite, but Terrible tip N5. The shorter the variable name is, the better is among them, because the most important rule for good software is good names:

Terrible tip N5. The shorter the variable name is, the better

Use one or two letters to name variables. This way you’ll fit a more complex expression on one line on the screen.

Indeed, this way helps you write much shorter code. However, it’ll be hard to read. In fact, the absence of normal variable names makes the code write-only. You can write it and even debug it right away, while you still remember what each variable means. But you won’t understand a thing there after a while.

Another way to mess up the code is to use abbreviations instead of the normal variable names. Example: ArrayCapacity vs AC.

In the first case, it is clear that the variable means “capacity” — the size of the reserved memory in the container [1, 2]. In the second case, you’ll have to guess what AC means.

Should you always avoid short names and abbreviations? No. Be considerate. You can name counters in loops like i, j, k. This is common practice, and any developer understands code with such names.


Rainer D 6 P2 500x500Modernes C++ Mentoring

Be part of my mentoring programs:

  • "Fundamentals for C++ Professionals" (open)
  • "Design Patterns and Architectural Patterns with C++" (open)
  • "C++20: Get the Details" (open)
  • "Concurrency with Modern C++" (starts March 2024)
  • Do you want to stay informed: Subscribe.


    Sometimes abbreviations are appropriate. For example, in code implementing numerical methods, process modeling, etc. The code just does calculations using certain formulas described in the comments or documentation. If a variable in the formula is called SC0, then it is better to use this name in the code.

    For example, here is the declaration of variables in the COVID-19 CovidSim Model project (I checked it once):

    int n;             /**< number of people in cell */
    int S, L, I, R, D; /**< S, L, I, R, D are numbers of Susceptible,
                        Latently infected, Infectious,
                        Recovered and Dead people in cell */

    This is how you can name variables. The comments describe what they mean. This naming allows you to write formulas compactly:

    Cells[i].S = Cells[i].n;
    Cells[i].L = Cells[i].I = Cells[i].R = Cells[i].cumTC = Cells[i].D = 0;
    Cells[i].infected = Cells[i].latent = Cells[i].susceptible + Cells[i].S;

    I’m not saying this is a good approach and style. But sometimes it is rational to give short names to variables. However, be careful with any recommendation, rule, and methodology. You should understand when to make an exception and when not.

    Steve McConnell gives good arguments about how to name variables, classes, and functions in his book “Code Complete” (ISBN 978-0-7356-1967-8). Highly recommend to read it.

    To make the long story short: I highly recommend reading the 60 terrible tips.You will be educated and entertained at the same time,

    Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Stephen Kelley, Kyle Dean, Tusar Palauri, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, Bhavith C Achar, Marco Parri Empoli, moon, Philipp Lenk, Hobsbawm, Charles-Jianye Chen, and Keith Jeffery.

    Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.

    My special thanks to Embarcadero
    My special thanks to PVS-Studio
    My special thanks to Tipi.build 
    My special thanks to Take Up Code
    My special thanks to SHAVEDYAKS


    I’m happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.

    Standard Seminars (English/German)

    Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.

    • C++ – The Core Language
    • C++ – The Standard Library
    • C++ – Compact
    • C++11 and C++14
    • Concurrency with Modern C++
    • Design Pattern and Architectural Pattern with C++
    • Embedded Programming with Modern C++
    • Generic Programming (Templates) with C++
    • Clean Code with Modern C++
    • C++20

    Online Seminars (German)

    Contact Me

    Modernes C++ Mentoring,