Style wars

Path: emory!swrinde!sdd.hp.com!wupost!uunet!mcsun!uknet!stl!bnr.co.uk!th From: th@bnr.co.uk (Tony Heskett) Newsgroups: comp.databases.informix Message-ID: <5492@stl.co.uk> Date: 6 Mar 92 20:11:34 GMT Sender: news@bnr.co.uk Reply-To: th@bnr.co.uk (Tony Heskett) Organization: BNR Europe Limited, London Road, Harlow, Essex, GB Yup, I'll bite :-) Sorry this is a bit long, the very end bit may be more interesting. pmahler@StarConn.com (Paul Mahler) writes (using a VERY broad brush) :- > Looking at most informix programs makes me want to puke. They > all look like they were written at terminals with organ pedals > instead of a shift key. Of course, this is only a small part of the > problem. Could you clarify this organ business just a little, please ? > Most C programs I have seen don't have this problem. If they > were written by generally competent programmers they are > generally well structured, well styled and easy to read. Most {C,Cobol,Pascal ...} code out there is fairly poor, too. C and pascal don't have the UPPER CASE problem, but that's a *very large* "if" you've got there. > Most 4gl programs look like they were written by stupid BASIC > programmers. s/stupid// 4GL tends to be directed at non-programmers, where C would never be. Fair enough, 4GL's easy and it gets the job done a damn sight quicker. If it was written by a novice, that'll show, but so what ? It's a lot cheaper that way, and if you want-to/can-afford-to/are-able-to pay the old hands they'll write you better code. > This seems to be an artifact of the very first > examples that came out of Informix where all the key words > were in upper case and lots of extra blank lines were inserted. Yup. > There also doesn't seem to be a beautifier > that would allow existing programs to be codified to the same style. > This is perhaps because the grammer is large. No, it's just 'cos we're all busy working already :-) > Writing a YACC > grammer would be a big deal and anything probably wouldn't > work very well. Informix wrote one - want to ask Oracle what they think of it ? ;-) > The only grousing I have heard about a beautifier > was from Tony Heskett who was trying to figure out how to > capitalize the key words, which is, of course, backwards and > stupid to boot. If you've got a company coding standard that bungs stuff in upper case, and you've got used to it so you find it's easier to read anyway, it's as well to carry on. My "grouse" was to say that I've got a very small, simple program which maps keyword stuff to upper case and if anyone would like a copy let me know. Still applies, if you're not swayed by Paul's persuasive/dispassionate args. It sometimes helps [ novice | stupid BASIC ] programmers avoid using reserved words for col names or data, which can be quite tempting. > So now that I've pissed off all the 4gl programmers out there Just be polite to Ruchi, no-one else gets upset !! > and you have your flame throwers on, what about this style > question ? > > Here is a fragment of code I stole from dbgen by David > Snyder. This is a wonderful program written by a superb 4gl programmer. So you like it ? Even without a :g/.*/\\L&/ ? Good. > I have changed it a bit for the purposes of discussion. But left the shell script stuff in ... > DEFINE w_record RECORD LIKE $TABNAME.* # working record > DEFINE n_record RECORD LIKE $TABNAME.* # null record [ ... lots of db4glgen deleted ... ] > Here is much the same program with various stylistic changes. > if q_cnt > 0 or other_var = TRUE then > if repo_tabname("c", "q") then # r4gl requires return values > let q_cnt = q_cnt # to be used whether they are > end if # needed or not. > else > let w_record.* = n_record.* # faster than initialize > end if > Please note that spaces have been changed into tabs in the second > version. Which is probably worse than the normal 4-space indents, since the lines tend to get too long for the screen/printer. Your choices are then to wrap them or truncate them, either of which is pretty lousy. I know you can change the tab stops in any sane editor, but if you don't have them on 8 you'll get f****d in the end anyway. > I also added a few lines. In particular there is > a line that uses a value of TRUE. This is beacuse I think that > capitalizing macro names or built-in constants (like NOTFOUND) > makes the program more readable. Yup. > So what do you folks think? What makes for an attractive, > legible, practical 4gl style? One that's easy to write, that everyone on the project works to. If the company's got lots of code in a particular style, yours should fit with that. If their style is atrocious, give them some sensible guidelines. (I've inherited 3 sets of company coding standards, all different unfortunately). The tabbing & line spacing should be enough that you can see the structure of the thing at a distance - say, across the room. Writing the stuff in upper-case tends to force double-spacing simply cos the letters are taller, which is of course a disadvantage. Linelength should be less than 80 if at all possible. I agree completely that lower-case is easier to read than upper, for free-flow text, but the case for code *IS* slightly different. > -------------------------------------------------------------- > Paul Mahler internet: pmahler@StarConn.com > Consultant > 1800 Market St. #257 voice: 415.327.6737 Just while we're here ... Advert: I've got a real dog of a program that attempts to do cross-referencing for I-4GL (but only if the keywords are in upper-case :-) I normally wouldn't wave anything as ugly as this around in public, but I haven't seen anyone else produce anything. It might at least provoke a few new ideas ... If you'd like to plug'n'play, let me know and I'll send you a copy under plain RFC 822 wrapper. Glad to see the ol' group's warming up a bit ! Remember Melissa on rec.humor ? Have fun. Cheers - Tony. __________________________________________________________________________ Tony Heskett th@bnr.co.uk Voice: (+44) 279 429531 x 2637 BNR, London Road, Harlow, Essex, CM17 9NA Fax: (+44) 279 454187