Seems that most developers are still writing code like done in the 90s and have not moved on in naming schemes to what Intellisense allows now. Even though Intellisense has its issues with large scripts.
So things like
SELECT c.name, o.dated, ... FROM Customer c, Orders o
The following is much easier to digest on first encounter:
SELECT customer.name, order.dated, ...
FROM dbo.Customer AS customer
INNER JOIN dbo.Orders AS order
ON order.CustomerID = customer.CustomerID
In a BI / DW environment there can be up to 100 of columns (or more) that transform data from multiple tables. Using full names (whether Hungarian, CamelCase or Pascal) is much easier for beginners to follow. And changing jobs can make everybody pretty much a beginner again.
One of the best phrases I heard and took to heart is: "Code is for humans". As in code should read in a flow like a book, not a bunch of sticky notepads.
Looking at my old code I know I fail in this myself though new stuff gets written with following styling:
* Use " AS " between table and alias
* Use schemas - it is a lot easier to change schemas moving tables and then code will not break if suddenly two tables of with same object but different schema names exist
* Comment the Why?, not the How - business rules included in code are not as easily forgotten than the ones in a Word document
* Explicit alias names for code that is under source control
* Think how much less time I spent if code is clear and explicit instead of shorthand and think of the developers that have to continue and maintain what I started
* Document business requirements for which the code is written