Uppercase vs. lowercase for keywords

  • This might seem crazy, but I just don't get it. Why does everyone go through the trouble of hitting the shift key for every keystroke on a keyword in T-SQL just so it can be capitalized? Why not just leave keywords lowercase like other languages. Am I missing a benefit of this or something?

    Thanks,

    Vic

  • Back in the old days when we used stone knives and bear skins we didn't have these fancy schmancy text editors ad IDE's that color coded syntax.

    The programmer actually had to consider the next guy that was going to come along and have to mess with his code  (even though there were only like 6 of us programming back then).  And well, there was this common ethic we all had back then about code that was easy to read...

    Bottom line: code is easier to read with key words capitalized (along with all the other niceties of indenting and commenting, etc.)

    (I wonder at times if widespread use of intelisense is going to result in programmers being conditioned to the point that they get stuck on the toilet waiting for their butts to get wiped automatically.)

     

  • OK, but now that we do have color coded editors, can we stop dragging our knuckles, come out of the stone-age and quit holding down the shift key? I've been developing SQL since '88, and I think my code is quite readable with uppercase keywords. Is there another reason? I've still got to be missing something here.

  • Yes, I meant to say "...readable withOUT uppercase keywords.".

  • personally I prefer lower case  too


    * Noel

  • There are situations, where uppercase helps a lot : on forums and in articles (I don't want to copy everything into QA to see it better); in client applications that don't use the color coding and display everything in black (like our IS, which allows to insert pieces of SQL to filter records etc.); if you for some reason want to check the scripts in Notepad - e.g. on a notebook w/o SQLS - or printed. Another thing - in some more complicated queries, containing a subquery, I often write the keywords uppercase in the main query and lowercase in subquery, which (together with indentation) helps to identify the parts. Again, there are places where I can't indent the code in our IS because of how the app is working, and besides, indentation is very easy to "destroy" while editing - lower/upper will stay.

    So, although it is not necessary, I tend to use uppercase in all SQL that I think will be reused. I don't care when I'm writing it ad hoc, and don't plan to save the query at all.

    Vladan

  • The standard mix is by far the most readable - it makes it easy to identify at a glance which bits are which. Are you going to leave out spaces and brackets too, just because they're optional?

     

    Starting with this:

    select blah1,blah2,blah3 from tablename where something=1 and somethingelse=2

     

    I'd change it to this:

    SELECT blah1, blah2, blah3

    FROM tablename

    WHERE (something = 1) AND (somethingelse = 2)

     

    I'm sure you'll agree that that's a lot more readable, n'est pas?

  • Another vote for no caps (this needs a poll). I am a stickler for proper indentation, which in my opinion matters far more than keywords. When code is indented well, it is easy to understand regardless of caps.

  • Back in the old days when we used stone knives and bear skins we didn't have these fancy schmancy text editors ad IDE's that color coded syntax.

    The programmer actually had to consider the next guy that was going to come along and have to mess with his code  (even though there were only like 6 of us programming back then).  And well, there was this common ethic we all had back then about code that was easy to read...

    Bottom line: code is easier to read with key words capitalized (along with all the other niceties of indenting and commenting, etc.)

    (I wonder at times if widespread use of intelisense is going to result in programmers being conditioned to the point that they get stuck on the toilet waiting for their butts to get wiped automatically.)

    I guess that qualifies for the SSC Joe Celko Memorial rant award

    --
    Frank Kalis
    Microsoft SQL Server MVP
    Webmaster: http://www.insidesql.org/blogs
    My blog: http://www.insidesql.org/blogs/frankkalis/[/url]

  • Properly cased and indented code is much easier to read.  Most of my colleagues would agree, as we had this discussion when one of the programmers used lower case.

    Making code easy for most others to maintain is not dragging knuckles, it just makes sense.  This may vary from group to group, but sometimes the way one person wants to do something has to yield to the way most people want to do it, which I say as both the yielder and the one yielded to.

  • What about some classics ?

    http://mindprod.com/unmain.html

    http://www.galisteo.com/gallant/humor/klingon1.htm

    --
    Frank Kalis
    Microsoft SQL Server MVP
    Webmaster: http://www.insidesql.org/blogs
    My blog: http://www.insidesql.org/blogs/frankkalis/[/url]

  • Alright. Thanks for everyone's responses. Yes, I indent, use spaces & brackets, and do the other things necessary to make my code readable by the next guy. I just don't bother capitalizing my keywords, and neither do a few others apparently from reading the posts. If readability is the only issue, I think my code is perfectly fine without having to use my pinky to hold down a darn shift key every other word.

    -Vic

  • No one commented on whether or not they considered datatypes keywords and therefore used uppercase.

    For example:

    DECLARE @FirstName varchar(50)

    vs.

    DECLARE @FirstName VARCHAR(50)

  • They are definitely keywords, and I do not capitalize them either. As far as objects are concerned, I do name them in ProperCase.

  • I'd say that all parts of a T-SQL statement which are not named by the user are "keywords", although that's not a particularly good name for them... perhaps "syntax" would be more accurate. Therefore, I'd go for the latter.

Viewing 15 posts - 1 through 15 (of 22 total)

You must be logged in to reply to this topic. Login to reply