In our SQL career, all of us might have come across atleast one T-SQL script,(say a stored procedure), which has too many comments in it. A sample being as below- CREATE PROCEDURE dbo.spTestCode AS BEGIN 4 lines of active code -- 26 line of commented code 18 lines of active code -- 30 lines of commented code 10 lines of active code ...and so on... END While I understand that this approach is done by a developer during initial phases of a release, where in the back of his head, it will seem best to him to just "soft-delete" the existing code by commenting it out while he puts up his new ideas in place, and if by chance anything goes wrong, he can simply restore the original state by commenting his new piece of code and uncommenting the existing code. But over time, when the procedure grows with logic and is finally stable in the production environment, and while it is in maintainence-phase, one fine day another DBA opens this procedure to do some tuning and optimization; it is really annoying to scan through heaps of commented code which are simply not serving any purpose whatsoever. Though I am aware that the SQL engine doesnot process anything which is in comments, my question is, does having too much of commented code **play havoc in any kind**?(apart from the DBA being annoyed ofcourse...) In your opinion, should one get rid of all such blocks of "waste-code" once the purpose of the stored procedure is achieved or should it remain, much to the annoyance for the poor DBA guy - if at all nothing else? Experts - Please advice.
I have seen a situation where HUGE amounts of comments can slow down compile time. I suspect it's SQL Server having to work harder to "ignore" the comments. I believe in commenting code, but comments shouldn't be used for version control, and that's what's going on. Instead, get the code into source control and then you can use that to manage versions and changes and do rollbacks, etc., just like .NET code or anything else.