Best practices with using domains?

[MDB_GIS]

Is there any reason not to use the fully qualified attribute in the 'Code' column as well as the 'Description' column? I have been using numeric codes for a  while now but they are sometimes a bit annoying to deal with. Specifically if I ever export the data. I'm contemplating just converting the field to a text field and using the fully spelled out attribute for both columns. Are there any real reasons not to do this?

[BillFox]

We adopted the practice to keep both sides the same because when the feature class was exported it only held the code numbers which were pretty much useless without the user have a comparably lookup table to join with it.

[MDB_GIS]

This was precisely the issue I ran into. It doesn't happen often because I try to stay away from shapefiles, but it is unavoidable with some of our departments, and it drives me nuts having to decipher the codes. 

[KimOllivier]

Actually you cannot use numeric codes for text fields any more at ArcGISPro in domains.They only allow ranges with digits.

It does half work in ArcMap but the text is always right justified and the widths go wonky.  So even if you want to use digits, for say sorting they have to be character strings. I still hate this because our postal service uses leading zeros. My postcode is "0626" but if Excel get hold of that it morphs into 626 and so on.

Sometimes export tools allow you to choose between the code and description but since I am a programmer the codes will do just fine because you Have to use the code in SQL expressions anyway.

[Bud]

Short codes (just a few letters long) are handy for keeping SQL queries concise and readable.

select
    *
from
   active_transportation
where
    type in ('S','T','PP','MUP',...)

Users in our organization know what those codes mean; the codes aren’t too cryptic.

• Sidewalk
• Trail
• Park Pathway
• Multi-use Path

It’s also easier to remember a short code.

Like you mentioned in the original question, the other option is to use the full description as the code (code and the description are the same).

We have lots of lengthy descriptions with hyphens, brackets, etc. I wouldn’t be able to remember the exact spelling/wording/capitalization of those descriptions when writing SQL queries. So I wouldn’t want to make the codes be the same as the descriptions.

But I do like the simplicity of making the codes the same as the descriptions from a data entry/data integrity perspective. It would avoid the risk of the user entering the description when they should have entered the code (using the field calculator). It’s too bad there isn’t an OOTB way to prevent users from entering non-domain values in ArcGIS, using the field calculator, etc. Prevent non-domain values from being used (across the board, including GP tools)

[Bud]

Related: Use letter instead of integer as subtype field/code