This editorial was originally published on Apr 24, 2015. It is being republished as Steve is out of the office.

When I first started to be paid money to write software, I worked on my own. I had to test my own code, decide when it could be deployed, and make the decision to deploy it. I had to notify users, and over time, I had to delay deployments because my mistakes would stop a business from getting work done. Fortunately I didn't cause any serious loss of revenue for a small construction company due to my coding errors.

Later I worked at a large company and was surprised when I finished a piece of work and had to submit to a code review. My boss told me to get two other programmers, at least one a senior level developer, and have them review my code. In those days we reviewed code on paper, with a red pen reminiscent of my school days. The amount of ink expended on my work was a bit overwhelming, but fortunately I recovered and was able to fix most of the issues quickly.

I've talked to a number of developers over the years and it seems that most of them make their own decisions about how ready their work is for deployment. Code reviews seem to be the exception rather than the rule, but I wasn't sure if that was the case for SQL Server professionals. Are we more conservative and formal in our approaches? Here's the question this week.

Do you perform code reviews?

Do you review just application code (C#, Java, etc)? Are stored procedures and functions included? Do you include DDL and DML changes in reviews? Are DBAs able to apply changes to production without a second employee checking them?

In many ways, despite the stereotype that DBAs want to be careful with their systems, I've seen many DBAs rashly apply a change to a production server without any oversight or second opinons. It has seemed to me that having the control to decide what changes are made to a SQL Server instance has led to the execution of that power without any oversight for many individuals.

Let us know this week if you review code, and what things matter. I certainly thing naming and structure matter, though I'm willing to let formatting go as many tools these days will reformat code in whatever structure an individual developer prefers.

Join the debate, and respond to today's editorial on the forums

As crazy as it sounds, statistics on temp tables may be reused across multiple executions of the procedure. This is because, as Paul White, writes, “Statistics associated with a cached temporary object are also cached.” Read more in Paul’s article here: click here.

Using temp tables doesn't have to force a recompile on each run. They do support statistics. And they aren't always global... unless you make them global by naming them ##likethis.

» Discuss this question and answer on the forums