Re: Naming Standards

Johnathan, you are worth picking a "fight" with. Additionally the issue is important enough that it should be discussed. I have suffered from making allmost all possible errors up through times, and still suffer in old code of mine. If anyone can come up with better ideas we can move the world yet another tiny (or perhaps bigger) stepp forward. Elegance in design and programming is one of the more important issues in ataining quality in finished products. Also an important issue in this context is that non of this is a "matter of opinon" or related to "feeling". Every *argument* on these issues, as in every other area of computing (and all other walks of life), can be and have to be backed by reason. (Johnathan have never stated otherwise, so this is for the benefit of others.) You may argue that some small points like the number of characters to indent are arbitrary, and I agree. The reasonable argument then is you can indent using 2 to 4 (or thereabout) characters. Less and you don't see the indent as clearly, more and it takes up to much space and eventually makes the code less clear. Also sometimes you can't find a good reason one way or the other, and have to go by your gut feeling. This *may* also be appropriate, and you may even state such "feelings", but not at the same time claim that you are right and others should do things the same way you do. The only proper reason is to find arguments for or against them. So here goes: Can one do a PS first: All this is written mostly for internal use in my company, but I post it here so others may benefit, and I may get feadback with better ideas. johnl@informix.com (Jonathan Leffler) wrote: :>From: Nils.Myklebust@idg.no (Nils Myklebust) :>Date: Fri, 14 Feb 1997 18:06:01 GMT :>X-Informix-List-Id: <news.33930> :> :>forrey@wsu.edu (Dale Forrey) wrote: :>:We are new to the Informix world and the Data Administrator at our :>:shop is a little frustrated with the 18 character limit on names. :> :>I can see this beeing a problem if you want to port a database that :>already have longer names. :>For new designs it's (mostly) not a problem. Names shouldn't be more :>than 18 characters. One place where it might be a small problem is in :>naming indexes (which incidentally should always be explicitly named :>by you) where the name is always tablename_indexname. With a long :>tablename the indexname part may become a tiny problem. :> :>If you use too long names sql statements become hard to write. :> select a_table_with_a_very_long_name.some_very_long_name, :> another_table_with_a_very_long_name.some_very_long_name :> from a_table_with_a_very_long_name, :> another_table_with_a_very_long_name :> where a_table_with_a_very_long_name.some_very_long_name = :> "Somedata" :> and a_table_with_a_very_long_name.some_very_long_name = :> another_table_with_a_very_long_name.some_very_long_name : :I agree about naming indexes, and that using long names can make SQL :harder to write. : :>You can of course rename the tables locally in the from part, but :>that's a bad practice (for anything but self joins) that makes the :>select harder to read. : :I disagree. I think it is much easier to read the following than the :version above. I think the careful use of case (upper for keywords, lower :or mixed for database objects) helps, too, as does careful indenting. You :can argue about details of the indenting. : :SELECT A.some_very_long_name, : B.some_very_long_name : FROM a_table_with_a_very_long_name A, : another_table_with_a_very_long_name B : WHERE A.some_very_long_name = "Somedata" : AND A.some_very_long_name = B.some_very_long_name I agree in this case on the use of renamed tables (further on case and indentation below). The problem of readability however stems from two issues here: The names are too long so it is hard to read whatever you do (that was the point of the whole select statement). The names aren't real names, so it gets even harder to read. The reason why it's a bad practice to rename tables in the from clause is that you have to constantly refer to the from clause when you read other parts of the statement to find what table is actually refered to. Thus isn't a big deal in small statements, but makes it harder to read large and complex ones. In any kind of programming every part of what you write should be as easy as possible to follow without refering to other parts. Refering to other parts take time and is error prone. ("As easy as possible" obviously means there are strict limits or you end up with even more unreadable code.) A more realistic exsample would be: 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 And with renamed tables: select a.custid, a.firstname, a.lastname, a.adr1, a.adr2, a.zip, a.state, b.invno, b.invdate, b.duedate, b.amount, b.tax, c.invno, c.lineno, c.prodcode, c.proddescr, c.quantity, c.amount, c.tax from customer a, invhead b, invline c where a.custid = 1000 and a.custid = b.custid and b.invno = c.invno This have lost significantly in readability. Of course the following is better: select c.custid, c.firstname, c.lastname, c.adr1, c.adr2, c.zip, c.state, ih.invno, ih.invdate, ih.duedate, ih.amount, ih.tax, il.invno, il.lineno, il.prodcode, il.proddescr, il.quantity, il.amount, il.tax from customer c, invhead ih, invline il where c.custid = 1000 and c.custid = ih.custid and ih.invno = il.invno But it's still not as good as the first one. If you dislike typing this much, the difference is completely insignificant in time. (Anybody who don't touch type fast shouldn't even be in on the discussion until they learn that.) An additional issue with this is that in large databases there tend to be several tables with very similar names. (Appropriately so because they are used for very similar purposes. As an excample we have several invoice header and line tables for different types of inovices for both performance reasons and to avoide too much redundancy.) The exact table that is used is of course very important. In this case it becomes harder to rename tables, and one have to refer to the from clause to find out exactly which one is used. In small select statements these issues aren't a big deal. They become more of an issue in larger ones. The above examples are still relatively small. 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 one have to find out how things are done before one starts