Nowadays i go for the RedGate tool - sql refractor..(she is a costly baby). It works like a charm, but lets talk about doing it manually..The steps given below r d one i followed after visiting Robert Sheldon's page.
Case (Capitalization)
Let’s look at some examples that demonstrate different capitalization strategies. Look at the image below..
make sure to click on the images to view in detail
Object References
When you reference an object such as a table or column, you must decide about such issues as whether to qualify the object name, whether wildcards are permitted, and so on. The following questions provide an outline of the types of details you should take into account when deciding how to reference objects:
•How extensively should you qualify object names? For example, should you always include the schema name with a table even if the schema is dbo? Should you include the database name as well?
•Do different types of code call for different naming strategies? For instance, should you reference objects in a stored procedure differently from how you would reference objects in a data definition language (DDL) statement?
•Is the asterisk (*) wildcard permitted in SELECT lists rather than specifying the column names? Are there circumstances when a wildcard would be permitted? Although most guidelines recommend against using the wildcard in a SELECT list, you cannot assume that everyone follows these guidelines. For this reason, you need to be very specific about these sorts of style decisions.
•Should column names always be specified in INSERT and UPDATE statements? For some of these statements, it’s not necessary to include the column names, but best practices generally recommend that you do include them. As with the use of wildcards in SELECT lists, you should be very specific.
•Is the use of column numbers in place of names permitted in your T-SQL statements? For example, you can use column numbers in the ORDER BY clause when referencing columns in the SELECT list.
Let’s take a look at a few examples that demonstrate some of these issues.
Aliases
Aliases let you assign temporary names to objects (or assign names to computed columns) so they’re easier to work with when writing and reviewing code. Some important points.
•Will you implement a different strategy for different alias types? For example, should table aliases be treated the same as column aliases? Should all column aliases be treated the same, or should computed columns be treated differently from renamed columns?
•What types of alias names are permitted? Can single letters be used for table aliases? Can abbreviations be used for any type of aliases? Should column aliases follow the same naming conventions as those used for object names?
•Should the AS keyword always be used? Never used?
Commas
One of the quickest ways to wreak havoc among T-SQL developers is to start a discussion about how commas should be treated within T-SQL code, particularly in a SELECT list. Even so, a standard should be set, and to do so, you should take into account several factors:
•Should commas be treated differently in different circumstances? For example, should columns in a SELECT list be treated the same as columns in an ORDER BY clause? What about the commas used in a list of parameters?
•For object names that are separated into multiple lines, as is sometimes the case for a SELECT list, should commas end the line or begin the line?
•Should spaces or tabs ever be used before or after the commas?
I prefer the second one.. doing so will make it easy 2 edit the query..
Spacing and Aligning
There are as many ways to lay out your code as there are people developing that code. You should consider number of factors when planning your code’s layout:
•What will the policy be for new lines (linefeeds)? For example, should there be a new line for each clause? Should there be a new line for each clause keyword and a separate line for the arguments to that keyword? For instance, should the FROM clause be on one line and the table name be on the next line?
•What is the maximum number of characters permitted in each line? Should line widths provide for printing the code without adding unplanned line breaks?
•How will you handle clauses that exceed the maximum line width? Should subsequent lines be indented?
•What is the general policy for indentation? For example, in a SELECT statement, should each clause after the SELECT clause be indented? Should arguments to the clause be indented more?
•Will you use spaces or tabs for indentation? If you use spaces, how many spaces per indent?
•How will you handle joins in your queries? Will the JOIN and ON keywords start new lines? Should each clause in a join be on separate lines?
Will continue the rest in the next post...waiting for feedback 4m u guys..
No comments:
Post a Comment