Best Practices for Production Grade Code

Spread the love

In the blog post invite, Tom asks “Which quality makes code production grade?”

I am fond of programming. Most of my time is spent either with TSQL or PowerShell. Even though both of these are vastly different, still there are some common best practices that I follow to produce Production Grade code-

  • Long back, I got introduced to SOLID programming principles. When followed, these rules help you build large/complex projects in the easiest manner. I used these while building SQL Server baselining open source tools like SQLMonitor, SQLDBATools, MetaDataSync, etc.
    • The Single Responsibility Principle
    • The Open-Closed Principle
    • The Liskov Substitution Principle
    • The Interface Segregation Principle
    • The Dependency Inversion Principle
  • Follow a standard for naming objects and identifiers. The Standard being followed could be your own, or you can borrow from others, or books. For example, below is something I use –
    • T-SQL procedure name starting with usp_**
    • All t-sql objects/variables in snake_case_names
    • Local t-sql variable names start with l_******
    • Cursor involved variables names start with c_
    • Similarly, in PowerShell, I prefer to use camelCaseNamingConvention for local variables whereas PascalCaseNamingConvention for parameters
  • Object or Variables names should reflect what they contain/represent.
  • Over-commenting or under-commenting in code makes the code ugly. A right balance between the two is needed.
  • Irrespective of the size of the project, it is important to think about debugging the code. So always implement features for debugging code. For example, in PowerShell, I always implement advanced features like Verbose, Debug & WhatIf
  • For debugging TSQL, I add parameters like Verbose with possible values like 0 {no messages}, 1 {only print messages}, 2 {all messages & table results}.
  • For projects that are suggested to be having a significant impact and users, I sometimes add parameters like LogToTable where I record execution times along with parameter sets for significant portions of the code.
  • I believe that writing complex code does not make us Experienced programmers. Rather, writing simple codes & having knowledge of when to use non-common methods is what makes us experienced programmers.
  • When deviating from simplicity/Obvious in code logic, putting comments about why it was done is important.
  • It’s important to consider the scenario of code failing in the middle flight, and implement TRY/CATCH to handle errors gracefully.
  • If the project does lots of changes, then it’s important to build the tools/project with the capability to only run selective changes or skip selective changes.
  • Last but not least, a code built and tested in a Development/Test environment should not be considered Verified unless tested in Production 🙂

I hope this would helpful for new developers reading this blog post.

Add a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.