T-SQL Context Switching

  • Steve Jones - SSC Editor

    SSC Guru

    Points: 715809

    Comments posted to this topic are about the item T-SQL Context Switching

  • Aaron N. Cutshall

    SSCrazy Eights

    Points: 8715

    I totally agree that what the standards are defined as are not nearly as important as following them. Consistency is King!! We'll, that and good documentation.

  • Rod at work

    SSC-Dedicated

    Points: 33137

    I don't know what to think of this editorial. I do agree that reading others code can be taxing and hard to do. But heck, when I go back to code I wrote a few years ago, I tend to have similar difficulties.

    Coding standards are useful, but in all my years of coding I've only worked on one team that actually sat down to decide on what our coding standards would be. In my experience, it isn't at all easy to get people to agree upon coding standards. What we try to do here is not edit other's code, unless it's absolutely necessary such as when they're on vacation or are sick. I've read my colleagues code, and with only one exception, I haven't any issues with it. The single exception I definitely try not to bother with because his coding patterns bug me. There's nothing objectively wrong with them. I just don't like how he codes.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Eric M Russell

    SSC Guru

    Points: 125018

    I'm willing to tolerate inconsistent naming conventions - so long as the same column is named and typed consistently across tables. Also, I expect the column to be unambiguous in regard to it's purpose. For example, I don't like to see columns with names like 'Delivered', 'Status', or 'DID'. Any of the following as OK - just tell me that the column is related to delivery status and that it's an ID.

    DeliveryStatusID

    Delivery_Status_ID

    deliverystatusid

    delivery_status_id

    DELIVERY_STATUS_ID

     

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Rod at work

    SSC-Dedicated

    Points: 33137

    Eric, your comment made me realize I hadn't even thought of column naming conventions! WOW, how could I have forgotten that!! I'm fairly flexible, although I prefer to use Pascal notation for naming conventions. e.g.: ClientNumber. But I'm OK with client_number or Client_Number. I worked with this one developer who insisted upon only using initials for all column names, then insisting that we maintain a Word document with all of the initials listed, specifying what the initials stood for. I had to argue with her about that, but finally prevailed saying that there was no guarantee that the Word document would always be available.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Eric M Russell

    SSC Guru

    Points: 125018

    Using initials for column names and then having a document at your desk for reference - that is so retro '80s RPG/COBOL.

    I too would recommend implementing the database using a proper PascalCase naming convention. However, just to accommodate this one developer you mention, create a view on each table that renames columns as a 3 or 4 character abbreviations. As for a document mapping abbreviations to column names, they can print out the views and tape them up on their cubicle wall. Of course, they'll eventually give in and just use the tables like everyone else.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • JustMarie

    SSCertifiable

    Points: 7771

    The "organic" nature of database development has caused us to have this in our projects.

    Phase 1 - Inexperienced developers. Poor coding practice. Column names and data types from source data regardless of usage.

    Phase 2 - Additional developers added. New coding practices, previous code not updated. Column names and data types more in line with usage so mismatching between tables.

    Phase 3 - New management added. New coding practices based on manager's preference, previous code not updated. Mismatch of column names and data types continue.

    Phase 4 - Developer turnover. Previous code copied and pasted into new code with developer preferred changes, previous code not updated.

    This is how you end up with a mess. And it's why coding standards are nice but not really going to help unless you start with a good design that's enforced and developers who will adhere to the design and standards.

  • Rod at work

    SSC-Dedicated

    Points: 33137

    Eric M Russell wrote:

    Using initials for column names and then having a document at your desk for reference - that is so retro '80s RPG/COBOL.

    I too would recommend implementing the database using a proper PascalCase naming convention. However, just to accommodate this one developer you mention, create a view on each table that renames columns as a 3 or 4 character abbreviations. As for a document mapping abbreviations to column names, they can print out the views and tape them up on their cubicle wall. Of course, they'll eventually give in and just use the tables like everyone else.

    I like that approach.

    Kindest Regards, Rod Connect with me on LinkedIn.

Viewing 8 posts - 1 through 8 (of 8 total)

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