It appears to be about programming on Linux and also about programming a simple video game, but the advice applies to any platform or language - including SBasic (especially on 2.0).


http://www.ibm.com/developerworks/linux/library/l-clear-code/?ca=dgr-FClnxw01lin...

Note the quote from Donald Knuth - one of my favorite really smart people.

BOBSCOTT wrote on May 31^st, 2007 at 7:23pm:


That is actually more in Andreas' ballpark more than mine. I don't think it has come up before. I know that he does have a simple debugger for it that he used while writing the compiler.

Bharat_Naik wrote on Jun 1^st, 2007 at 1:26pm:




Bharat,

A profiler is a program that watches your program and figures out how much time it spends using different calls.

It is talked about in tip 5 of the link Mark posted above. I make many of the mistakes discussed in the article so it was really valuable reading to me. I was especially intrigued  by the profiler! Here is a paste from the post.

Tip 5: "Premature optimization is the root of all evil." - Donald Knuth
I didn't make up the above sentence. But you can find it on Wikipedia, so it must be really smart.
Unless you are trying to make people suffer, your first goal, when writing code, should be clarity. Simple code is faster to write, faster to understand when you return to it later, and faster to debug.
Optimization is the enemy of clarity. Sometimes, though, you have to optimize. This is especially true in games. However, and this is the vital point, you almost never know what you need to optimize until you actually take your functioning code and test it with a profiler. (A profiler is a program that watches your program and figures out how much time it spends using different calls. These are awesome programs. Find one.)
Every time I've optimized one of my games, I've invariably been blown away. The code I was most worried about was always fine. The code I'd never thought about was slow. Because I had no idea what was fast and what was slow, all optimization time I had spent before getting actual data was wasted. Worse than wasted, in fact, because it tangled up the code.
This is a hard rule to follow. Heck, if it were easy, it wouldn't have to be a rule. Good programmers tend to be offended by clumsy code that could be faster.
But rejoice! After preaching about how you should spend more time doing this and more time doing that, this is one rare, precious moment when I'm saying that it's okay to be lazy!
Write something that is clean and works. You have all the time in the world to ugly it up with optimization later. But don't do it until you're sure that you're doing the right thing.