I have experimented with distinguishing 'code'/lookup tables from other tables in two different ways: 1) adding text at the beginning of the table name and 2) adding text at the end. The system I liked best was to putting the designation at the end. I inherited a system where lookup tables were 'type' tables and had the text 'Typ' appended to the end. In the example above, it would be CarColorTyp. I've continued that system, though I might have used some other text like 'dd' if I were starting from scratch now.
The nice thing about a suffix as opposed to prefix text is that related tables tend to be next to each other. For example, if I have tables like Car and CarColorTyp and CarEngineTyp, etc, all my 'car' tables would be next to each other in a list. I don't need all my type tables grouped together.
But this begs the question of why make the distinction at all. I could just have Car, CarColor and CarEngine as table names. Here's why I add the suffix: I find the suffix text useful from a human perspective when trying to get the big picture of understanding a database. A distinguished table name very quickly helps me to identify what is going on with that table. I quickly get the function at a glance. It doesn't bother me in the least that there is a subjective/human element to deciding when a table is a 'type'/code/lookup table and when it is a 'main' table. Having the distinction is helpful to me.
Since all my 'typ' tables (with additions when needed) have the exact same columns: code, name, abbreviation and sort order (ex for a PhoneTyp table: phnCd, phnNm, phnAbbr, phnSortOrd), one could easily argue that the 'Typ' suffix is simply not needed. I could look at the structure of the table to understand it. But again, from a human perspective, I get a much quicker understanding of the table by being able to deduce it's purpose from just it's name. I'm looking at a list of table names more often than I'm looking at a data model.
I will say one nice thing about having 'Typ' as the suffix/text rather than something like 'dd' for data dictionary or 'lu' for lookup. The 'typ' text often seems to create meaningful names in an of itself. Take my Phone table example. I can have a Phone table and a PhoneTyp table. I instantly know two things about the PhoneTyp table without having to know anything at all about it's columns (I won't dare call them fields after reading some other comments in other articles ). I know that PhoneTyp is a table that gives me phone types. I don't have to name it say 'PhoneTypLU'. And I know that this table is nothing more than a simple list of phone types. When I need that simple list, I know right where to go. When I need to get to main data, I know I can skip that table.
I think of another reason to have a suffix or prefix, but I can't think of a great specific example right now. Here's the idea anyway: if the lookup tables all have the same text, then it would be much easier to make mass changes to those tables using code. Here is an example of what I am trying to say. Suppose you have a WHOLE bunch of code/type tables configured as I explained above with the same basic 4 columns (with some additional columns when needed). Then your business rules change and you need to add a new column to all your code tables. For example, maybe you need to add a 'Stop Date' column. If all the tables have a unique beginning or ending text, then you can quickly write some code to loop through the tables and add the new column to just the tables you care about. It could save you a lot of work. Admittedly I don't know how often this type of need would arise. I haven't needed it yet--especially since I use ERwin to create my databases. So, changing something like field size for all the 'abbreviation' columns would be easy.