Field naming conventions for clean columns

Nobody deliberates over a field name. You are building a form, you need an input for the person's company, and you type whatever comes to mind. Company. Or company_name. Or field_7.

That name then becomes a column heading, a key in every payload, a reference in every formula, and the thing an integration matches on. It outlives the form, and frequently it outlives the person who chose it.

It is one of the highest-leverage thirty seconds in the whole build, and almost nobody spends it deliberately.

The cost of getting it wrong is never dramatic, which is exactly why it accumulates. Nothing breaks; the sheet simply becomes slightly harder to use every time somebody adds a field, until one day a report takes an afternoon instead of ten minutes and nobody can point at the moment it went wrong.

The good news is that the rules are short and they are the same rules everywhere.

The most important property of a field name is that it does not change. A renamed field is a broken integration, a broken formula and a new column beside the old one.

This argues against names that encode things likely to change. A field called spring_promo_source is wrong by summer. A field called question_about_pricing breaks when the question is reworded.

Name the thing the field holds, not the context it currently sits in. Source, referrer, enquiry_type, budget_range. Those survive redesigns, seasonal campaigns and rewrites of the surrounding copy.

Where a name genuinely must change, treat it as a migration rather than an edit: add the new column, backfill if you can, and retire the old one once nothing references it.

Mixed casing across a form is the most common and least excusable inconsistency, because it costs nothing to avoid and produces columns like firstName next to last_name next to Company.

Lowercase with underscores is the safest default for field names. It survives being used as a key, a column heading, a URL parameter and a variable name in most languages without quoting or escaping.

What you should not do is mix. A sheet whose headings alternate conventions is a sheet where every formula needs checking against the actual spelling, and it reads as careless to anyone you share it with.

If you are joining an existing form, adopt whatever it already uses rather than introducing a second convention alongside the first.

Spaces are the main offender. A field named company name works fine until something serialises it into a URL parameter or a formula reference, at which point it needs quoting everywhere.

Leading and trailing whitespace is worse because it is invisible. A field called company with a trailing space is a different field from company, and you will spend a genuinely unpleasant afternoon working out why a lookup returns nothing.

Avoid punctuation beyond the underscore. Dots, brackets, hashes and slashes all mean something to some system in the chain, and the failure they produce is usually silent rather than loud.

Do not start a name with a digit, and do not rely on case alone to distinguish two fields, since some systems normalise casing and will merge them.

Some names are best avoided because something else in the chain already uses them.

Names beginning with an underscore are frequently used for control fields: our own honeypot field is one, and other services reserve similar prefixes for their own metadata. A visible field called _notes may be stripped or misinterpreted.

Avoid id, name and type as bare field names where you can. They collide with existing attributes and keys in enough places to be worth sidestepping, and enquiry_id or contact_name is barely longer.

And avoid names that duplicate the automatic columns your pipeline adds, such as timestamp, status or source, unless you intend to overwrite them.

The label a visitor reads and the name the field carries are different things, and conflating them causes trouble in both directions.

Labels should be human: What is your budget for this project? Names should be short and stable: budget_range. Using the full question as the field name produces a column heading that is unreadable in a spreadsheet and breaks the moment the wording is improved.

The opposite failure is a form builder that sends only opaque generated identifiers, so your sheet fills with columns like field_1a2b. Where that happens, a mapping step between payload keys and column names is the fix.

The arrangement you want is human labels on the page, stable names in the data, and a header row that a colleague can read without a key.

Grouping by prefix is a small habit that pays off as forms grow. Address fields as address_line1, address_city, address_postcode. Company fields as company_name, company_size.

The benefit is sorting: related columns end up adjacent when anything orders them alphabetically, and a person scanning the header row can see the structure.

It also makes selective handling easy later, when you want to copy the address fields somewhere without listing them individually.

Keep prefixes short. Two levels is plenty, and address_billing_line1_primary is a name nobody will type correctly twice.

Some names are worth adopting because other systems already recognise them.

Campaign parameters are the clearest case. Keeping utm_source, utm_medium and utm_campaign under their standard names means every analytics tool, spreadsheet template and report you ever build already understands them. Renaming them to something you prefer buys nothing and costs compatibility.

The same applies to click identifiers such as gclid, which are matched by name when uploading conversions back to an ad platform.

This is one of the few areas where following a convention you did not choose is strictly better than choosing your own.

A short form for a service business might carry name, email, phone, company, enquiry_type, message, plus utm_source, utm_medium, utm_campaign and gclid captured automatically.

Every name is lowercase, every one describes what it holds rather than where it sits, none contain spaces or punctuation, and the campaign fields use their standard names.

The resulting sheet has a header row somebody can read at a glance, formulas that reference sensible names, and no column called field_7.

That is the entire ambition, and it is achieved by decisions made before the form is published rather than by cleanup afterwards.

If you have inherited a mess, resist a big rename. The cost lands on every downstream reference at once and the benefit is cosmetic.

The pragmatic route is to leave existing fields alone, adopt the convention for anything new, and map the worst offenders to readable column headings at the delivery step so the sheet improves without the form changing.

Then rename properly only when the form is rebuilt, which is the natural moment because everything downstream is being revisited anyway.

A gradual convergence is the version that actually happens; a rename project is the version that gets abandoned halfway and leaves two conventions instead of one.

Lowercase, underscore-separated, descriptive of content rather than context, stable across redesigns, standard where a standard exists.

Five properties, thirty seconds per field, and a spreadsheet that is still pleasant to work in three years from now.

The test for whether it worked is simple. Open the sheet and read the header row as though you had never seen the form. If a colleague could tell you what every column holds without asking, the naming did its job. If two of them need explaining, fix those two now while it is still cheap.

Does the field name have to match the column heading?

Is camelCase acceptable?

Why avoid spaces in field names?

Should I rename badly named fields?

What names should I never use?

Should campaign parameters keep their standard names?

How long should a field name be?

What about fields I might add later?