I've used this myself in the dim and distant past (there is still code in my area of responsibility that shows signs of it).
I find the much better method is to be strict about table names and aliases:
1: Always specify the table name with field names. Even if there is only one table in the query (if the query changes later to draw in data from another table, you don't have to go back and add the table references if they are already there). As well as avoiding name conflicts which will raise errors, it removes certain silent fails that are possible with correlated sub-queries when you don't explicitly note the intended scope by naming the object a column should be found on.
2: Always specify a short but meaningful alias for every object referenced in the query/view (such as "kpi_fact_definition AS kfd"). It makes the code more readable when every column reference has "<table>." prefixed.
2b: All aliases should be unique within the query/view even if the same object is referenced more than once where the scope of each reference means the names/aliases would not conflict. Also try to avoid using aliases that are visually similar (visually similar aliases can lead to typing errors being able to hide in plain view).
3: Make sure that all tables/views have meaningful names, even if they means them looking overly long. You are going to give them short aliases when you use them anyway.
