Best Practices for Production Grade Code

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.