Make that again.

This is a particularly boring post, but it’s intended mostly for internal use.

Next time i’ll write about somewhat more interesting stuff like designing the objects hierarchy, resource files and modding.

There are two things i’ve discovered to be essential in supporting a large project. I think, not everyone will find these things equally important, or important at all. But for me the difference is in ability to continue developing.

Firstly, documentation.

Don’t believe your inner voice telling: “We can write the class summary. But we can write it later. In fact, let’s do it tomorrow. Oh, i know! Let’s make saturday a documentation day! Every 4-th saturday. Of January.” The bastard doesn’t have a drop of responsibility. But you will. So write the summary for every major class, especially for every public component.  Write short one-liners for your genius constructions, because week later you will probably have no idea what’s going on. And don’t drink’n’code.

Seriously, it’s kind of obvious truth, but leaving meaningful commentaries here and there eases future code comprehension and saves you much more time than 30 seconds you’ll lost writing them.

Second, refactoring.

Some people aren’t fond of the refactoring, implying that you should do a lot of planning and then write it all at once.

I’m more like try-and-see man, so my code fails fairly often. Sometimes it pops out much later (remember documentation?).

I used to hate rewriting the code, until i’ve meet the test-driven-development and its ideas. Martin Fowler’s Bliki is the canonical reference on the subject, if you want the details. Though i can’t say i’m a proficient TDD user, i’ve definitely learned from it.

“Don’t afraid to rewrite. That’s the good way to keep your head wrapped around your ever growing project.”

Following the basic TDD principles is very helpful here.

You design the general structure of your code, break it down to the modules and define their inputs/outputs, and then you stick to this schematics even if the module’s internal structure will have to be rewritten entirely. Most of the time that work, but even if it don’t and you have to change IO’s, you rewrite them in incompatible way and IDE will tell you where you should fix.

And of course, nothing will beat logic.

Your commentaries may be puzzling, you might have not been touching this part of code for weeks, but if you’ve been logical with your project structure, if your variables are named properly and methods are doing what they claim they do, then you’ll be fine.