Preface

Every programmer inherently learns and practices a custom programming style. The reason for this is no doubt rooted in how programmers learn to program: a snippet from this book, a line from that, an algorithm from this magazine, an array class from that. Every programmer is essentially a melting pot for the many different styles that exist. It is left to the statistically inclined reader to determine just how many combinations are possible and at which frequency. Having a custom style is generally suitable as long as the programmer abstains from interacting with other programmers and decides to be a prisoner to that particular style. Aside from the usual social discontinuities, problems surface when programmers begin to mingle. A random sample of C++ source code from the Internet will yield a variety of C++ dialects. Either you will learn some new things or your eyes will tire from poorly written code. The one constant is that you will never find two programmers that do things exactly the same way. Even more problems occur when teams of programmers must work together. In this environment source code can make round trips through programmers, changing ever so slightly in each iteration. Small scale battles can occur in these code bytes in the form of moving curly braces and parenthesis around, adding or removing spaces, tabbing this, carriage-returning that, commenting this, not commenting at all, renaming variables, or using for loops instead of while loops. We end up fighting essentially irrelevant battles and wasting time.

If everybody wrote code in the exact same way, then everything would be fine. This is obviously not the case and it is not the intention of this document to force you into writing code the way we write code. The purpose of this document is to address common problems and to provide solutions in a well-defined manner.