Another great point of contention. For over 35 years (including pre-MV of the PDP-8 era), I typed FOR I=1 TO 10 and not FOR I = 1 TO 10.
Meaning, my 'habit' (not style or standard) does not use X<space>=<space>1 but X=1. I don't use spaces as separators when using the colon (contatenation) function. Thus I use PRINT X"L#10":Y"L#10". I do use spaces when putting multiple statements on the same line, X=1 ; Y=2 ; Z=3. I know that will ruffle a few feathers as there's a large camp condemning more than one statement on a line. I do use spaces with CALLed sub parameter strings, aka CALL SUB(A, B, C, D, E). In fact, I make a conscious effort to add the spaces as many programmers before me jam punctuationed parameters in the parameter area that makes it hard to discern, aka CALL SUB(TRK.MFT,SHP.RPT,F.FILE, D.FILE,F.TRK.DFR,USER_ANS1,USER_ANS2,RET_VAL). When printing, especially on non-laser printers, the commas and periods look too similar. I add a space after the commas in any read/write commands. Might I digress on file handling: I hate the non-filehandle option on production programs. It's acceptable only for single use, 'programmer's' programs. We can get into a whole dissertation on the nomenclature for file-handles. I believe I have the best practice for the OPEN statement. In fact I had it published by Spectrum years ago. Anyone who still uses OPEN "","CUSTOMER"... meaning the null dict reference should get his head out of the sand. It's never been required, at least not by the truly earlier MV flavors (MCD, ULT, MENTOR, R80 etc). If it was required by Prime (spawning UV/UD), then it's not required by U2 today. My 4 cents Mark Johnson ----- Original Message ----- From: "Bill Haskett" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Thursday, November 22, 2007 1:25 PM Subject: RE: [U2] Re: U2 Users Digest V1 #1968 > Mark: > > I always thought a principle of languages was to separate words. In this sentence, > > ... programs ago that PRINT X/100"R2,#10" ... > > you've separated each word, within the sentence, with a space, but not the BASIC > code. Why not BASIC? > > PRINT (X/100) "R2,(#10)" > or > X = (4 + 5) * 7 > > I believe you're correct when you talk about principles and inherited code. > Sometimes principles go out the window. However, when writing new code certain > "principles" should be followed and one is left to themselves, or others, to devise > their own "style". > > Bill > > > >-----Original Message----- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] On Behalf Of MAJ > >Programming > >Sent: Thursday, November 22, 2007 9:43 AM > >To: [email protected] > >Subject: Re: [U2] Re: U2 Users Digest V1 #1968 > > > >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. > > [snipped] > > > > >My 3 cents > >Mark Johnson > ------- > 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/
