A must read for every C++ programmer is without doubt this book. I just bought it for myself today but I have read it back to back some years ago while I still worked at Larian.
I am myself very interested in programming languages in general and I feel that this book has given me a good understanding of the C++ language. Since I read the book I think more ahead about a class and its functions before I start to write the code. I feel I also write less bugs and far more structured code, I even find bugs faster! If only such a book existed for C# and Java.
So I started re-reading some of the chapters. I'm currently more often working in C# and Java and I noticed that quite a few of the guidelines/best practices presented in the book also apply evenly well on those two languages, especially the first chapter. For example the first 'rule': 'Don't sweat the small stuff.', summarized as 'Don't enforce personal tastes or obsolete practices.' With the team at Newfort we started creating some sort of C# coding agreement to use in our code and I must say that we violated this rule a few times. This rule for example implies that you do not specify where your braces should be for your if construct; every programmer should be capable of reading and writing it. The rule only mentions that you should be consistent on file level.
The odd thing is though, that several C# standards (including the one we knocked up ourselves) specifically mention how to brace your loops and if-then-else code.In hindsight, I must say that I agree with my mates Sutter and Alexandrescu. Why on earth would we bother with the placing of braces or specific line length or indent length, etc as long as it's structured, readable and consistent.
The next three rules also apply on C# and Java and other programming languages, but that's for a later post, bedtime now for me :) Kiddies tend to make you tired.
Read the book!
1 comment:
I'm sure the c# compiler doesn't care where the braces are, which makes bracing choice a matter of taste. So one tends to make a choice, find an environment that adapts accordingly, and stick with it as well as one can.
The C++ language is full of weird inconsistencies, making it next to impossible to make 'the perfect choice'. Google's very own Coding Guidelines, in my opinion, are the best up-to-date resources I've ever come across, detailing all the reasons why they make those choices. This makes it possible to re-evaluate in the long-run wether those choices were right or wrong, which is something software companies seldomly do right.
Can't wait to read your next post :)
Post a Comment