Source control anyone?

In the same book I mentioned in the previous post, the writers state in their preface that one of the goals of the rules in the book is: 'Each item must need saying'. As an example they give 'Use an editor', and indeed that rule goes without saying.

I thought the same thing about source control, everyone uses source control for a project large enough, obviously. So why put it as a rule in the book?

But then I experienced myself that this rule indeed 'needs saying'. Recently I came in contact with a company -no need to mention names- that does software development in mainly C++, on Linux and Windows, also in assembly... without source control. Without it.

I still can't really believe it and I don't want to know how they have to manage, but lesson learned: the item clearly needs saying.

As I will be moving to another company in May, I already wonder what source control system they use. I silently hope they use Perforce (as does Larian and as does Newfort since I introduced it there). I know it's not free, it's even quite expensive if you ask me, but their P4V tool, together with plugins for 3rd party software is unmatched, at least imho.
I like the idea of git and mercurial, and I've been working with git lately. I think it's a very good system, I only want a client tool that's as good as P4V for it. Mmm, challenge. Nah, don't have the time for it.

Well, off to work then :)

Coding standards

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!