By thinking "relations yield relations", SMV's comments are all the more important (far more so than bickering about case and commas).
When large numbers of "SQL Tables" are joined, good "aliases" help but often aren't enough that a read of the code makes clear what the ultimate predicate is.
What we're calling "derived tables" in SQL are (in a well designed relational database) simply relations themselves, and the end result is simply a relation.
In that case, to use a meaningless (or ordinal) alias is as silly as calling your tables "a, b, and c".
Also by thinking "relations from relations", you can start from tables that are not value relations, and transform them into relations on the fly so that when you get to the tricky joins, you are working with true relations, and have removed all need for outer joins, calls to isnull(r, v), or any other 3VL issues at the later stage. Most modern optimizers recognize that situation and can then apply much better optimization when it can reduce to ordinary 2VL truth tables.
(I have a good example, but I realize that's an article in itself). I like the article, SVL. It demonstrates a certain respect for so-called "subqueries" and "derived tables" that should be at the center of our practice.