 This thread in the general development forum inspired me to write this tech-file entry. It seems that every new, young software developer at some point decides the “experienced” people are all wrong, and he/she doesn’t need to do things “the right way”. What’s wrong with goto? Why are public variables bad? Who needs Object Orientated Programming anyway? I don’t need comments, I KNOW what my code does! I think I understand where this comes from. Most programmers start young, they work alone, and their projects are small. This means they do not see any direct benefit from the “proper” methods. As one person in the thread I mentioned explained, “I haven’t used a private variable since 1997. The funny thing is I’ve encountered zero problems that can be attributed to this”, and I completely believe him. But…. Although I don’t consider myself an incredibly good software developer, I have gained some experience in the last three or four years. If there is anything I learned, it is that all the “proper” ways of doing things can definitely have enormous advantages in the real world. All this Object Orientation, Encapsulation, Polymorphism and Proper Design stuff was not invented because it is cool or sexy, nor does it stem from some purist desire to have “nice” code. It came from the experiences of earlier software developers who ran into all kinds of problems when they attempted ever more complex and larger-scale software projects. It is intended to make real-world software engineering easier, more reliable and more predictable. In a serious project, a lot of people work on a large code-base (10,000’s to 1,000,000’s of lines of code). Every module interacts with other modules, and some basic modules are used by a LOT of other modules. This means that changing interfaces can have severe side effects that take a lot of resources to fix. Encapsulation prevents a lot of interface changes. People get hired, write some code, and leave again. You will find yourself modifying and debugging code you didn’t originally wrote yourself. A uniform code-style and Even worse, over the course of a project requirements are bound to change. Don’t complain that your code must be rewritten almost from scratch to accommodate this requirement change, that’s your problem. A good design recognizes this and makes the most likely changes easier. Moreover, when a project is finished you will have to maintain your product. Bug fixes, patches and updates will be necessary. Maybe small features need to be added. You would like to minimize the time you spend on such things, if possible. “Proper” design and implementation leads to code that is easier to test, debug and maintain. The key characteristics of a successful project are that it is: On time, within budget and according to spec. Over time, experience with such projects led to tons of “best practices”: Ways of doing things that increase the chances a project will achieve these three goals. Things like using a revision control system (CVS), a bugtracker (mantis), a unit-test framework (cppunit), a code documentation system (Doxygen) and reviewing each others’ code fall in the “best practices” category. Like it or not, games are made, or at least published, by companies. That means money is involved, and it means “on time” and “within budget” are important. This in turn means that these best practices are very useful, if not essential, to the success of your current and future projects. “But”, I hear some of you say, “All this doesn’t apply to me. I am programming GAMES, not databases or aircraft control software”. Let me help you get rid of this idea right away: Game programming is not, in any fundamental way, different from any other branch of software development. Granted, Game Programming is different in several ways from more conventional programming. For instance: But in the end, making a game is still software engineering, just like making any other piece of software. Therefore game developers benefit just as much from good practices as anybody else. This doesn’t mean that OOP and all the other things I mentioned are some sort of magic bullet that make software engineering a breeze. It also doesn’t mean that all the “old” techniques cannot be used anymore. C is very appropriate in many situations (Gameboy Advance programming, for instance) and even assembly has its place in embedded applications and for some tight loops for instance. But it does mean that even though it is not immediately obvious what the benefits of some practice or technique are, that doesn’t mean it has NO benefit. It was a while ago that I read something like this on the flipCode message boards: I couldn’t agree more. Happy coding, Jeroen 
Download The Sample Program: ManicMotion.exe |
