Thanks David. I feel less alone. As far as the order of processing, it's an acquired taste. We all recall learning the order of calculations between +, -, / and *. Despite it compiling without parenthesis and coming up with the right answer, I too like to make it more obvious with using parens. X=4+5*7 vs X=4+(5*7) or X=(4+5)*7. You know the story.
With that in mind, I've proven thousands of programs ago that PRINT X/100"R2,#10" works as expected without fearing that it may come up as X/(100"R2,#10"). Only by testing did I gain the confidence to omit the parens. In the Jurrasic Pick era, people got tired of typing EXTRACT (et al) and started using DIM arrays or other FIELD etc methods to save keystrokes. I too retired the letters OCONV() when I gained that confidence. I know that I can use DATE()"d2/" and the numeric expressions earlier. I also know that I cannot use TIME()"MTHS" so I revert to OCONV(). I also know that if a date value may be empty in a formatted line, I don't trust X"D2/""L#10" so I use (X"D2/")"L#10". Bottom line is what's comfortable and what environment you are working with. Like David, I've been around the block a bunch and have seen horrible code that I can cognitively omit using. One clients' system has this style of dynamic array handling embedded everywhere and I dare not change it without a whole lot of finger crossing: Z=CHAR(254) ; ZZ=CHAR(253) REC=NAME:Z:ADD:Z:CITY:Z:STATE:Z:ZIP:Z:Z:Z:STR(Z,15):PHONE1:ZZ:PHONE2:Z:SALES MAN WRITE REC ON CUSTOMER, CUSTNO Quick, which attribute are the phone numbers on? When you inherit this kind of garbage and have your hands tied on justifying its improvement, then you can get an appreciation for the diversity of MV programming and don't get too caught up with tweaking the few best commands. I won't offend the FMT/OCONV crowd but I will defend against those who stand on their soapbox and offend simpler coding. My 3 cents Mark Johnson ----- Original Message ----- From: "David A Barrett" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Thursday, November 22, 2007 9:47 AM Subject: [U2] Re: U2 Users Digest V1 #1968 > There was this: > > >>> Speaking of mis-used commands and side-stepping some of the given code > >>> craziness... > >>> > >>> It is better practice to atomize the code into discrete elements such > >>> as... > > Var1.F = oconv(Var1, 'MD0') > Var2.F = oconv(Var2, 'MD2') > Var3.F = oconv(Var3, 'MD4') > > Crt.Str = Var1.F 'R#6 > Crt.Str := Var2.R 'R#12' > Crt.Str := Var3.F 'R#14' > crt Crt.Str > > > >>> rather than to try to kill two birds with one stone by including an > >>> oconv statement inside a crt statement such as... > >>> > >>> crt oconv(Var1, 'MD0') > >>> > >>> --Bill> > > And this: > > > >>Womack, Adrian wrote: > > >>> IMO, the only thing wrong with your example is the use of the > trailing > > >>> format strings - everyone (and I mean everyone) should be using the > FMT > > >>> function, making your example: > > >>> > > >>> CRT FMT(OCONV(VAR1,"MD0"),"R#6 "):FMT(OCONV(VAR2,"MD2"),"R#10 > > >>> "):FMT(OCONV(VAR3,"MD4"),"R#14") > > Yikes! > > As someone who has spent the last 25 years of my life looking > at/fixing/changing code that someone else wrote I have to say that I value > terseness over everything else. Create a variable just to hold the > formatted version of some other variable to avoid embedding OCONV's in a > PRINT/CRT/DISPLAY statement? Just looking at code like that would have me > drawing a warm bath and getting out the razor blades. Never mind having to > write code like that. > > Personally, I find the trailing "D2/" a little too subtle, and prefer the > use of OCONV statements just to make the conversion jump out a little more > when someone takes a quick glance at the code. Justification and fill via > "R%6" and so on works just fine for me, and the extra space taken up with > FMT function calls only serves to make the code harder to read. > > As to a "disaster waiting to happen". I've never seen, never even heard of > it happening. Doubt that I ever will. Programmers make typos all the > time, keeping the code terse and clean is the absolute best way to make > them easier to spot, easier to avoid and easier to fix. > > I don't like: > > PRINT ABC/100"L%6" > > because I'm never quite trust the order of operations or my rememberance of > them. I'd use: > > PRINT (ABC/100)"L%6" > > I never saw a line of code that wouldn't be improved by adding some > parenthesis. :) > > And I'd never use: > > X = (ABC/100)"L%6" > > or > > X = OCONV(ABC,"MD2,") > > Unless there was some extraordinary reason to have a variable floating > around with formatted data in it. I consider it a best practice to keep > all variables as internal, unformatted data and apply the formats in the > output commands themselves. > > > Dave Barrett, > Lawyers' Professional Indemnity Company > ------- > 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/
