Re: Classic Traps -- I need your input!

Classic Traps:

1. Don't use I, O or now l as variables. It's too easy to see what you
expect and not what is really there. As I type this I see I need to
explain those letters. First is capital i, capital o, and lower case L. I
spent hours tracking down a bug when I was overlooking the capital letter
i on a line printer with a number 1.

2. Don't reinitialize a variable if you don't need to. I've seen a lot of
programs that retrieve and reformat the program date for each record read,
and then write it to a file. This really becomes noticeable when you do
this date retrieval and reformatting for each of the 100,000+ records you
are reading. Initialize and format the current date once, and then move
the value to the variable in the record

3. Stop using the 10000.0001 date multiplication. I did a performance test
on this back in the 90's, and it took 18000 time longer to do the date
multiplication than moving the date to a data structure to reformat it.

Steve


Steven Morrison
Fidelity Express




Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
03/30/2008 05:48 PM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
cc

Subject
Classic Traps -- I need your input!






Folks, I'm working on an article that's tentatively titled "Classic
Traps and How to Avoid Them". The general idea is to discuss the classic
mistakes that programmers make while programming, and (where necessary)
explain how to avoid that.

This can be simple things like "Don't use 10000.01 to flip dates,
because it's an obscure technique that many people won't understand, so
even though it's really neat, don't use it". But it can also be a much
more broad and sophisticated notion of a "trap".... "Don't get into the
habit of mixing business logic together with display logic. Although it
makes your program much easier to write, and the code is much easier to
follow, over time it results in a system that's very difficult to
maintain when the business wants to change something, it becomes very
slow and difficult to adapt the old system to the new paradigm"

Or something like that.

Anyway... I would REALLY appreciate your help. What I need to do is get
together a list of the classic traps that programmers fall into. Please
send me a list of the common traps and mistakes. You can just reply to
my e-mail address directly (I don't want to dirty up the lists too much)
The e-mail address at the top of this message will work fine.

I just want to get together a good list of classic traps so I can use
them in my article.

Thanks