Exception to no multi-command lines.
TOT(1,1)=0; TOT(1,2)=0; TOT(1,3)=0; TOT(1,4)=0; * Resets array for this loop
And as far as no MATREADS/WRITES. You can always INCLUDE the DIM
statements. Which can also include the equates for standardized
variable names for each attribute. And yeah, you'd have to recompile
every program when new attributes are added. But as others will point
out, if you're updating a lot of attributes, there are performance
advantages.
Roger
Richard Taylor wrote:
I would add a few:
1) no multi-command lines (i.e. command ; command; command
2) Use Continue and Exit inside loops to handle error conditions.
3) I then to prefer the following for working with select lists
LOOP WHILE READNEXT ITEM.ID DO
Some commands
REPEAT
4) No MATREAD & MATWRITE. Some will probably disagree, but to me this
takes a wonderfully dynamic system and hamstrings it. I have also seen
data corruption happen when you have a large file dictionary than the
array dimension. This is definitely platform dependant though. Unidata
just puts all remaining fields into the last array position. If you then
change that position expecting it to be just the one field you want to
work with, the remainder of the data is lost. Universe behaves
differently, but I still don't think using these commands is a good idea.
Ok, let the flame war begin.
5) Proper variable names; no single character variables, variable names
should indicate there purpose.
6)INDENT YOUR CODE. This may be obvious to most here, but I have worked
with programmers that seem to have a phobia about this.
Generally, I have always had three general rules that I apply up front.
All the specific standards created work to support those three rules.
1) A program must work. By that I mean that it solves the client's
problem and gives them what they need. It is NOT simply that the program
was syntactically or even logically correct.
2) The code must be readable by any one. Indentation, comments, variable
names are things that support this.
3) The code must be maintainable. Proper structure, NO use of the
'command-that-must-not-be-named'
One other thought, since you are talking about new programmers. You will
likely need to train them on proper testing/debugging technique. The
basic mistake I see many programmers make in testing is that they test to
see that it works. What you should be doing is trying to break it! Lord
knows the users will.
That is my $0.02 such as it is.
Rich Taylor | Senior Programmer/Analyst| VERTIS
250 W. Pratt Street | Baltimore, MD 21201
P 410.361.8688 | F 410.528.0319
[EMAIL PROTECTED] | http://www.vertisinc.com
Vertis is the premier provider of targeted advertising, media, and
marketing services that drive consumers to marketers more effectively.
"The more they complicate the plumbing
the easier it is to stop up the drain"
- Montgomery Scott NCC-1701
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
