Coder Corner

Most of us are manichaeist programmers: we see things in binary, either good or bad. This is the real root of all evil.

Joe loves tricky code. He enjoys assembly, over-abuses the float-as-int macro, doesn’t care at all about how “clean” or “unclean” the code is: he doesn’t even see it. He only sees the performance numbers on a benchmark. Joe thinks all compilers are evil by nature, and the last IDE he approved was Devpack 2.23.
Jack dreams in C++, loves the STL, enjoys template meta-programming, only uses Comeau compilers, and his code is already written with C++0x in mind. Compliance to the C++ standard is king, and runtime performance is a secondary concern better left to the one who knows best about this: the compiler.

Joe uses radix-sort.
Jack uses qsort.

Jack’s code crashes and exits as soon as a single texture is missing. He uses level 4 warnings-as-errors, his asserts can’t be ignored, and everything has to be perfect otherwise the game doesn’t even start. He uses exceptions and never tests pointers returned from an allocation: if it fails, an exception is thrown and the code handles it somewhere else.
Joe over-uses defensive programming, all pointers are tested in case malloc returns NULL, the game can start and run even when most assets are missing (missing textures are replaced with a procedurally generated “not found” texture, missing 3D models with a code-embedded rabbit object from GD Mag), his asserts have an “ignore always” button, exceptions and RTTI are disabled, and he uses a bunch of pragmas to disable all those useless compiler warnings.

Jack uses DX10 and his graphics code usually doesn’t run on cards from last year.
Joe still uses the Fixed Function Pipeline and misses the good old days of software rendering.

Jack uses proper O(n^3) LCP solvers, doubles for more accuracy, and uses distance queries for collision detection - penetration is forbidden.
Joe uses hacky linear-time solvers, floats, and he computes penetration depths with heuristic, borderline artistic, experimental code.

Jack wants all the string functions as members of the string class, because it’s “object oriented”. “There’s a string class, it should encapsulate all the string-related functions, otherwise it’s not clean.”
Joe doesn’t want a string class at all. He wants strcpy, strlen, and const char*.

So who’s right?

Well: Both and none. “Good” and “bad” doesn’t cut it here. It is not enough to stand on one side of the fence and blindly follow the rules or apply the recipes from your camp. The job is to be smart enough to know when to bend or break the rules. That’s the hard part: to give the recipe a subtle twist at the right moment. Anybody can program by the rules. Great programmers are the ones who know when to bypass them, how to bypass them, and who are not afraid of doing so.

In other words and as usual, the trick is to be flexible. The best thing to do is to be a mix of both Joe and Jack. And to handle your strings this way.

You’re the only one in the world using your coding standard. So it’s not really “standard”.

Self-commenting code is a joke. It’s a good excuse for your laziness. If the code is so obvious you don’t need a comment for it, it’s probably not doing anything interesting. Code worth writing needs comments, or even a full document. Self-commenting code is just not enough.

Refactoring 3rd party libraries is a criminal waste of time.

a) you may introduce new bugs while rewriting the code. Since you did not write the original code, they will be quite difficult to find and fix.

b) if a new version of the 3rd party library gets released, you have to either refactor it again, or live with the previous version. This possibly prevents you from getting important bug fixes or optimizations.

c) it is a complete illusion to believe you will understand the 3rd party code just because it follows your coding standard.

If you don’t know anything about the separating axis theorem, there is no way you will really “understand” an OBB-OBB overlap test. You will understand a given line, locally, but you will not understand why it is there, and how the algorithm works, globally. Finding a bug within the code is not going to be easier just because it follows your coding conventions (in particular if the bug is like this one).