Wrong! There’s a lot in a name. Just ask any expectant parent trying to decide on a name for their child. Names are important, not just for people, but for your layers’ attribute fields!

What is a naming convention for attribute fields?

I think of field names the same way I do about complex words in English: as having a prefix, a root, and a suffix. Even if you’ve never heard the word “acrophobia” before, you might be able to get there by realizing that “acro” is a root that means height (think “acrobat”) and “phobia” is a suffix that means fear – fear of heights!

Prefixes and suffixes in field names help communicate the meaning of your field in a similar way. For example, for binary variables, variables that can only be yes or no (1 or 0), I often use the prefix “is” or the suffix “_flag”. Here are some examples:

• isVeteran or veteran_flag
• isTeachingHospital or teaching_flag

When categorizing a continuous variable such as age, or minutes spent commuting, I tend to use my own personal shorthand of LT, LE, GT, and GE:

• “LT” for less than (e.g., “LT18” means less than age 18)
• “LE” for less than or equal to (e.g., “LE5” means a commute time of 5 minutes or less)
• “GT” for greater than (e.g., “GT60” means a commute time of more than an hour)
• “GE” for greater than or equal to (e.g., “GE65” means age 65 and over)

As you create more and more layers, you’ll undoubtedly come up with your own consistent naming conventions that make sense for your data needs. The key word here is consistent. Lastly, pick camelCaseVariableNames or underscore_variable_names and stick to it. Maybe you do an underscore after some ID number, but camel case for the rest. It’s a personal preference, but consistency is valued!

If you are building a layer that others on your team will use at some point, or that you might use several months from now, do yourself a favor and spend minutes to save hours later on. Good field names also help coworkers get up to speed quickly during collaboration. These types of naming conventions help when layers have dozens or even hundreds of related attributes, and you need to be able to make sure you’re using the right one for the right purpose.

How does this work on a real layer?

In my energy workers employment and wage layer, the prefix is the units of the wage (“h” for hourly or “a” for annual), the root is the value itself (e.g. “median”), and the suffix is the detailed occupational category (Bureau of Labor Statistics’ Standard Occupational Classification, or BLS SOC, for those who really want to know the details). For example, the field called h_median_499081 is the median hourly wage of workers with BLS SOC number 49-9081, which happens to be wind turbine service technicians.

Convey information about the original source

This energy workers employment and wage layer was originally a series of spreadsheets from the Bureau of Labor Statistics, with all kinds of metadata. My field names are a place for me to provide the exact identifier of the occupation classifications, which makes the value my field really is storing unambiguous.

Allow other analysts to work with your layer’s data quickly

Anyone using your layer with any kind of SQL logic will thank you for a consistent naming convention. Consistent field names make it easy for programmers to do systematic data transformations. For example, programmers can drop all of the annual wage fields (if the field name starts with an “a”, then drop), or multiply all hourly wage fields by 40 to get an approximate weekly wage (for all fields that starts with “h”, multiply by 40).

Easily communicate what your fields are with display aliases

I mentioned that my attribute field h_median_499081 is the hourly median wage for wind turbine service technicians. ArcGIS Online allows you to give your fields display aliases to communicate this using natural language. Aliases bring explanations into the layer in a user-friendly way. Aliases are much more accommodating than field names:

• Aliases allow up to 255 characters, enough for a complete phrase describing the field. There’s usually room to spell out acronyms and abbreviations here, so please do so.
• Unlike field names, aliases can contain spaces, special characters, and can begin with numbers.

ArcGIS Online rewards layers that have aliases by using them throughout the whole product

They are visible in the auto-generated legend for the attribute you’re mapping. Here I’m mapping the count of employees who are wind turbine service technicians, attribute field tot_emp_499051. Nobody wants a legend that says “tot_emp_499051” when it can say “wind turbine service technicians” instead:

They are visible in Change Style view. If a layer does not have field aliases, you see the field names. If a layer does have field aliases, you see them when changing the map’s symbology:

In the attribute table view, the aliases appear as your field headers:

And, my favorite, in the fields list (under the Data tab in the Item Details), where you can sort your field names alphanumerically. You can even include a long description for each field with all the gory details. Here, I’ve done this by incorporating the long descriptions that the Bureau of Labor Statistics has for each occupation. Descriptions go that last mile, providing additional details and definitions pertaining to an attribute.

Are you convinced to give your fields aliases? Not yet? Wait until I tell you this: Aliases are preserved when exporting a web layer to a geodatabase!

There are many ways to apply aliases to your layers

• If publishing a web layer from Pro, all aliases on your feature class will be transferred. This also adds aliases permanently to their source file in the geodatabase.
• In ArcGIS Online within the Map Viewer via Configure Pop-up -> Configure Attributes. This is also the place to toggle fields on and off from displaying in your attribute table, changing the order field display in the attribute table, and formatting fields with things like number of decimals and thousands comma separators.
• In ArcGIS Online from the Item Details Page’s Data tab, which is the place to add long field descriptions as well. Long field descriptions allow you to move the data’s documentation closer to the GIS analysts who will be using your layer.
• Using a Feature Service Alias Updater tool written by my colleague Lisa Berry, which I have added to My Favorites in ArcGIS Online since I use it so often! It’s great for doing bulk updates to a layer with dozens of fields.

The initial effort pays off

Next time you publish a layer, help your future self out by constructing consistent field names and descriptive aliases. The payoff is well worth the initial time spent choosing a consistent field naming convention and assigning aliases. Help yourself out so that you don’t have to remember what you were thinking months ago, or constantly refer to a codebook. Help other analysts in your organization who will work with your layer. Help those who will be viewing your maps by making the legend easy to read.

If you share your layer publicly with ArcGIS Online users worldwide, or nominate it to ArcGIS Living Atlas, you will be building trust and credibility in this layer, and in yourself as a professional GIS content creator!