The main issue of programming, refactoring and all that

I wrote a small e-book in which I consider how to make the code better. The book is focused on C / C ++ programmers, but it will be interesting for developers using other languages. The format of the book is not suitable for my beloved Habr, but I am interested to get feedback and discuss the thoughts presented in the article. Therefore, I decided to post here only the announcement, and the article itself can be found here . And I invite in the comments for discussion.

I hope you enjoyed this collection of tips. Of course, it is impossible to warn about all the ways to write a program, and there is no point in this. My goal was to warn the programmer and develop a sense of danger in him. Perhaps when the programmer once again encounters something incomprehensible, he will remember my instructions and will not hurry. Sometimes a few minutes of studying the documentation or writing a simpler / clearer code will allow you to avoid introducing a hidden error that would then poison the lives of users and colleagues for several years.

Here are 42 topics that I cover:

1. Do not take over the work of the compiler
2. Greater than 0, this is not 1
3. Copy once, check several times
4. Fear operator?: And enclose it in parentheses
5. Use available code checking tools.
6. Check all places where the pointer is explicitly cast to integral types.
7. Do not call the alloca () function inside loops.
8. Remember that an exception in a destructor is dangerous.
9. Use a literal '\ 0' to denote a terminal zero.
10. Try not to shrink when using #ifdef
11. Do not be greedy on lines of code
12. When focusing on Copy-Paste, focus on the end of work.
13. Align uniform code with a “table”
14. Remember: not always enough compiler and good coding style
15. If possible, start using the enum class.
16. “See how I can” - unacceptable in programming
17. Use specialized functions to wipe private data in memory.
18. Knowledge gained from working with one language is not always applicable to another language.
19. How to call one constructor from another
20. End of File (EOF) checks may not be enough
21. Check the sign of reaching the end of the file (EOF) correctly
22. Do not use #pragma warning (default: X)
23. Calculate the length of a string literal automatically.
24. The override and final identifiers should be your new friends.
25. No more comparing 'this' with nullptr
26. VARIANT_BOOL
27. Insidious bstr strings
28. Do not make macros where you can make an ordinary function.
29. Use prefix increment operator (++ i) instead of postfix (i ++) for iterators
30. Visual C ++ and the wprintf () function
31. In C and C ++, arrays are not passed by value.
32. Fear printf
33. Never dereference null pointers
34. Undefined behavior is closer than you think.
35. Adding a new constant to enum, do not forget to fix the switch statements
36. If magic events occur on your computer, check the memory
37. Be careful of the continue statement inside do {...} while (...)
38. From today, use nullptr instead of NULL.
39. Why incorrect code sometimes works
40. Implement static code analysis
41. Resist adding new libraries to your project.
42. Do not give functions the name "empty"

So, the link to the article: http://www.viva64.com/ru/b/0391/

In English: http://www.viva64.com/en/b/0391/
')
I foresee that the Habroeffekt may inadvertently happen, so I want to make sure in advance. Therefore, I post on Yandex Disk in PDF format:

Russian: https://yadi.sk/i/LKkWupFjr5WzR

English: https://yadi.sk/i/pBZqebxsr5Wyg

PS I do not specifically place the text of the book on other sites. Quite a lot of people report shortcomings in the text, and if the text is published in several places, I’m tortured to make corrections. When the text is stabilized, I will place it somewhere else in different formats. In the meantime, please treat with understanding. And another request. I’m writing about emails (karpov [@] viva64.com), and not in the comments.