https://www.modernescpp.com/index.php/60-terrible-tips-for-a-c-developer/ MC++ BLOG * TOUR + Introduction + My Blog + Current Topics + My Portfolio * Table of Content * Blog * Portfolio + My Books + My Courses + My Mentoring * Contact Me * RSS Feed * Search * Menu Menu Blog - Latest News You are here: Home1 / Blog2 / News3 / 60 terrible tips for a C++ developer [pvs-780x321] 60 terrible tips for a C++ developer August 15, 2023/in News/by Rainer Grimm 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. [pvs] 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. Rainer D 6 P2 500x500Modernes C++ Mentoring Be part of my mentoring programs: "Fundamentals for C++ Professionals" (open) "Design Patterns and Architectural Patterns with C++" (open) "C++20: Get the Details" (reopens December 2023) Do you want to stay informed about my mentoring programs: Subscribe via E-Mail. 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, [RainerGrimmDunkelBlauSmall] Post Views: 7,649 Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Droge, Abernitzke, Frank Grimm, Sakib, Broeserl, Antonio Pina, Sergey Agafyin, Andrei Burmistrov, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschlager, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Muhlhaus, Matthieu Bolt, Stephen Kelley, Kyle Dean, Tusar Palauri, Dmitry Farberov, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Futterer, Matthias Grun, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, Bhavith C Achar, and Marco Parri Empoli. Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole. My special thanks to Embarcadero [special-th] My special thanks to PVS-Studio [special-th] My special thanks to Tipi.build [special-th] My special thanks to Take Up Code [special-th] Seminars I'm happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions. Bookable German * Embedded Programmierung mit modernem C++ 12.12.2023 - 14.12.2023 (Prasenzschulung, Termingarantie) Standard Seminars (English/German) Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation. * C++ - The Core Language * C++ - The Standard Library * C++ - Compact * C++11 and C++14 * Concurrency with Modern C++ * Design Pattern and Architectural Pattern with C++ * Embedded Programming with Modern C++ * Generic Programming (Templates) with C++ New * Clean Code with Modern C++ * C++20 Contact Me * Phone: +49 7472 917441 * Mobil:: +49 176 5506 5086 * Mail: schulung@ModernesCpp.de * German Seminar Page: www.ModernesCpp.de * Mentoring Page: www.ModernesCpp.org Modernes C++ Mentoring, [RainerGrim] Share this entry * Share on Facebook * Share on Twitter * Share on Pinterest * Share on LinkedIn * Share on Tumblr * Share on Vk * Share on Reddit * Share by Mail https://www.modernescpp.com/wp-content/uploads/2023/08/pvs.png 440 780 Rainer Grimm https://www.modernescpp.com/wp-content/uploads/2023/ 02/logo_mcpp-blog-news2_287x52.png Rainer Grimm2023-08-15 13:04:26 2023-08-15 13:04:2660 terrible tips for a C++ developer Start Here [MCPP_Button_left_TOC1-5_500x120-300x72] Tag Cloud acquire-release semantic (10) ADL (1) Allocator (3) Anti-Patterns (1) Arithmetic (1) Associative Containers (10) async (2) Atomics (29) atomic_thread_fence (2) auto (6) barriers (2) Bit Manipulation (1) C (1) Classes (14) Class Hierarchies (4) Concepts (28) condition variables (6) consteval (2) constexpr (12) constexpr if (2) constinit (2) Contracts (1) Control Structures (2) Conversions (2) Coroutines (16) CppMem (9) CRTP (3) Data Races (1) Declarations (3) decltype (2) Dependency Injection (1) Dependent Names (1) Dining Philosophers (2) enum (3) Error Handling (6) Exceptions (3) Executors (2) Expressions (2) Expression Templates (2) final (1) finally (1) Fold Expressions (3) format (2) friend (1) Functions (3) GSL (3) Haskell (9) History (1) if (1) In/Output (4) Initialization (5) inline (1) Interfaces (3) iterator (2) jthread (2) Lambdas (9) latches (2) lock (11) lock-free (3) Memory (24) memory_order_consume (2) Mixins (1) Modules (10) Monads (1) Monostate (1) move (6) Multiple Inheritance (1) mutex (7) Myths (3) Naming (1) new/delete (8) nullptr (1) Ongoing Optimization (7) Outdated (11) Overloading (2) override (1) Ownership (1) Parallel STL (2) Performance (13) Pimpl (1) POD (1) Pointers (2) Policy (5) Polymorphism (2) Python (6) Race Conditions (2) RAII (1) Ranges (14) Regular (2) Regular Expressions (3) Relaxed Semantics (7) Requires Expressions (1) Rule of Zero/Six (3) Safety (5) semaphores (3) Sequential Consistency (12) shared_ptr (7) Singleton (5) Slicing (1) Smart Pointers (13) Source Files (2) Spaceship (3) span (1) Statements (1) static (2) static_assert (2) string (4) switch (2) Tag Dispatching (3) Tasks (14) Template Metaprogramming (6) ThreadSanitizer (1) thread_local (3) Time (11) Traits (1) Transactional Memory (1) type-traits (12) Type Erasure (3) union (1) unique_ptr (5) User-Defined Literals (2) Variadic Templates (5) variant (1) vector (1) Virtual Constructor (1) volatile (3) weak_ptr (1) Source Code [MCPP_Button_left_GitHub1-1_500x120-300x72] Subscribe to the Newsletter [ ] [ ] Please enable the javascript to submit this form [Subscribe] Latest news * [ram-] Polymorphic Allocators in C++17September 25, 2023 - 7:43 am This post starts a miniseries about an almost unknown feature in C++17: polymorphic allocators. I often promised that I would write about polymorphic allocators. Today, I fulfill my promise. Since C++98, you can fine-tune memory allocation in general but also for user-defined types or containers of the standard library. For example, the containers of the [...] * [Cpp2] C++23: Ranges Improvements and std::generatorSeptember 18, 2023 - 9:28 am C++20 does not provide concrete coroutines, but C++20 provides a framework for implementing coroutines. This changes with C++23. std::generator is the first concrete coroutine. std::generator is part of the extension of the ranges library in C++23. So, let me start this post with the ranges library in C++20 and its extension in C++23. I will [...] * [cove] The Final Version of my C++20 BookSeptember 13, 2023 - 7:10 pm I have given many C++20 classes in the last two years and improved my C++20 knowledge. Consequentially, I updated my C++20 book. This update includes restructured chapters, more detailed information, and additional examples. The book now has almost 700 pages and more than 200 examples. This issue is the final one. I'm done and will [...] * [Cpp2] C++23: A Multidimensional ViewSeptember 11, 2023 - 6:26 pm A std::mdspan is a non-owning multidimensional view of a contiguous sequence of objects. The contiguous sequence of objects can be a plain C-array, a pointer with a size, a std::array, a std::vector, or a std::string. Often, this multidimensional view is called a multidimensional array. The number of dimensions and the size of each dimension determine [...] * [Cpp2] C++23: Four new Associative ContainersSeptember 4, 2023 - 6:51 am The four associative containers std::flat_map, std::flat_multimap, std::flat_set, and std::flat_multiset in C++23 are a drop-in replacement for the ordered associative containers std::map, std::multimap, std::set, and std::multiset. We have them for two reasons in C++23: memory consumption and performance. With C++23, we have 12 associative Containers. Twelve? Right! Now, I need a systematic and start with the [...] * [Cpp2] C++23: A New Way of Error Handling with std::expectedAugust 28, 2023 - 6:49 am C++23 extends the interface of std::optional and gets the new data type std::expected for error handling. Before I dive into the extended monadic interface of std::optional in C++23, I want to introduce this C++17 type. std::optional std::optional is quite comfortable for calculations such as database queries that may have a result. This vocabulary type requires [...] Become a Patreon [MCPP_Button_left_Patreon1-1_500x120-300x7] Privacy Statement Imprint Disclaimer Contact Me (c) Copyright 2023 - Modernes C++ GmbH * Facebook * Twitter * LinkedIn C++ Parallel STL Benchmark[BookCover-][Cpp23-80x8]C++23: A Modularized Standard Library, std::print and std::println Scroll to top Manage Cookie Consent To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions. Functional [ ] Functional Always active The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network. Preferences [ ] Preferences The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user. Statistics [ ] Statistics The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you. Marketing [ ] Marketing The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes. Manage options Manage services Manage vendors Read more about these purposes Accept Deny View preferences Save preferences View preferences {title} {title} {title} Manage consent