Home

Typing is the enemy of programming.

GENERAL CAR SIM TIPS

As general programming tips, I've noticed the following during my 15 years of programming:

• NEVER ever use 'delete' directly in C++. My opinion is that it has a fatal design flaw; every such statement leaves by definition a dangling pointer. And remember, dangling pointers (pointers which points to unallocated storage, which is mostly intact but can be overwritten at the next allocation) are a big contributor to those 'mysterious' bugs that happen now & then (just after writing beyond automatic stack variables, like 'char buf[10]; strcpy(buf,"You didn't think this is going to work?");'.
  Use instead something like:
  #define MYDELETE(v) {if(v){delete(v);(v)=0;}}
  This will check and delete the variable pointed to by 'v', and set 'v' to 0 after that. This will make if far easier to detect if you are accessing deleted objects, since you will get bad 0-pointer references. It cost me several hours for a bug like this to trace, after which I started transforming my source code to use this more safe form.
• NEVER use 'free' directly. For the same reasons as with 'delete', this creates dangling pointers by definition (something to which languages like Pascal and Basic are much less prone). Also use something like:
  #define MYFREE(v) {if(v){free(v);(v)=0;}}
• Keep your functions short; this will allow you to keep the bird's eye view of your project better. And a better view means a clearer picture means less bugs, and more flexibility.
• Keep variable names and function names descriptive; this will help if your project takes more than a month. You WILL forget how your program worked in time.
• Design first (on paper for example), program later. Only start programming when you have a clear picture in your head of what you want to achieve. This helps programming productivity very much.
• Create goals and subgoals to keep going ahead. You'll need subgoals if a project seems large. Design the global scheme of things first, than create subgoals that can be achieved without the rest of the application working yet. I always like to see results early on, so I go for things that I can check (if they work). Filling in subgoals gives you the feeling that you're actually getting forward, an important thing (for me, at least).
• Give your head time off by selecting other goals at times. Don't keep banging at the same subject until it works perfectly. Your brain will get saturated and progress will get slower. By turning to another subject/goal for a moment, or just doing something completely different, your right side of the brain will have time to work on the subjects that are seemingly at rest. Don't depend too much on your left brain for too long, especially when things get tough. Things will often pop up at unexpected moments.
• For every big problem you had, think of how your code could have caught it beforehand. A lot of problems can be catched by regular code in easy ways, before things get out of hand ('the program sometimes crashes' is the most nauseating diagnostic you can have). Use debug macros freely.

These rules have at times given me more productivity and more progress than I thought would be possible. Programming should be trying new ideas, and debugging should be needed only at a minimum.

GENERAL CAR SIM TIPS

• Strangely, I've noticed that when adding '-' signs to get formula's correct, they often tend to be a result of a flaw in the design and can be taken out later when you've totally figured out how a system works. No really, the number of '-' addition grows as you build in a new physics thing, only to be removed later when all forces and torques have the right orientation, and things just work like it is.

Reread this page after some time, it's really hard-earned experience.

(last updated June 29, 2009 )