Terrible tips for a C++ programmer. Part 2

Hi, I am Andrey Karpov and today I am posting a few more terrible tips for C++ developers. They may seem funny, but I have seen all of them in real-life applications.
These tips are meant to be educational - but make sure to use common sense when you follow (or don't follow) them. Real-life cases are very diverse and may require different approaches.
Want to see more tips? Take a look at 60 terrible tips described in my online book: https://pvs-studio.com/en/blog/posts/cpp/1053/

Transcript

1. 60 terrible tips for a C++ programmer Part 2 Tips 6 - 10 Andrey Karpov Co-owner and CMO pvs-studio.com
2. Introduction I am excited to invite you to read terrible tips 6 – 10 for a C++ developer. Following them may have an adverse effect on your code – I have seen that in real-life applications. Although I’ve intended these tips to be educational, I’ve also made them entertaining. So make sure to use common sense when you follow (or don’t follow) these tips. This presentation contains just 5 tips – so that you don’t get tired. Want to see them all? See my online book, “60 terrible tips for a C++ programmer”.
3. Contents: tips 6-10 • 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
4. Terrible tip N6. Invisible characters
5. Use invisible characters in your code. Let your code work like magic. That's cool. Terrible tip N6. Invisible characters
6. Some Unicode characters are invisible or can change what code looks like in an IDE. Consequently, the developer and the IDE would interpret such code differently. Such error may be an accident. This can also be done on purpose – in this case it is called a Trojan Source attack. Terrible tip N6. Invisible characters
7. This tip may come in handy on April Fool's day. When your teammate turns away, change any semicolon in their code to the Greek question mark – U+037E that looks like a semicolon (;). Sit back and enjoy their reaction :) Everything will seem fine, but the code will not compile. Terrible tip N6. Invisible characters
8. Terrible tip N7. Magic numbers
9. 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; Terrible tip N7. Magic numbers
10. When the code contains numbers whose purpose is unknown, these numbers are called magic numbers. Magic numbers are a code smell. Over time, such code becomes hard to read for anyone: authors and other developers alike. To improve such code, replace magic numbers with named constants and enumerations. Terrible tip N7. Magic numbers
11. As with any tips and rules, moderation is key – so not every constant must be named: • there are 0 or 1 constants whose use cases are obvious; • mathematical calculations may suffer from naming each numerical constant. Terrible tip N7. Magic numbers
12. Terrible tip N8. int, int everywhere
13. 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. Terrible tip N8. int, int everywhere
14. For a long time, on many common platforms where the C++ language was used, an array could not contain more than INT_MAX elements. In fact, the size of such types as int, unsigned, and even long may be not enough. Here’s an example: in order to build an app for the Windows x64 platform, MSVC compiler uses the LLP64 data model. In this model, the long type remains 32-bit. Terrible tip N8. int, int everywhere
15. What if you don’t use large arrays in your code? • If the program doesn't use large arrays now, that does not mean it'll always be so. • The code can be reused in another application, where the processing of large arrays is routine. • The use of mixed arithmetic may cause problems even if you work with small arrays. What types should you use? Memsize-types such as ptrdiff_t, size_t, intptr_t, uintptr_t are safe to store indexes or array sizes. Terrible tip N8. int, int everywhere
16. 1. A 32-bit counter is used to process a large array in a 64-bit app. The signed int variable may overflow and cause undefined behavior. 2. Here’s one example of correct code. 3. This code is even better – although lengthy. std::vector<char> &bigArray = get(); size_t n = bigArray.size(); for (int i = 0; i < n; i++) bigArray[i] = 0; size_t n = bigArray.size(); for (size_t i = 0; i < n; i++) bigArray[i] = 0; std::vector<char>::size_type n = bigArray.size(); for (std::vector<char>::size_type i = 0; i < n; i++) bigArray[i] = 0;
17. 4. To keep the code short and iterate through elements correctly, you can use iterators. 5. Alternatively, you can use a range-based for loop. for (auto it = bigArray.begin(); it != bigArray.end(); ++it) *it = 0; for (auto &a : bigArray) a = 0;
18. Terrible tip N9. Global variables
19. Global variables are exceptionally convenient because you can access them from anywhere. Terrible tip N9. Global variables
20. Unfortunately, when variables can be accessed from anywhere, this also means it is unclear where and when exactly they are accessed. This causes a number of problems: • program logic is confusing, • errors are difficult to find through debugging, • functions are difficult to check with unit tests. So, to prove all that is serious, I suggest you read the article "Toyota: 81 514 issues in the code". One of the reasons why the code is so messy and buggy is the use of 9,000 global variables. Terrible tip N9. Global variables
21. Terrible tip N10. The abort function in libraries
22. A tip for those who develop libraries: when in doubt, immediately terminate the program with the abort or terminate function. Terrible tip N10. The abort function in libraries
23. Sometimes a simple app or utility shuts down after an error. In such scenarios, it is acceptable for a developer to handle errors by calling the abort, exit or terminate function. However, this approach is unacceptable for library code. Here’s why: • the library author cannot predict all scenarios for the library’s use; • somebody’s app that uses the library could shut down with work unsaved; • MISRA and AUTOSAR prohibit abort and exit functions. Library code should return an error status or throw an exception. And it is up to the user to decide how to handle the error. Terrible tip N10. The abort function in libraries
24. Conclusion
25. I hope you enjoyed reading the terrible tips! You can find a complete list of 60 terrible tips here. Please do let us know what you think in the comments. Conclusion