Using Case with Keywords and User Defined Names
Another problematic area is the selection of case for various parts of the program. Usually it is considered bad practice to use uppercase letters unless you are trying to make a strong statement about something. Case selection should be included in coding standards documents.
Many programming teams decide to use uppercase letters for keywords, which is how SQL Server documentation is written. For instance,
'SELECT last_name, first_name FROM authors'
clearly emphasizes the fact that SELECT and FROM are keywords and last_name, first_name and authors are identifiers (in this case column and table names). This makes it easy to identify the columns you are retrieving as well as table names as opposed to keywords and functions specific to SQL Server. The opposite technique would work as well: your team could agree on using lower-case characters for keywords and uppercase for everything else: 'select LAST_NAME, FIRST_NAME from AUTHORS'.
Note: If you need to quickly modify a case of the selection to uppercase you can use the combination of Ctrl + Shift + U. To switch back to the lower-case use Ctrl + Shift + L.
Another choice could be capitalizing all keywords: 'Select last_name, first_name From authors', although this style is not as easy to decipher as using all caps for keywords. Some developers prefer using mixed cases with keywords as in 'Select GetDate()', which could be beneficial, but requires the use of the Shift key.
Similar choices are available with user-defined objects. Whichever method you choose, try to differentiate between user-defined names and keywords.
Often the choice of using upper-case and lower-case letters along with underscores comes down to ease of typing. Many programmers like to use lower-case throughout their code without underscores since they don't have to use the Shift key. Again, it makes sense to remind them that their code will have to be maintained and readability is just as important as writing good code.
Whatever standards you decide on, be sure not to spend more time on coming up with the standards than actual programming.