For this months T-SQL Tuesday contribution I want to explain why you should think twice about your comments when writing code. Because you never know where your comments can end up.
Tom Zíka hosts this months T-SQL Tuesday. Tom invites us to write about which quality makes code production grade. Since it is a theme that shows up often in forums and posts.
You can read the original invitation by clicking on this link for the T-SQL Tuesday 156 invitation or on the image below.
In reality, there are many things I could have covered in this post. For example, avoid using SELECT * and GOTO statements.
However, in the invitation Tom added a new rule which he commented out. Which inspired me to write about comments. Because inappropriate comment are not always welcome in production.
Think twice about your comments
I must stress that comments are really vital when writing code. Because it helps others to work with your code if needed.
However, you should think about the content of your comments in your code. For example, using swear words or jokes about the quality of the code.
Your colleagues might think your comments are funny. However, you need to realize that your code can end up anywhere. Even after you have left a company.
For instance, your comments can end up been viewed by clients or members of the public. Especially now that it is common for code to be stored in cloud-based services such as Azure Repos or GitHub.
For example, say I added a comment in the database project in my AzureDevOps-AzureSynapseLinkforSQLServer2022 GitHub repository. Which is a repository that is based on a blog post I wrote about a complete CI/CD experience for Azure Synapse Link for SQL Server 2022.
After adding the comment to the T-SQL code for the ‘Sales.Orders‘ table I decide to delete it.
You can see for yourself that the comment has gone from the latest version of the T-SQL code in the ‘Orders.sql‘ table. However, you can still see the comment in the commit history for the delete as below.
Now imagine if I had put something insulting or sensitive in that comment and then deleted it. It would still be there for people to see in the commit history.
In addition, code stored in cloud-based versions of GitHub can be cached on GitHub servers. Which means that even if I removed the commit history it would still exist.
To resolve this, I would have to contact GitHub support as per the instructions they supply on how to remove sensitive data from a repository.
Final words
I hope my T-SQL Tuesday contribution makes some of you think twice about your comments when writing code.
Good comments can be really useful in production and can help others. However, the wrong comment can be damaging.
Of course, if you have any comments or queries about this post feel free to reach out to me.
Be First to Comment