With that said, let’s move onto comments, which provide a simple and effective mechanism for describing what’s going on in the code, making the code easier to understand, review, and troubleshoot. Just be sure you take into account all those niggling little details, such as whether to add a space on either side of a comparison operator, when and how to indent, or where to place commas in the select list. When deciding how to address such issues, you’ll have to weigh each one carefully because there are often good arguments for and against a particularly convention or approach (along with an endless stream of sentiments). To this end, you and your team should take into account a wide range of factors, such as capitalization, indentation, and the judicious use of line breaks. I am merely making the point that all T-SQL should be consistently and carefully formatted so it is readable and understandable by everyone who reviews it. Issues such as capitalization and indentation have been discussed and argued in countless places, with opinions ranging across the spectrum of database developers. The careful use of line breaks, spaces, capitalization, and indentation makes it infinitely easier to review T-SQL code, especially when everyone is following the same standards.īut before we go further-and I get slammed with a horde of comments about the “proper” way to format code-let me make it clear that I am not advocating you follow the formatting I have used here, or any particular formatting styles for that matter. JobTitle DESC, EmpID ASC Ĭertainly it would be a lot easier to review code like this than what we saw in the proceeding examples. Take, for example, the following USE and SELECT statements, which are written in all lowercase, with no line breaks or spaces except where required: The sloppier the formatting, the more difficult it is to decipher and troubleshoot the code. At some point, most code will need to be revisited, and a lot of time can be wasted just trying to understand what is going on, let alone identify potential problems. Readability and other odditiesĪ great number of articles have been written about T-SQL formatting, and for good reason. In the articles to follow, I’ll go deeper into the specifics of defining database objects and querying SQL Server data. The series in not intended as a prescriptive how-to list that dictates what approaches you should take, but rather as a set of guidelines for evaluating the types of issues you should address when coming up with your own approach to T-SQL coding.īecause this is the first article in the series, I focus on general considerations that can apply to your code regardless of the types of T-SQL statements you’re defining, covering such issues as formatting, system functions, deprecated language elements, and user-defined variables. The series will cover such topics as readability, accuracy, performance, standardization, and other factors. To help with this process, this article and the ones to follow will look at various considerations to take into account when trying to formulate T-SQL standards in your organization. In this way, the standards provide a focal point for ironing out differences and working toward a common purpose. Often a good place to start within an organization is to create a set of coding standards that T-SQL developers can help to define and then reference when building their solutions. The trick, of course, is getting consensus on how to achieve that goal. Despite these differences, most would agree that turning out readable and high-performing code is the best solution for everyone. And those opinions can vary far and wide, as evidenced by the multitude of forum postings and heated article comments.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |