Spelling for Developers: Words Programmers Get Wrong in Code and Docs

Every web browser in the world sends a header called Referer, and it is spelled wrong. The English word is referrer, with a double r in the middle, but the header was written up with one r missing in the mid-1990s, it went into the HTTP/1.0 specification that way, and there it has stayed. Three decades and some trillions of requests later, it will never be fixed, because fixing it would break the web.

That is the peculiar thing about spelling in code. A typo in an email is forgotten by Friday. A typo in a function name, a database column or a public API can outlive the job you had when you wrote it, the framework you wrote it in, and possibly the company. Every developer who comes after you has to learn the wrong spelling and use it on purpose.

This piece is for developers who would like to stop shipping those. It covers why naming is a spelling problem, the words programmers misspell most, and how word parts make long technical words predictable. Then it deals with the British and American split, what spell-checking tools can and cannot do, and a routine short enough for a commute. Nobody is judging. Most developers stopped being taught spelling at about ten and learned asynchronous by copying it from someone else's code, which is a teaching gap, not a character flaw.

Why naming is a spelling problem

Naming things is famously one of the hard problems in programming. Half of it is choosing the right word. The other half, less discussed, is spelling that word the same way every single time.

A misspelled identifier is a latent bug. If one module defines recieveMessage and another calls receiveMessage, a compiled language fails the build and costs you ten minutes. A dynamic language may let it through until the code path runs, in production, at the least convenient hour of the week.

Spelling also breaks search, and code is searched far more often than it is written. Grep the repository for receive and you will not find recieve. A new teammate who searches the docs for dependency will not find the page someone titled dependancy. Every inconsistent spelling makes a codebase slightly harder to navigate, and the cost compounds quietly.

Then there is the public face of the work. A typo in a README, an error message, a CLI help string or a pull request title is often the first thing a user, a maintainer or a hiring manager sees. Fair or not, people read spelling as a proxy for care. The office version of the same problem is covered in the spelling mistakes that make you look unprofessional at work.

Typos that became permanent

The Referer header is the canonical case. The misspelling appears in RFC 1945, the HTTP/1.0 specification published in 1996, and every later version kept it for compatibility. When a newer header was added to control what browsers send, it was named Referrer-Policy, spelled correctly. So the web now carries both spellings, and you have to know which goes where. In JavaScript, document.referrer is spelled correctly; in PHP, the server variable is HTTP_REFERER. Mix them up and your code does not crash. It quietly reads nothing.

Unix has its own example. The system call that creates a file is creat, with no final e. Ken Thompson, one of Unix's creators, is often quoted as saying that if he were designing Unix again he would spell it with an e. Whatever his exact words, the lesson holds. Names in an interface are forever.

Your own codebase is the same story at a smaller scale. Once a misspelled column is in a production database, other services read it. Once a misspelled field is in a public JSON response, clients depend on it. Renaming means a migration, a deprecation notice and months of supporting both names. Spelling it right the first time is far cheaper.

The words developers misspell most

Tools that scan open-source code for typos, such as the codespell project, maintain long lists of known misspellings, and a few dozen words appear again and again. They fall into recognizable families.

The largest family is doubled letters, because English doubles consonants in places your ear cannot detect.

The second family is vowels you cannot hear. In separate, dependency, existence and definitely, the troublesome vowel sits in an unstressed syllable and has collapsed into a neutral "uh" called a schwa, which gives no clue about its letter. That one sound is behind a remarkable share of adult spelling errors, and schwa, the lazy vowel explains how to beat it.

The third family is plain transpositions, where fingers outrun eyes: lenght, widht, heigth, recieve, retreive, paramter. These are motor slips as much as knowledge gaps, and a linter catches most of them. They still ship.

Beyond those, a set of words turns up in code review with depressing regularity. There is no d in privilege. There is only one h in the middle of threshold. The word queue has four vowels in a row, maintenance is not maintainance, and argument drops the e of argue. Then there are guarantee, compatible, persistent, consistent, environment, initialize, concatenate and truly, each with its own regular misspelling.

And then there are pairs that are both real words, which no checker will flag. The word deprecated means marked for removal, while depreciated means lost value, and belongs in an accounting system, not a changelog. The pairs principal and principle, affect and effect, and lose and loose all get through CI with ease.

How word parts make long words predictable

Long technical words look intimidating, but most are assembled from small, regular parts, and once you see the parts the spelling stops being a guess. Linguists call the study of word parts morphology, and the research on it is encouraging. Peter Bowers and John Kirby found in 2010 that teaching children how words are built improved their vocabulary learning. There is every reason to think the same approach helps adults who work in a vocabulary full of Greek and Latin.

Take asynchronous. It is a (not) plus syn (together) plus chron (time) plus ous. Not at the same time. If you already know chron from cron jobs and chronological, the ch and the y stop being mysteries.

The word dependency is depend plus ency, and it is never dependancy in either American or British English. Likewise, consistent and persistent are consist and persist plus ent. And privilege comes from Latin privus, private, and lex, legis, law: a private law. The leg is the same as in legal, and there is no d anywhere in it.

The word occurrence follows a rule most people were never taught. When a verb ends in one vowel plus one consonant and the stress falls on that final syllable, you double the consonant before adding an ending. You say oc-CUR, so you write occurred and occurrence. The same rule produces committed, referred and controller. It also explains why targeted has one t, since TAR-get is stressed at the front. The full rule, with its exceptions, is in consonant doubling in the middle of words.

Finally, threshold is an oddity worth one sentence: it is not thresh plus hold, and the second element is an old word of uncertain origin, which is exactly why people are tempted to insert a second h. One h, where the parts meet.

License or licence, and the other splits

Distributed teams run into this constantly. In American English, license is both noun and verb. In British English, licence is the noun and license the verb, and practice and practise split the same way.

In software, American spelling wins almost everywhere that is machine-readable. Open-source projects ship a file called LICENSE, package manifests have a license field, and the major licenses spell it that way. So in code, configuration and filenames, use license. In prose documentation, either system is fine as long as you pick one and hold to it.

The same principle covers color and colour, initialize and initialise, canceled and cancelled. Most APIs, standard libraries and web standards use American forms. CSS has a color property and silently ignores colour, although, in a small act of mercy, it accepts both gray and grey as color names. The DOM calls the property cancelable, with one l. For names in code, match the platform; for docs, match your style guide, and if you have no style guide, one line will do: American spelling in code and docs. The full list of differences is in British vs American spelling.

What spell-checking tools can and cannot do

Code-aware spell-checkers are worth installing. codespell checks against a curated list of known misspellings, so it has few false positives. cspell is dictionary-based: it splits camelCase and snake_case identifiers into words and checks each one. Both can run in your editor and in CI, and between them they catch most of the lenght and recieve that would otherwise reach review.

They have limits. Dictionary-based checkers do not know your domain vocabulary, so you will spend some time maintaining an allow list. No checker catches real-word errors: type form where you meant from, or affect where you meant effect, and the tool sees a valid word and moves on. And they only run where you run them. Your Slack messages, your commit messages if you have not configured a hook, your whiteboard and your design docs have no CI.

There is a deeper limit too. A tool that corrects a word does not teach it. You can fix occurence in your editor two hundred times and type it again on the two hundred and first. If you want the typo to stop at the source, the word has to live in your memory, not only in your linter's configuration.

A routine that fits a commute

The fix takes less time than you might think, because memory research offers two reliable shortcuts. Recalling a word strengthens it far more than rereading it; that is retrieval practice, demonstrated in a well-known 2006 study by Henry Roediger and Jeffrey Karpicke. And short sessions spread across days beat one long session; that is the spacing effect, confirmed across hundreds of studies.

A routine built on both:

1. Grep your recent commits, docs and identifiers for your own habitual typos.
2. Put the ten you make most often into a note on your phone.
3. On the commute, have each word read aloud and type it from memory.
4. Check every letter and mark the misses.
5. Repeat the misses the next day and the hits a few days later.

The important part is hearing the word and producing it, rather than reading it. Reading is recognition. Typing from sound is recall, and recall is exactly what you do when you name a variable. Spelling.School is built around that loop: a recorded voice says the word, you type it, and the app marks which letters went wrong and brings the word back just before you would forget it. Any method that makes you produce the word, rather than look at it, will work.

Ten minutes a day for a few weeks is usually enough to retire most of a personal typo list, and words fixed this way tend to stay fixed.

What to do next

Tonight, run git log --oneline | grep -iE "recieve|occured|seperate|lenght|dependancy" against your main repository and see what comes back. Then look at identifiers and docs, not just commit messages. Pick the three words you misspell most and practice them from memory for a week.

If you want a ready-made version of that routine, the five-word demo on the Spelling.School home page needs no sign-up. Either way, spell it right before it becomes an API.

Questions people ask

What are the most misspelled words in programming?

Common ones include occurrence, receive, separate, length, dependency, privilege, committed, successful, threshold and accommodate. Most go wrong because of doubled consonants, unstressed vowels that give no clue to their spelling, or fast typing that swaps two letters. Tools that scan open-source code for typos find the same few dozen words appearing again and again across projects.

Why is referer misspelled in HTTP?

The correct English word is referrer, but the header was spelled referer when it was first written up in the mid-1990s, and that spelling went into the HTTP/1.0 specification, RFC 1945, in 1996. Correcting it later would have broken existing browsers and servers, so it was kept. The newer Referrer-Policy header and the JavaScript property document.referrer are spelled correctly, which means developers have to know both forms.

Does spelling matter in code?

Yes, for practical reasons rather than aesthetic ones. A misspelled identifier can cause bugs when other code uses the correct spelling, and it makes the codebase harder to search, because a search for the right word misses the wrong one. Misspelled names in public APIs and database schemas are expensive to change later, so they often become permanent.

How do I stop misspelling variable names?

Run a code-aware spell-checker such as codespell or cspell in your editor and in continuous integration to catch typos early. Then find the handful of words you misspell most often and practice them from memory for a few minutes a day, hearing each word and typing it before checking. Recall practice spread over a week or two fixes the spelling in memory, so the typo stops at the source.

Is it licence or license in software?

In software, license is the standard spelling in filenames, package metadata and configuration, because most tools and standards use American English. In British English, licence is the noun and license the verb, so British-style prose documentation may reasonably use licence for the noun. Whichever you choose for prose, use it consistently throughout.

Is it dependency or dependancy?

The correct spelling is dependency, with an e. The word is built from depend plus the ending ency, and that spelling is standard in both American and British English. Dependancy is a common misspelling that appears often in code and documentation, and it is worth adding to a spell-checker's watch list if it turns up in your repository.

Fix the words you actually get wrong

A few minutes a day, spaced repetition, built only for spelling. Try five words without signing up.