Review of mini-book «60 terrible tips for a C++ developer»

I wrote a small e-book about terrible tips for C++ developers. Actually, it describes bad programming practices and explains why it's better to avoid them. However, every chapter of this mini-book starts with a terrible tip — just for fun.

By the way, these tips may seem artificial but believe me, they are based on the real experience. In other words, the described terrible tips occur in developers' lives — that's why it's worth discussing them. First of all, this book will be useful for junior developers. But more skilled C++ developers can also find interesting and useful tips.

Even though it's a mini-book, it clearly does not fit into the Habr format. Too many words. So, I decided to write here the review. Here is the link to find the full version of the mini-book: 60 terrible tips for a C++ developer.

If you still hesitate whether to read it or not, below you will find a list of terrible tips that will be discussed in the mini-book.

View the terrible tips:

1. Real developers code only in C++!
2. If you need a tab character in a string literal, feel free to press the tab key. Save \t… for somebody else. No worries.
3. 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.
4. Disable compiler warnings. They distract from work and prevent you from writing compact code.
5. Use one or two letters to name variables. This way you'll fit a more complex expression on one line on the screen.
6. Use invisible characters in your code. Let your code work like magic. That's cool.
7. Use strange numbers. This way, the code of your program will look smarter and more impressive. Doesn't this code line look hardcore: qw = ty / 65 — 29 * s;?
8. 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.
9. Global variables are exceptionally convenient because you can access them from anywhere.
10. A tip for those who develop libraries: when in doubt, immediately terminate the program with the abort or terminate function.
11. If something doesn't work, most likely the compiler is acting up. Try swapping some variables and code lines.
12. There's no time to explain — immediately use the command line arguments. Like that, for example: char buf[100]; strcpy(buf, argv[1]);. Checks are only for those who don't feel too confident about their own or their teammates' coding skills.
13. Undefined behavior is just a scary bedtime story for children. 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. Everything is fine.
14. Feel free to use the operator == to compare floating-point numbers. If there is such an operator, you need to use it.
15. memmove is a redundant function. Use memcpy always and everywhere.
16. 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.
17. 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.
18. Extend the std namespace with various additional functions and classes. After all, for you, these functions and classes are standard and basic.
19. 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.
20. 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.
21. 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.
22. Don't use static analyzers. These are tools for students and losers.
23. Always and everywhere deploy any changes immediately to production. Test servers are a waste of money.
24. Everyone is just dreaming of helping you. So, it's worth asking on Stack Overflow/Reddit "why isn't my code working?", and everyone is ready to overcome any barriers to answer your question.
25. The C++ language allows to perform virtual inheritance and implement diamond inheritance with it. So why not to use such a cool thing!
26. Do not use the language's standard library. What could be more interesting than writing your own strings and lists with unique syntax and semantics?
27. Get rid of that stupid stdafx.h. It's always causing those weird compilation errors.
28. Besides, 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.
29. Do not use a version control system. Store the sources directly on the virtual machine server.
30. Everybody knows that index-to-pointer accesses are commutative. Don't be like everybody else. Make your code unique — use constructions 1[array] = 0.
31. It's much more convenient to use more code in header files. Moreover, the compilation time increases only slightly.
32. Rumors say that goto is considered a terrible statement, but this is nonsense! This statement is very powerful and even allows you to stop using for, while, do. Long live goto and asceticism!
33. Never use enums, they implicitly change to int anyway. Use int directly!
34. Sometimes it happens that some kind of global constant object is needed everywhere. For example, an instance of an empty string. It's more convenient to place it in the header file where your string class is declared.
35. Show a little respect for programmers of the past — declare all variables at the beginning of functions. It's a tradition!
36. 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!
37. 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!
38. Why do we need all these *_casts if there is a reinterpret_cast? And the good old C-style cast — (Type)(expr) — is even better and shorter.
39. 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.
40. What could be wrong with looking at a neighboring variable via a pointer to a variable? I mean, we are within the limits of our memory.
41. 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.
42. 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.
43. Why initialize variables if they are already zeroed? I mean, just the other day, I didn't initialized variables and there was zero. Everything worked.
44. Private and protected access modifiers are for those who don't feel confident. These class fields — who needs them anyway?
45. Create variables that will differ in names only by numbers: index1, index2.
46. 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).
47. If line breaks and indents are insignificant in C++, why not write code in the form of a bunny or a squirrel?
48. Alignment and code style do not allow to express your individuality and creativity. This is a violation of individual freedoms and self-expression. Everyone should write code the way they like.
49. 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...
50. A universal std::string is inefficient. realloc, strlen, strncat work more quickly and effectively.
51. Make sure your code supports the outdated C++ standard for compatibility purposes.
52. Reuse variables as much as possible. Allocate memory once and then reuse it. For example, if we need three integers in a function, create one, call it something generic, like x, and then use that x name for all three integers.
53. Write comments to explain what exactly a line of code does. Yet every true coder understands why this is done.
54. Multithreading is always more efficient than single-threading.
55. There is no limit to the amount of code that may fit into a single file; in fact, this way code compiles faster.
56. Everything that can be represented by a class must be represented by it.
57. Reading fundamental books on C++ is a waste of time. Educational videos are enough, Google will help with everything else.
58. Need to print a string? What's there to think about! Just print it using printf!
59. The C++ standard clearly defines how a virtual function call works in a constructor and destructor. So, you can safely make such calls.
60. Copying code and then editing it is the fastest way to write code. Long live the copy-paste programming!

Enjoy reading!