I'd like to add to all the above threads.

I tend to use two characters for table aliases; this generally works, because some tables pop up in almost every query, and you get quite familiar with them. For subqueries and other complex abstractions, I tend to use short words or phrases to make it clear what the subquery's doing.

The specifics are vague and abstract, but there are certain forms or conditions where a (left?) outer join cannot be properly performed using pre-ANSI-92 [ANSI 89, right?] syntax. Exclusively using ANSI-92 avoids ever even having to think about this. (This issue is documented somewhere in BOL.)

For spacing, I always use non-proportional fonts (for any coding job) and spaces for indentation, and that you can cut and paste most anywhere with impunity. I've developed a complex and rigorous code layout convention... but, when it comes right down to it, everyone has their own systems and standards, and getting anyone to agree on anything is about as productive as arguing religeon. Devise something that works for you, get others to use it if you can, adapt those parts of their conventions that make sense, and be prepared to be flexible. (I will say that I'd never add blank lines within a single T_SQL statement, no matter how long. I use blank lines to tell when one (long) statement has ended and the next one has begun.)

Rather than "tit", would "git" be at all appropriate? (From and American who watched loads of Monty Python at a young and impressionable age...)

And you missed "rouding out" the Hitchhiker's Guide / Database analogy. The immortal who'd set about insulting everyone (third book?) showed up early on and insulted Arthur Dent... and then showed up at the end of the book and did it again, only to realize "Wait a minute, didn't I already do you?" implying that his list was corrupt and he'd probably have to start all over again. Dude should have normalized his database...

Philip