Uh...

Makes me feel sad!

On the bright side, their compilation times would be pretty fast!

At this point I feel compelled to point out that the previous thread is ApochPiQ posting an entire compiler implemented as a single 10,000 line file...

The line between awesome and awful can be a very fine line.

TRWTF is

using namespace std;

TRWTF is

using namespace std;

On the bright side, their compilation times would be pretty fast!

Yeah, if they never ever have to change anything in that code again, ever.
Which I really hope for the poor soul that has to maintain this abomination.

TRWTF is

using namespace std;

What's wrong with that? It's after all their headers, in a cpp. Standard library is bad?

On the bright side, their compilation times would be pretty fast!

Yeah, if they never ever have to change anything in that code again, ever.
Which I really hope for the poor soul that has to maintain this abomination.

I meant that one large file often compiles faster than many small files, even though it's technically doing more work... ;) good old C++ ;/

It's still polluting that translation units global namespace, but I take more offense to all the externs and global variables defined all over the place. The person class is a nice read as well far less bad in function design but the whole class internal variables are public :)

This section is also very awesome: http://hg.icculus.org/icculus/lugaru/file/97b303e79826/Source/Terrain.cpp#l132

void Terrain::Update?Transparency(in?t whichx, int whichy){ /*...*/ }
void Terrain::Update?Transparencyoth?er(int whichx, int whichy){ /*...*/ }
void Terrain::Update?Transparencyoth?erother(int whichx, int whichy){ /*...*/ }

"otherother"

Getting code to compile isn't actually that difficult; it's just a matter of following the syntax rules of the language you're using.

The real issue here is that, at no point during the initial writing, does anybody seem to have said "STOP!"

In other words, all of the problems with this code are easily resolvable at source, and it doesn't take a genius - or any great particular skill - to see a codebase beginning to get messy or out of hand. But that needs to be observed early in the process; once it's been observed, one can say "OK, better start cleaning this up a little" and - at the very least - shove some lines of code around to make things easier and cleaner. That doesn't seem to have happened at all here. Instead, the author(s) seem to have just ploughed on relentlessly beyond the point at which almost anybody else would have stopped and refactored.

I don't see "high school/self-taught" as being a valid excuse for this; anybody would look at this and say "eeewww, my code sucks!" and anybody would have a desire to make it less sucky. This isn't just the kind of sucky code that we've all written when starting out, this is a new pinnacle of suck, the suck-de-la-suck, the "OH MY GOD MAKE IT GO AWAY" of suck. It takes a special kind of relentless bloody-mindedness to continue beyond the point at which anyone else would have stopped.