50 terrible coding tips for a C++ developer

Whichever C++ article you read, it provides serious information, requires thoughtful reading — preferably with a cup of coffee. And what if you want to have fun? That's why I decided to write this humorous article with terrible coding tips. The main thing is not to confuse these tips with helpful ones!

I write articles about static analysis methodology and issues of creating high-quality code. But I wanted to fool around a bit. So please, welcome the article with 50 terrible coding tips. However, if you have more ideas how to create sh*tcode — share them in the comments. There's a chance that I'll post a new article and there might be 100 terrible coding tips :).

In case you don't understand why some tip is called terrible, click the {link}. If there is no link, let me know. I'll share a more detailed explanation.

• A real programmer only programs in C++! {1}
• If you need a tab character in a string literal, feel free to press the tab key. Save \t ... for somebody else. No worries.
• Use nested macros everywhere. It's a good way to shorten code. You will free up hard drive space. Your teammates will have lots of fun when debugging. {3}
• Disable compiler warnings. They distract from work and prevent you from writing compact code.
• Use one or two letters to name variables. This way you'll fit a more complex expression on one line on the screen.
• Use numbers in programming. This way the code of your program will look smarter and more impressive. Here's code line example: qw = ty / 65 - 29 * s;. Looks hardcore, right? {6}
• Use invisible characters in your code. Let your code work like magic. How cool is that?
• All old books recommend using int type variables to store array sizes and to construct loops. Let's keep it up! No reason to break with tradition.
• Global variables are exceptionally convenient because you can access them from anywhere.
• A tip for those who develop libraries: when in doubt, immediately terminate the program with the abort or terminate function. {10}
• If something doesn't work, most likely the compiler is acting up. Try swapping some variables and code lines. {11}
• There's no time to explain — immediately use the command line arguments. For example: char buf[100]; strcpy(buf, argv[1]);. Checks are for those who don't feel too confident about their own or their teammates' coding skills. {12}
• Undefined behavior is just a scary bedtime story. Undefined behavior doesn't exist in real life. If the program works as you expected, it doesn't contain bugs. And there's nothing to discuss here, that's that. {13}
• Feel free to use the == operator to compare floating point numbers. If there is such an operator, you need to use it. {14}
• memmove is superfluous function. Always and everywhere use memcpy. {15}
• The size of the pointer and the size of int is always 4 bytes. Feel free to use this number. The number 4 looks much more elegant than an awkward expression with the sizeof operator. {16}
• It makes no sense to check if memory was allocated. Modern computers have a great amount of memory. And if there is not enough memory to complete operations, there is no need for the program to continue working. Let the program crash. There's nothing more you can do anyway. {17}
• Extend the std namespace with various additional functions and classes. After all, for you, these functions and classes are standard and basic. And if so, the std namespace is where they belong. {18}
• Your teammates should know your extensive experience with the C language. Don't hesitate to show them your strong skills in manual memory management and in the usage of longjmp.
• Use as few curly brackets and line breaks as possible. Try to write conditional constructs in one line. This will reduce the code size and make the code compile faster. {20}
• Never test anything. And don't write tests. Your code is perfect, what's there to test? It's not for nothing that you are real C++ programmers. {21}
• And don't use static analyzers. These are tools for students and losers. {22}
• Always and everywhere deploy any changes immediately to production. Test servers are a waste of money.
• Always use as many nested objects as possible. Complex code looks trustworthy!
• Never use licensed components. You can use only pirated ones. Where to find them? On suspicious websites. Why do you need to pay other programmers? Especially if they suddenly didn't use C++. Eww.
• Do not use the standard language library. What could be more interesting than writing your own strings and lists with unique syntax and semantics? {26}
• Don't use smart pointers and RAII. All resources must be managed manually, this makes the code simple and understandable.
• And in general, memory allocation is evil. char c[256] is enough for everyone, and if it's not enough, we'll change it to 512. At the very least – to 1024.
• Do not use a version control system. Store the sources directly on the virtual machine server.
• Alignment and code style do not allow to express your individuality and creativity. This is violation of personal liberty and self-expression. Everyone should write code the way they like.
• Use more code in header files. It is much more convenient, and the compilation time increases only slightly. {31}
• Rumor has it that goto is harmful. Nonsense. The goto operator is exceptionally powerful and can replace many other operators. Long live goto and asceticism!
• Never use enums, they implicitly change to int anyway. Use int directly! {33}
• Use as many different build systems and package managers as possible. Show everyone that you are aware of modern trends! Of course, the code versions in the packages for different managers should slightly differ. Otherwise, users will get bored.
• Show a little respect for programmers of the past — declare all variables at the beginning of functions. It's a tradition! {35}
• Include as many header files as possible so that each .cpp file opens in a million lines — your teammates will thank you for having more time for a smoke break during rebuild! {36}
• Write your .h-files so that they depend on other headers, and do not include them in your header file. Let the one who use include guess what header files need to be included in advance before using your file. Entertain your colleagues with quests!
• Why do we need all these *_casts if there is a reinterpret_cast that always works? And the good old C-style cast — (Type)(expr) — is even better and shorter.
• If you decide to write a function, it should be omnipotent and versatile, like a Swiss army knife. The function should take a lot of arguments. To save time, you may not enumerate the arguments, but parse them using va_arg.
• What could be wrong with looking at a neighboring variable through a pointer to a variable? I mean, we are within the limits of our memory. {40}
• The const word just takes up space in code. If you don't want to change a variable, then you just will leave it like that. {41}
• Did you know that instead of curly brackets, you can use <% and %>? Digraphs and trigraphs can make your code vintage and more unique. Your code will stand out against the code of your teammates. You are not doing anything illegal. Digraphs and trigraphs are in the standard.
• Why initialize variables if there are already nulls? I mean, just the other day, I didn't initialize variables and there was null. Everything worked.
• private is for those who don't feel confident. These class fields. Who needs them anyway?
• Create variables that will differ in names only by numbers: index1, index2. As many as possible. {45}
• Write your code as if the chairman of the IOCCC judges will read it and as if they know where you live (to come and give you the prize). {46}
• If line breaks and indents are insignificant in C++, why not write code in the form of a bunny or a squirrel?
• Everyone knows that [ ] operator is commutative. So don't be like everyone else. Give the code originality by using 1[array] = 0 constructions.
• For as many types as possible, overload as many operators as possible, including non-arithmetic ones. By giving operators a different meaning, you are getting closer to creating your own language dialect. Creating your own language is fun. And what if you also add macros...
• Universal std::string is inefficient. realloc, strlen, strncat work more quickly and effectively. {50}
• If you can refer to the next element outside the array, it means that it's possible to access this element as well. Opps, this is the 51st item on the list, and I promised 50. Sorry, but what a C++ article without an off-by-one error :). {51}

Probably these pieces of advice will remind you any of your colleagues :) Then it's time to share this article with them. Bye! See you in the debugger!