Silly things we used to do?

[WILL]

Hey guys, since there have been recent topics on things we should do, how about talking about what we have done that we shouldn't have done? What are some of the coding mistakes that you've done in the past that you've learned from of just never got over? What's your worst/best?

Who is able to make fun of themselves a little?

[pstudio]

Not really a mistake but definitely a silly thing I used to do back in my early days:

var myBool: Boolean;
...
if myBool = true then
  myBool := false
else
  myBool := true;

First I figured out that there was no reason to type

if myBool = true then

when I could just type

if myBool then

Later I figured out simply to write

myBool := not myBool;

I comfort myself having seen many beginners write the same kind of code. It's nice to know I'm not the only one

[SilverWarior]

Back in the days when I was making just some trivial applications I have been using forms caption for monitoring progres for some long processing. The reason why I used this approach was the fact that even when you were rapidly changing Forms caption (updating caption for each step) doing this didn't slow down overal procesing much (barly noticable) and the caption did updated even when the rest of the form was unresponsive becouse procesing was done in main thread.
While this approach works nice on Windows XP and older I strongly disadvise to use this approach on Windows Vista or Windows 7. The reason for this is the fact that Aero desktop don't ofer so quick forms caption drawing as it was on Wondows XP. The reason for this is semitransparent windows that are used in Aero desktop. So changing caption rapidly would lead to considerable slowdowns of you processing, and even worse, it wil cause whole windows GUI to be porly responsive. Having several windows like this can cuse whole windows GUI totaly unresponsive (tried in practice ).
So instead use normal approaches for monitoring procesing progress like ProgressBars etc. Also try to update these ProgressBArs in certain intervals and not for every step.

[User137]

I used to refer to vectors with all its components, without taking advantage of record structures. So something like this was not unusual:

PointInRect(x1, y1, x2, y2, pointX, pointY: single): boolean;

But you can write it like:

PointInRect(const p: TVector2f; const rect: fRect): boolean;

It's about consistency in different units. Little by little there became patterns and things "melted" better together.

[WILL]

Okay fair is fair so here is one of mine.

I remember when I was first learning about OOP with Object Pascal(we're talking Delphi 3 here) and how you could reference object types in memory by using pointers. Well the beauty of Object Pascal and even Pascal is that you just don't need to use any pointers except in specific cases, well I had them everywhere in my game's code, it was like a nightmare. It was so bad that I even had to check for what kind of object I was referencing.

The cool trade-off was that I was able to make an array of multiple object types into one. I had to do some crazy stuff to do it, but it was my most experimental project to date, despite the many years ago this was. Needless to say, I'm not a huge pointer fan these days.

[SilverWarior]

If you need to have multiple objects in same place (array) I suggest to use TList instead. TList is actualy component build around pointer array. Its main advantage over regular arrays is that it already contains necessary methods for item managment (adding items, removing item, moving items, sorting items etc.). If your list contains items of mutiple types (classes) you can always check classname for certain item to determine its type.
There is also a TObjectList component wich could come verry handy especialy when you use OOP approach in your games (ingame objects are actualy TObject decendants). The main advantage of TObjectList is that it can own its items. What this means? This means that when you remove an object from ObjectList it automaticly cals default destructor method for the object.

[Ñuño Martínez]

Few days ago, in my 2nd PGD Challenge entry. Something didn't worked. And if I changed it, it didn't change. The problem was that I didn't call the procedure that I was working on, but I was working hours..

Also, I wrote something like this in the OpenGL initialization procedure:

        glFrustum (-1 * fVw / fVw, 1 * fVw / fVw, -1, 1, fNear, fFar);

Can you see it? I didn't in 5 days...

[Carver413]

micro managing my code was my worst mistake, back in my delphi days. when I switched to Lazarus I scraped all my code and began a new. so glad I did.

[SilverWarior]

Can you see it? I didn't in 5 days...

I can Dividing fVw with fVw in two places (forget to use brackets).
When I do any mathemathical expressions I always rely heavily on using brackets. Sometimes I even use more of them than actualy needed (pascal does multiplications and division before addition and substraction). I do this to be absolutly sure that math is done just as I want it to. Also it helps me to understand my code more easily.

[WILL]

Yeah improper structuring of math calculations can be a big code killer. It can also come up with some wacky behavior too. I remember working with AI using Neural Networks with Genetic Algorithms and I just don't know if I ever got the math right, but my little library I made, up just wouldn't work right. It's been ages, but I still think it was badly coded math.