Re: 4GL style (was Re: Is this a bug w/ 4GL 4.10)

->From: dbroker@hermes1.sps.mot.com (BSI DATA BROKER) ->Date: Fri, 30 Jul 93 20:15:38 MST ->To: aeaim-co-se-03@heidelberg-emh2.army.mil, alan@po.den.mmc.com, -> informix-list@rmy.emory.edu ->Subject: Re: 4GL style (was Re: Is this a bug w/ 4GL 4.10) ->Cc: inc@hermes1.sps.mot.com -> ->Alan, -> ->i have never written a line of cobol, and never plan to. but i do write ->"narrow" code. my reasoning, lets say i write a sql statement in 'wide ->code format' for a user. the user agrees that the information is correct, ->but would like to see column b after column c. 'wide code' dictates that ->i have to locate the column in the column list and then delete it and the ->retype it. the 'narrow code' style allows for a cut-and-paste (3 keystrokes ->in vi). ... I actually use a "middle" width for coding non-trivial SELECTs: SELECT a, b, c, This helps, but does not solve, the editing problem. d, e, f, My main objection to the narrow code is that it can g, h, i be VERY hard to read large SQLs in a 20-to-30 line FROM ... window, because you can't see the whole thing at once. I understand your point about the ease of editing. '/column-name' gets vi to the right place in either narrow or wide style. Yes, 'ddp' is nice for rearranging single lines in vi. '2dw2wP' is three more key strokes, but does the same function for comma separated words. Now, move two adjacent columns two places: '2dd2jp' vs. '4dw4wP'. (Ahh, the wonders of editor arcana!) Interestly enough, I tend to segue into the "narrow" style when I have table qualifiers, long column names, column aliases on the column names (in ISQL, not much used in 4GL), substrings, or aggregate functions. Thus, I write: SELECT tab1.long_column_name, and SELECT a, b, c obscure_name[5,9] clear_heading, sum ( prices ) total_cost Again, sort of a middle width. Also notice my idiosyncratic style for '()'. Pascal style would be 'sum(prices)', C style often is 'sum( prices )'. Oh, well, you can't please everyone; sometimes hardly anyone. -> ... for the same reason, i advocate putting the AND/OR's in the where ->clause as: -> . . . ->WHERE condition1 WHERE condition1 AND -> AND condition2 vs. condition2 AND -> AND condition3 condition3 -> ->in this case, what if you want to remove conditions 2 and 3. not only do ->you have to delete the 2 lines, you have to remove the AND. extra keystrokes. -> Not guilty! I also use the left style, even had it in my example, tho' it was not obvious. I like to see each line start with a keyword if possible. An interesting counter-argument is that, if you accidentally leave off or delete the third line, the compiler will find the error in the right style, but not in the left. No help either way if the second line gets deleted. ->ideally, programmers would code in whatever manner they wish and run their ->code through a 'pretty-printer' prior to launching it into production. -> Agreed, in principle. But some 'pretty-printers' produce pig-ugly code. Remember TIDY from Fortran days? This has (probably) been more time than this topic was really worth. In reality, the only reason for worrying about style is to facilitate under- standing and ease maintenance of someone else's, or even your own, code. Throw-away stuff doesn't need style, or the time it takes; it just has to compile. ->regards, -> ->------------------------------------------------------------------------------ -> | . . -> Bob Baskett | ... ... -> Software Engineer, DBA | ..... ..... -> Business Systems Integration Group | .. ... .. -> Semiconductor Products Sector | . . . -> Mesa, AZ | -> | Motorola, Inc ->------------------------------------------------------------------------------ Regards, Alan ___________________________ ______________________| R. Alan Popiel |__________________________ \\ Internet: | Martin Marietta, Tech Ops | / \\ alan@den.mmc.com | P.O. Box 179, M/S 5422 | Std disclaimers apply. / )Voice: | Denver, CO 80201-0179 USA | ( / 303-977-9998 |___________________________| (But you knew that!) \\ /________________________) (____________________________\\