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:

• Terrible tip N1. Only C++
• Terrible tip N2. Tab character in string literals
• Terrible tip N3. Nested macros
• Terrible tip N4. Disable warnings
• Terrible tip N5. The shorter the variable name is, the better
• Terrible tip N6. Invisible characters
• Terrible tip N7. Magic numbers
• Terrible tip N8. int, int everywhere
• Terrible tip N9. Global variables
• Terrible tip N10. The abort function in libraries
• Terrible tip N11. The compiler is to blame for everything
• Terrible tip N12. Feel free to use argv
• Terrible tip N13. Undefined behavior is just a scary story
• Terrible tip N14. double == double
• Terrible tip N15. memmove is a superfluous function
• Terrible tip N16. sizeof(int) == sizeof(void *)
• Terrible tip N17. Don’t check what the malloc function returned
• Terrible tip N18. Extend the std namespace
• Terrible tip N19. Old school
• Terrible tip N20. Compact code
• Terrible tip N21. Professionals do not make mistakes
• Terrible tip N22. Only students need analyzers
• Terrible tip N23. Slap stuff together and deploy!
• Terrible tip N24. When you ask for help on a forum, make sure people need to drag the information out of you. It will make things more interesting for everyone
• Terrible tip N25. Diamond inheritance
  • Initialization of virtual base classes
  • Virtual base classes and type conversion
  • Should we abandon virtual inheritance?
  • Pros of multiple inheritance
• Terrible tip N26. I’ll do it myself
• Terrible tip N27. Delete stdafx.h
  • Why do we need precompiled headers
  • How precompiled headers work
  • How to use precompiled headers
  • Life hack!
  • What to include in stdafx.h
  • Multiple precompiled headers
  • Typical errors with precompiled headers
• Terrible tip N28. An array on the stack is the best thing ever
• Terrible tip N29. Nothing extra
• Terrible tip N30. Unusual constructions
• Terrible tip N31. Use more code in header files
• Terrible tip N32. The Goto statement
• Terrible tip N33. You don’t need enums
• Terrible tip N34. Need to add a constant instance of the class everywhere? It’s more convenient to declare it in the header file
• Terrible tip N35. Declaring variables at the beginning of a function
• Terrible tip N36. Add everything, it might come in handy
• Terrible tip N37. Create your own h-quest
• Terrible tip N38. C-style cast
• Terrible tip N39. Versatility is cool
• Terrible tip N40. You are the lord of pointers — do what you want
• Terrible tip N41. const is a redundant entity
• Terrible tip N42. Vintage is cool
• Terrible tip N43. Don’t initialize
• Terrible tip N44. Trust everyone
• Terrible tip N45. Don’t worry about naming variables
• Terrible tip N46. Write your code as if you are training for the IOCCC
• Terrible tip N47. Have fun when writing code
• Terrible tip N48. Everyone has their own style
• Terrible tip N49. Overload everything
• Terrible tip N50. Don’t believe in the efficiency of std::string
• Terrible tip N51. For as long as possible, resist using the new C++ standard
• Terrible tip N52. Variables Reuse
• Terrible tip N53. Answer the question “what?” in code comments
• Terrible tip N54. More multithreading
• Terrible tip N55. The fewer .cpp files, the better
• Terrible tip N56. More classes!
• Terrible tip N57. Reading books is no longer relevant
• Terrible tip N58. printf(str);
• Terrible tip N59. Virtual functions in constructors and destructors
• Terrible tip N60. No time to think, copy the code!
• Terrible tip N61. You can look beyond the array
• The end

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.

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,