Re: Naming Standards

In article <3305e730.8518859@gate.idg.no>, Nils Myklebust <Nils.Myklebust@idg.no> writes >The issue here however is that of consistency. Every statement should >be written the same way so one allways know how it's done. Otherwise Agreed, that is what pretty printers are for. >Beeing consistent about it of course makes it better than if you had >only done it some of the time. > Agreed. >:>As names are case insensitive in SQL you *always* write them in lower >:>case only of course. >: >:Actually, I use the convention that keywords are in upper-case, program >:variables in I4GL are in lower-case, and database objects are in mixed-case, >:as in the SysTables example. > >This isn't bad, but harder to write. (You also forgot TabId, but of >course the select will work as well anyway. Also informix have to be >spelled the way you do. Here the engine is case sensitive all of a >sudden. This is a very unfortunate situation, and one of the reasons >why mode ANSI databases are so hard to use.) Of course if you start have to swtich between writing 4GL code and Visual Basic connecting to Sybase (as I have) you suddenly find that Sybase IS case-sensitive. I always use 4GL keywords in uppercase and table/column names in lower case. >I don't think upper case keywords adds to readability when you addhear >100% to a good indenting style as you do. I find I prefer it but that's proably because that is what I'm used to and that is what the 4GL manuals use (E.g. INFORMIX-4GL User Guide 4.00 Page 10-24). >When I get automatic color syntax highligting in the editor I use I >will turn on that to achieve a better effect. I don't have one of those. >I dislike mixed upper and lower case in table and column names. First >it implies that these are the names. To the database case is >insignificant. Secondly, and more important, every tool you use that >shows these names from the database will be unable to show them like > >this. I want consistency at all levels to make things easy. > Agreed as above (I had a very frustrating week before I got used to case-sensitivity in a tool). >I would also argue a *little* about indenting and modify your example >from above: >The following two excamples show this: > >Your style: > >select customer.custid, customer.firstname, customer.lastname, > customer.adr1, customer.adr2, customer.zip, customer.state, > invhead.invno, invhead.invdate, invhead.duedate, > invhead.amount, invhead.tax, > invline.invno, invline.lineno, invline.prodcode, > invline.proddescr, invline.quantity, invline.amount, > invline.tax > from customer, invhead, invline > where customer.custid = 1000 > and customer.custid = invhead.custid > and invhead.invno = invline.invno> >My style: > >select customer.custid, customer.firstname, customer.lastname, > customer.adr1, customer.adr2, customer.zip, customer.state, > invhead.invno, invhead.invdate, invhead.duedate, > invhead.amount, invhead.tax, > invline.invno, invline.lineno, invline.prodcode, > invline.proddescr, invline.quantity, invline.amount, invline.tax > from customer, invhead, invline > where customer.custid = 1000 > and customer.custid = invhead.custid > and invhead.invno = invline.invno> >The difference in readability is insignificant. I find it significant. Remember the eye is built for edge detection and when you are checking to see which columns are selected the top version creates a straight line to follow rather the having the eye go down and back. > >The only issue here is to allways indent the same amount (I use 2 and >you use 4 characters wich are both fine). The issue then is where to >start the second line of the select and from clause in your excample. >For good arguments on this I will refere to the book "Code Complete" >from Microsoft Press. A major point however is that in general Page 429 Indent 'routine-call' continuation lines a standard amount. I do, the width of the 'function' name. OK I'm classing select here as a rountine call. Final answer from the book: "It does, however, make the routine name easier to pick out, so which you choose to do is really down to personal perference." Make it easy to find the end of a continutation line. "Another alternative is to put each arhument on a line on its own and indicate the end of the group with a closing parenthesis.... This approach takes up a lot of real estate... In practive only a few routine need to be broken into multiple lines. You cna handle others on one line. Any of the three options for formatting multiple-line routine calls works all right if you use it consistently." The last line follows what I sais above about using a pretty printer. I'd rather have a version control system which had pre and post filters i.e. Checking code out.. If for edit then format he way I like it. If for reading then taje stand out i.e. standard format. Checking code back in... Format the standard way. That way I can see the code in standard format when an error message is received i.e. line number in error messages are meaningful. When I edit code I can handle it in the format I like. >programming, if you indent using your style some indents will be very >deep. This isn't a significant issue in select statements (where the Agreed - helps to aoid deep nesting since lines of code tend to wrap and become hard to manage, >keywords are relatively short), but it's a good idea to follow a >consistent standard in all parts and types of code. > Agreed, >The things that are important, and that you have shown, are of course >the indentation for each new keyword, and starting each new line in >the where clause with a keyword (and/or). I have seen (and even >written) code with the keywords last. That is much less readable. > I tend to put operators (and/or last) as they do not delimit the end of the where clause (i.e. selects have a 'select' part, a 'from' part and a 'where' part each delimited by an uppercase keyword at the start of a line). >When many columns from several tables are involved it is also >mandatory to group tables together in the select part, and start a new >line for every new table. > Agreed. > >:>:Where did Informix come up with a limit of 18 characters >:>:in the first place? >:> >:>I am quite sure the ANSI standard says 18 characters, in which case it >:>would be a very bad idea to use longer names. >: >:Yes, the ANSI standards (SQL86, SQL-89) only guarantee 18 characters. >:SQL-92 requires 18 at the entry level (which is all the Informix claims >:compliance to), and 128 at the Intermediate level. In this detail, >:Informix conforms to the standard a little too closely for comfort. >: >:Yours, >:Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> > > >Nils.Myklebust@idg.no >NM Data AS, P.O.Box 9090 Gronland, N-0133 Oslo, Norway >My opinions