• John Mitchell-245523 (1/21/2015)


    Well off-topic now, but I think I can guess. I use ANSI compliant where it's the only distinguishing feature between two alternatives. For example, CURRENT_TIMESTAMP and GETDATE() both evaluate to the same thing, so I use the former because it's ANSI compliant. If something proprietary works better than something ANSI, I have no qualms about using it. I don't write code on the off-chance that I may one day want to put it on an Oracle server.

    +1000. I don't believe in crippling capabilities for the sake of the mythical transparent migration. As soon as you create a variable, your code is suddenly no longer 100% portable nor even easily portable.

    As for underscores and Pascal (is that the the same as camel?), I think I prefer camel - I think it's more pleasing on the eye and it makes for ever so slightly shorter object names. It doesn't bother me if research has been done that says that underscore names are easier to read - I use what suits me.

    John

    Me too! And I disagree with the research about underscores making things more readable especially in the midst of complex formulas.

    Since a lot of people confuse Camel Case and Pascal Case and Camel Case does actually have more than one form (according to some http://en.wikipedia.org/wiki/CamelCase), lets say specifically that I really like it where every word in an object name starts with a capital letter and that certain abbreviations are always upper case (ID for example). I'll also say that all else considered and that even Microsoft doesn't appear to have a standard in either their objects or code, I won't but anyone's chops during a code review for if they prefer that same thing but with a lower case first letter (front end developers love that form) in their code but I want things like column names, table names, and names of other objects to follow the "first letter of every word rule" and, for the sake of consistency, to not generally use underscores except where certain exceptions have been laid out by project for purposes of grouping by name (and no... it's not Hungarian Notation). I won't tolerate all lower or upper case at all unless it pops up on Intelli_Sense. Like I said, MS has no naming convention to speak of.

    But I do absolutely insist on other things to make all code look the same. All caps for SQL "words", lower case aliases, short lower case schema names, etc, etc.

    As for underscores, I also hate typing the damned things and I hate Intelli-Sense. Try typing t.N and see what it comes up with. Try typing INT and see what it comes up with. Try typing ID and see what it comes up with. BLEAH! There's also a practical reason why I don't care for them. As a DBA, I will many times do searches for objects in sys.SQL_Modules. The underscore is a single character wild card for LIKE. Yep... I can work around that but don't like it when I have to. I guess the biggest reason I don't like it is because it was used a lot in Oracle because the default for the return of object and column names is all caps and the underscores were bloody well necessary for readability.

    And I really feel sorry for anyone that made their whole database case sensitive. It should only be so in the columns that will contain case sensitive data.

    I don't use CURRENT_TIMESTAMP for the same reasons that I don't use underscores and I don't use unnecessarily long names. I even think that GETDATE() is too long. Neither identify what is actually being returned. If I had my druthers, today's date with no time would be TODAY, today's date with the current time would be NOW, and just the current time would be TIME.

    Unless, of course, there's an existing (non-Hungarian!) convention in place already.

    BWAAA-HAAAA!!!! In the interest of everyone else that we've bored with that subject, I'm going to let that go. 😀

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)