Death to char(9) in SQL code:

1. Indented code characters will move one space, more than one space (depending on what user preference was) or not at all when inserting/deleting empty “space” in front of a line of SQL code when tabs are used along with spaces. One of those three things happens, and we cannot know which, if there are a combination of spaces and tabs to the left of SQL code when removing or adding to indention. Using tabs along with spaces violates the principle of least surprise.

2. Fact is we will present scripts in any number of tools where we can present text. Does anyone expect otherwise? We all should care about every text presentation tool we might routinely use, including Email, IM, Word Processors, Spreadsheets, et.al. No telling where a script might need including, and including them should be as simple as possible. While that last bit is an opinion, I like to think it so obvious it stands on its own merit.

3. It is a fact that not knowing whether a preceding character is a tab or a space makes using find and replace harder. For instance, replacing all space-comma-space with space-space-comma-space will miss all tab-comma-space. Or can some of you visually distinguish tabs in the editor?

4. The space bar is large; it is conveniently located (under either thumb); it is easy to strike multiple times rapidly. These are ergonomic facts and they are obviously less true for the tab key, which is much smaller, under-left-pinkie and more difficult to push even for a touch typist.

5. Disallowing an additional unseen character means we never have to code to allow for it while searching through or automatically formatting the text of our library of views, stored procedures or functions. This is a fact.

6. Overall, editing and re-editing code with tabs will take longer because of reasons stated in 1-5 above.

Fortunately we can use the tab key to insert spaces instead!