Search this blog

28 March, 2008

Bad code is a virus

You did not document your system. You were in a rush and hacked the implementation. It happens even in the best families. Then someone else comes, and has to use that system. He does not find any documentation, so he searches in the code. It finds how you used it, copies and pastes. Code is documentation. Bad code spreads.
Always comment bad code (hacks etc). Always. Remove it at the end of the project. If you're the user, always ask if you don't find the documentation. Do not ever copy and paste code you don't understand/you're not sure of, do not trust code.
We can win, with your help, bad code can be eradicated.

27 March, 2008

C++ is too hard (for me)

I'm going, for the second time, through the book "C++ Coding Standards", a classic C++ book by Alexandrescu and Sutter. "101 Rules, Guidelines and Best Practices". And noone of them is unreasonable.

C++ is a huge language, it does a terrific job of giving to the programmer all the control he needs in order to predict exactly how the machine will execute his code, while still allowing some very high-level constructs to be crafted, extending the language. All of that, still being compatible with C, a.k.a. "the cross-platform assembly language".

Problem is, that to achieve all those three goals together, C++ has an enormous complexity behind it. Books and books were devoted only to tell what NOT to do with C++. Complex static code analyzers has been written to enforce those rules. Where I'm currently working we have more than fifty worldwide coding rules, that can be enriched by other studiowise and projectwise ones, enforced via code reviews and a custom configured static checkers (PC-Lint and Codewizard), and still I can't see them being applied consistently. Nor I've ever seen any source in the game/rendering realm strictly following all the well-known C++ best practices. It's crazy!

Even when you declare a class, there are many things you have to do before actually starting to write any code. The destructor has to be virtual or not? Protected or public? Do you want need to hide copy and assignment? Remeber to mark your single-parameter constructors as explicit. Why? Why do I have to mark my single-parameters contructors as explicit? Why? Why? If I want to declare a conversion operator, I do it, why do I have to use "explicit" to force a behaviour that should be the default one? I'll forget to do it! C++ is too hard for me, there's too much noise...

Bjarne Stroustrup said in an interview: "...Many minor and not-so-minor problems we have discovered over the years cannot be addressed in C++ for compatibility reasons. For example, the declarator syntax is an unnecessary complication—just about any linear notation would be better. Similarly, many defaults are wrong: constructors should not be conversions by default, names should not by default be accessible from other source files, and so on. Not controlling the linker has been a constant source of problems; in particular, implementers seem to delight in providing similar features in incompatible forms..."

Most of those not-so-minor problems are really driving me mad, on some days.

P.S. It could be a very nice idea to provide to your team some templates for the definition of common types, i.e. value types, pure interfaces, static classes, templates, base classes, etc...

P.P.S. Why C++ is considered immutable? Why couldn't we deprecate some old/bad language features? Java does this. You could emit a "deprecated" warning for such features, so people that are not dealing with huge legacy code bases can fix those warnings and turn them to errors, instead of having to rely on external static code checking tools to generate the very same results (because in the end, most of the stuff we enforce with static code checkers are really bad uses of the language that should be forbidden by the language itself)

21 March, 2008

No direction home.

I've noticed a couple of things about coding. One is about drunken coding, but it's not the topic of this post. The other one is about finding solutions.
I'm always surprised that most of the times when investigating bugs, or when trying to optimize a piece of code, or in other words, to find a new solution for a given code snippet, I tend to spend a lot of time at work with tools, iterating between the code, the debugger, Pix, and stuff like that. I probe the code, I dissect it and gather a huge amount of info.
But many times I don't find the solutions for those problems at work but on my way back home. At the same time I exit the company I start thinking and after a few minutes I find something to experiment with the following day.
Are those tools, fast iteration, the wealth of possibilities we have to operate on the code, reducing our thinking time? Many times it seems easier to tweak the code and find what happens, instead of pondering about the problem.
Is that something that happens only to me? Probably this is why I love minimal IDEs and languages for my home projects.

18 March, 2008

Four dimensions and more.

Are you doing you maths right? Are you tired of three dimensions? Linear Algebra is too way easy? Well, Geometric Algebra is more spicy. Jaap Suter tutorial is a great read. Geometric Algebra is a unification of mhm almost everything, vectors, lines, planes, quaternion, complex numbers, the awful plucker stuff, to any dimension.

It's nice to be able of reasoning in arbitrary dimensions. Now what we need is a killer application. Latest game programming gems (6) has an interesting article about using projective algebra to do enhance robustness of geometrical algorithms. But there aren't many other examples of uses of that extra coordinate we all get from memory alignment anyway. It's a shame, cool things could be done...