Sadly, we don't enforce putting in comments (development team of 22 people, of which 6 are mostly working with T-SQL). But we have all agreed to doing it and most actually do so...
@Jeff, your audience must be on a more advanced level than mine here. I usually have to explain even the concept of a common table expression: "It's almost like a temporary view". But at least on one point we are in full compliance: in-code comments should (and will) explain all that is beyond the most obvious. So I always add them wherever needed, AND keep them up-to-date when changing the code. Thank you for this conversation (and of course your performance comparison of = ALL).
Since we are on the topic, why aren't CTE's taught more? Once I started using them I found them useful.
As for commented code, do you guys enforce it in your workplace? I was able to use policy management for object naming but didn't find a way to enforce commented code.
It's great to say in theory - "code should always be commented" but how do you practice it?
We "practice" it by making it perfectly clear that it's a part of the job and doing 100% code reviews to enforce it. Doing 100% code reviews is not as difficult as most people would have you believe.
Change is inevitable... Change for the better is not.
Viewing 2 posts - 31 through 31 (of 31 total)