GETTING STARTED

I’ve heard it said that almost any standard is better than no standard. While I’m not sure I would go that far, I certainly agree with the point that there is no one ‘right way’ to format code. There are differing opinions here, and the important thing to remember is that a formatting standard is there to make the job easier. It shouldn’t be so cumbersome as to slow down development. It shouldn’t be too ‘loose’ or it won’t achieve its goal. While there might be some pain up front, the results of adopting a well thought out formatting standard will be well worth the effort.

What are the results? It is easier for team members to scan and understand each other’s code. This improved comprehension allows for team members to troubleshoot and verify code more easily because complex statements are easily identified, modified, or removed. When code is formatted and consistently applied across the team, development moves more quickly because it is much easier for team members to share the workload and maintain each other’s code.

SOME BASIC FORMATING RULES

· SQL code should be in all lowercase text with underscore delimitation where necessary
Using all lowercase with underscore delimitation allows you to avoid any case alteration by certain database systems. Column names and local variables will stand out from SQL keywords, allowing quicker scanning of code.

· Commas and logical operators (and, or) should begin on a new line
Having commas on the beginning of lines makes it very easy to see when one is missing (one of the more common errors, especially with beginners); beginning logical operations on a new line allow for easy inclusion and removal during testing.

· Statements that begin a clause (select, from, join, etc.) should begin on a new line; separate clauses with a single blank line

This allows a developer to more easily locate and identify the key sections of a statement, even if that statement is very long. Additional clause can also be inserted more easily because each clause is a distinct ‘block’.

· Information within each clause should be indented

Although we won’t get into the war about whether to use tabs or spaces, indentation helps the main sections stand out (see above), again allowing each clause to stand as a separate code block.

Below is a sample select statement using the above guidelines.

select
   e.employee_id
,name_last
,e.ssn
,cb.check_batch_id
,cb.pay_period_id
,pp.date_end period_end_date
,ch.check_header_id
,ch.check_number

from
check_batch cb

inner join
pay_period pp on
cb.pay_period_id = pp.pay_period_id

inner join
check_header ch on
cb.check_batch_id = ch.check_batch_id

inner join
employee e on
ch.employee_id = e.employee_id

where
cb.is_printed = 1
and ch.tax_school_district_withholding != 0

CONCLUSION

While far from a complete specification, the SQL formatting standards above can go a long way towards helping a team function more as a…well, team. Any new standard is going to be more natural for some and more painful for others, depending on coding habits and training. However, as the standard is ingrained and becomes habit, the rewards will become apparent, and will be well worth the effort.

Go to Top | Return to Newsletter Contents