Is there an advantage of storing shorter names vs longer labels in ArcGIS Survey123?

[EricaNova]

I'm transferring an old MS Access database to Survey123. I'm currently creating choice lists and configuring the survey before I import in the historic data.

I noticed that in the Access database, most of the fields were associated with lookup tables. For example, "m", "f", and "u" were stored in the database instead of "Male", "Female", and "Unknown".  If "Olivia Beatrice Smith" entered the data, she would choose "OBS" from the "data_entered_by" field. 

Is there any reason to keep these codes in Survey123? E.g., having short names and longer labels in my choices sheet in Survey123? Will storing shorter codes make my database take up less size or load faster? Or will it just cause me headaches?

[DougBrowning · Accepted solution]

1000000% stop using codes!  As you said only headaches.  I have been at companies where people are not even sure what the code means anymore.  

I keep the name and label the same at all times if possible.

This is a relic from the data entry days for quick typing and yes some space savings.  But none of that matters really anymore enough to see any difference.

[clt_cabq]

Thank goodness its not numeric codes! There is no good reason any more not to make your database human readable. I guess the only real value i can see is if the investment of time it will take to convert the codes to something English like is significant and too costly for your project. 

[ChristopherCounsell]

Yes, and no. I understand as @DougBrowning said it's a bit of a legacy thing to save data size, performance, etc. 

But you DO need to keep the choice lists clean - no spaces or special characters in the code column. It's a little known requirement of Survey123 that can cause issues for some parts of Survey123 but also when you move it around to other locations e.g. file geodatabase domains.

https://doc.arcgis.com/en/survey123/desktop/create-surveys/quickreferencecreatesurveys.htm#ESRI_SECT...

 So you can't just keep the name and label the same most of the time. But you can keep the choices clean

e.g. "Male" and "Male" are fine. A label of "Olivia Beatrice Smith" should technically be "Olivia_Beatrice_Smith" in the choice name/code. 

Users will see the code if they  export to CSV from a web app. Other times you can use arcade to pick which one is shown or used in calculations.

[DougBrowning]

Spaces have been fine in 123 select one for years now.  Select multiple no, but one is just fine.

[ChristopherCounsell]

Spaces for select one choice names will generally work but it's not best practice. It's fine 99% of the time. When I worked for Esri Aus tech support, every now and then there was an issue tied to this. Users would get frustrated as Survey123 gave warnings everywhere else but not this column, so they felt caught out.

The documentation places a hard limit on multiple choice for spaces and commas. Survey123 Connect will throw an error if you have this. Documentation otherwise recommends you should not use spaces or special characters. So it's more a warning than an error.

There's a lot of things that are OK, until they're not. For example, the 30 character limit on field length is OK in ArcGIS Online but not when you go to enterprise. There wasn't a warning for it in the XLSForm for a long time.

I wouldn't worry about it too much but it's definitely worth highlighting in a discussion about choice names. May as well adopt best practice now.

[EricaNova]

Appreciate the thoughts, Christopher! Can you point me to that documentation? I'd like to read it so I can follow best practice now.

[abureaux]

Agreed.

I always use "short-descriptive-form" for my choice lists. In my mind, a list item name should be:

1. Distinctive. It should be identifiable on its own. E.g., For a list of roof types, EPDM vs 0001. One of these is descriptive, and one is meaningless.
2. Short. I mean this in the context of some list item labels are unnecessarily long for a name. E.g., EPDM vs Ethylene propylene diene monomer rubber. NOTE: I do not mean this in the sense of reducing database size. As others have mentioned, that isn't really a thing any more. HDDs are cheap.
3. Simple. No special characters or spaces. As Doug pointed out, spaces are okay for select_one, but I prefer 1) the ability to seamlessly swap between select_multiple or select_one, and 2) standardize everything on the list page to simplify data entry.

[EricaNova]

Wow! Thanks so much everyone, this is super helpful. I really appreciate it and I know your answers will help other people too. I was having trouble finding a Survey123 specific answer to this question (I saw @DougBrowning alluded to it in another question and I was hoping for more detail). Wish I could mark multiple answers as solutions!