25 replies to this topic

[Vol Yip]

I totally agree with Dan's comment about Scratch varaible.

Once upon a time I had debugged a report function which printed unreasonable result. Everything looked fine until I finally found that programmer used #RECONGIZE_COST as field variable but used #RECONGIZED_COST during the calculation

[Mike Nicholson]

Good for some things though - e.g. global interfaces. For which I refer you back to the wonderful 1=0 discussion some time back ;-)

I've got a routine which will check a function for all scratch usage and count up the number of times they are used (all usage - fields, interface, logic etc.) Anything only used once gets closer investigation and zapped if no longer required.

Cheers

Mike

[Donald Miller]

Mike - I know how you feel about VIP but change is good. Once you have entered a scratch variable into a function you shouldn't need to enter it again as it is available to be selected. That should root out all those typos - epsecailly for those who can't type and for those that can't remember what they're doing...

[Rob Donovan]

Hi,

I too hate the people who have to put every file variable into a scratch var.

Our system is full of them.

I think the reason people do it is because they dont unserstand the timing cycle correctly, and therefor are worried that the variables will be overwritten.

Our system is also full of alternate file reads (ie _1,_A or Q files) because again people dont understand the timing cycle correctly.

It just makes the code much harder to read.

Rob.

[Mike Nicholson]

But Donnie - I've got a routine for that so I don't need VIP ;-)

I'm actually not massively VIP-averse these days but it's still much quicker to code in pro-aide for the moment, especially on a green- screen system.

BTW Rob - just to back up your statement (for a function you'll recognise you sad man you ;-) - removed about 10 unused scratches from MD.TRCV1 the other day . . .

There are all to many problems fixed by setting a value into a scratch and resetting the file var later - instead of finding out what the problem actually is and fixing it...

Cheers

Mike

[Rob Donovan]

BTW Rob - just to back up your statement (for a function you'll recognise you sad man you ;-) - removed about 10 unused scratches from MD.TRCV1 the other day . . .

Oh dear oh dear... I cant belive you've managed to get MD.TRCV1 into a post

Rob.

[Joseph Bove]

Dan,

My advice to one and all is *NEVER* *EVER* use scratch variables

I think that some the issues you listed, like obfusicating code have a lot more to do with design than anything else. A scratch variable called $PARM is just plain hideous. However, if the person putting together the database suffers from the same poor naming skills, your files could be equally obscure.

Going the route of using only file variables has its own drawbacks as well. For example, the file variable may be set in LS 1, and written in LS 3. This presents its own challenges for debugging.

One thing that we did in-house was to develop a scratch variable assessment tool. It's quite useful for figuring out when scratch variables are being used in an unbalanced fashion. (example: set, but never inquired)

[Dan Shannon]

My advice to one and all is *NEVER* *EVER* use scratch variables

Joseph

Of course when I give that advice, it's only advice - the real point is to try and get people to think about why they need to use a scratch variable, indeed if they need to use one at all. Many people just do it as a matter of course, and that's plain slack programming. Obviously sometimes you really do need to use them!

Cheers

Dan

[Joseph Bove]

Dan,

Many people just do it as a matter of course, and that's plain slack programming

Point taken.

I think that all programmers probably loathe having to look at someone's code and not understand it... or worse yet, look at our code several months later and not understand it.

Regards,

Joseph

[Sindre Solem]

"Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live."

[Joseph Bove]

"Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live."

I like that quote. However, if a good chunk of the time, I will end up maintaining my own code, wouldn't I end up with a pretty negative view of myself?