I challenge # 4 specifically. That takes away the entire concept of Equate
Aliases which is pretty useful and a huge step towards consistently named
fields in data files.
I don't use them on purpose but for those clients that embrace it, it's
pretty nice.
Also, no-one has mentioned the 4 letter word until now. I will defend my use
of it and offend the mis-use of it. Until they remove it from the compiler
and from the thousands of programs I currently support, it stays.
Otherwise I agree.
P.S. Regarding #1. I like X=1; Y=2; X=3; AA=4 on one line, especially if the
variables are related. I don't like having multiple complex lines on the
same statement expecially if they're after an IF statement.
Also, I think drop-down GOTO's or RETURNS should be on their own line. I've
seen code like this and it's pretty stupid:
*
*** NAME
10 PRINT @(10,15):;INPUT ANS
REC<10>=ANS
PRINT @(10,15):ANS"L#15" ; RETURN
*
*** ADDR
20 PRINT @(10,16):;INPUT ANS
REC<11>=ANS
PRINT @(10,16):ANS"L#15" ; RETURN
----- Original Message -----
From: "Richard Taylor" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, September 30, 2005 10:52 AM
Subject: RE: [U2] Good Programming Practice Question.........
> 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/
