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 :D).
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 ;D 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.

[Ñuño Martínez]

You're right. :)

Also it should be "fVw / fVh" because is width and height to calculate the OpenGL viewport relation.

Anyway the result was that graphics were a a bit deformed.

[pitfiend]

The worst thing I did, was try to convert a visual basic app to delphi. It was a totaly mess and a big waste of time. What I learn? never again convert someone else code, specially if it comes from visual basic. It's better to build new things with new approaches. No matter how well writen the original code is, in the end it's always a different way to see and do things, and an incompatible programming philosophy, it's bad if you have only code and zero documentation. I had to refuse the job, but instead I accepted it.

[User137]

I would take that challenge :p But surely there are may coding differences between Pascal and Basic language, that force you to plan some things differently.

[Super Vegeta]

http://govnokod.ru/pascal
Prepare your facepalm cannon.

[FelipeFS]

FVar : Booelan;

if FVar = True then
begin
...
end;


Actually I like doing that!!! I think it is more readable than:



if FVar then
begin
...
end;

[User137]

Not that i have ever done this, but i can imagine the above code would be about same as this ;)

if (a = b) = True then
begin
...
end;
Let's hope the compilers know how to optimize the extra comparison out of executable.

[pitfiend]

Not that i have ever done this, but i can imagine the above code would be about same as this ;)

if (a = b) = True then
begin
...
end;
Let's hope the compilers know how to optimize the extra comparison out of executable.
As far as I know, Delphi has a shortcut evaluator for booleans. But this is going to push it to the limits ;)

[pstudio]

As far as I know, Delphi has a shortcut evaluator for booleans. But this is going to push it to the limits ;)
I can't see why a compiler should have a hard time optimizing the code. It seems to me, it would be simple to add a rule saying something like:



if our code says
boolean = True
then replace the code with
boolean


This should be quite easy when you've made a syntax tree.

[pitfiend]

I can't see why a compiler should have a hard time optimizing the code. It seems to me, it would be simple to add a rule saying something like:



if our code says
boolean = True
then replace the code with
boolean


This should be quite easy when you've made a syntax tree.

I misspelled my statement, I wanted to mean: this is pushing the limits of stupidity. Didn't want to sound rude or politicaly incorrect.

[pstudio]

Ah ok, then I misunderstood you :)