Chapter 25 // Exercise 16 - Principles & Practice Using C++

In this exercise I am using Visual Studio 2019 and a modified version of the std_lib_facilities header found here.

Chapter 25 // Exercise 16

Formulate 20 coding style rules (don't just copy those in section 25.6). Apply them to a program of more than 300 lines that you recently wrote. Write a short (a page or two) comment on the experience of applying those rules. Did you find errors in the code? Did the code get clearer? Did some code get less clear? Now modify the set of rules based on this experience.

Github: https://github.com/l-paz91/

This was a really interesting exercise for me as my coding style has changed so much over the past 7 years. I could probably make a video talking about this. It's even changed a lot over the past 3 years I've been putting my code on github.

Currently my 20 rules would be:

1. Dashed lines between functions (I picked this up from work and now I will put bugs on code reviews if people have forgotten dashed lines)
2. UpperCamelCase to be used for object creation, enums to use capital snake case and everything else should use lowerCamelCase (this is in direct violation of Bjarne's R302 but he can suck it, camelCaseForever. I also use Hungarian Notation for vectors sometimes because why be completely consistent?)
3. All member variables should be prefixed with m
4. All global variables should be prefixed with g
5. Function argument parameters should be prefixed with p
6. Enums should be prefixed with e and be all uppercase afterwards. Example; ePURPLE_CRAYON
7. Where a function argument parameter is not modified in the function, it should always be passed by const reference (unless it's cheaper to just pass by const value)
8. References should be used over pointers where possible
9. Prefer std::vector over raw arrays
10. const_cast should not be used
11. Prefer ifndef/define over pragma once
12. All local variables should be declared as const/constexpr unless they need to be modified
13. Commonly used (non-changing) local variables should be declared in a private namespace in the cpp of the file they are used in
14. Avoid mixing static member variables with non-static. Either create a namespace or singleton with all static functions/members
15. Try to order member variables in descending size order
16. Braces {} should always be on their own line. The only exception is 1 line functions in header files (or empty constructors/destructors)
17. Avoid post-fix increment/decrement unless the functionality of post-fix is specifically needed. Always prefer pre-fix increment/decrement
18. Includes should be in grouped order of local (""), then global (<>). Each group should be in alphabetical order
19. Include what you use. Prefer including in the cpp with forward declares in the header. Only include in the header if you must
20. Avoid lambda's. Only use them if you must

When I first started programming back in January 2016, I had no one to talk to about C++ and used this book or stackoverflow to try and complete exercises. When I started my degree that September, I started picking up habits from my tutors code and youtube videos. For those first 3 years my code style heavily resembled what you see in the book. Then I started working at Rare and at first I fought against the strict coding style/rules. I used them because I had to but over the past 3 and half years I've grown to love some of those rules, and the ones I don't like don't bother me anymore. I'd say my current style is the one I'll probably stick to now as I find it clear, concise and maintainable. 

I would say rules 1-6 are just me being picky and pedantic however the rest are extremely useful in production code and can even help you avoid bugs and provide a better debugging environment.