Spelling Traps in IT English

null — always two l's in source code and technical writing:

The rule

• The keyword is null in JavaScript, TypeScript, Java, C#, PHP, Swift, Kotlin — two l's, lowercase
• "nul" with one l is not a valid value in any mainstream language — it will cause a syntax or reference error
• "Nul" (one l, mixed case) is equally wrong in code

When to capitalise:

• null — JavaScript, TypeScript, Java, C#, PHP, Swift, Kotlin, Go (nil), Rust (None)
• NULL — SQL (by convention, SQL keywords are often written in ALL CAPS); also used in C/C++ as a macro constant
• None — Python's equivalent (a capitalised identifier, not a keyword)
• nil — Ruby, Go, Objective-C, Lua
• undefined — JavaScript (separate from null; means "not yet assigned")

In prose and documentation

• When writing about the concept in a sentence, most style guides treat it like a keyword: wrap it in backticks or code formatting: "returns null when not found"
• "null value", "null check", "null pointer", "null reference" — all lowercase in flowing text
• "a null result" / "the value is null" — lowercase as adjective/predicate

Common mistakes in PR reviews and docs:
"Set to nul" ❌ → "Set to null" ✅
"Returns NULL" ❌ (in JS context) → "Returns null" ✅
"value is Null" ❌ → "value is null" ✅ (unless writing about Python's None)

boolean vs. Boolean — primitives vs. wrapper objects:

This is one of the most important capitalization distinctions in TypeScript and Java.

TypeScript / JavaScript:

• boolean (lowercase) — the primitive type; what you almost always want in annotations
  const isActive: boolean = true; ✅
• Boolean (capital B) — the built-in wrapper object class; represents an object, not a primitive
  const wrapped = new Boolean(true); — rarely useful, sometimes confusing
  Using Boolean as a type annotation is valid TypeScript but flags a style warning in most linters: "Use boolean instead of Boolean"
• typeof new Boolean(true) is "object", not "boolean" — a common gotcha

Java:

• boolean — primitive type; stored directly, fast, unboxable: boolean flag = true;
• Boolean — wrapper class (java.lang.Boolean); an object; can be null; required for generics: List<Boolean> flags
• Both are used routinely in Java depending on context

Python:

• bool — the built-in type: x: bool = True
• True / False — the boolean literals (capital T and F — unlike most languages)

Correct usage in documentation:
"The parameter accepts a boolean value" ✅ (TypeScript / JavaScript context)
"The flag is of type Boolean" ✅ (Java context, where wrapper is appropriate)
"accepts a Boolean value" ❌ (TypeScript — should use lowercase when referring to the primitive type keyword)

JavaScript — always capital J and capital S:

This is one of the most frequently misspelled technology names in the industry. The correct form has two capital letters:

Correct: JavaScript
Wrong: "Javascript", "javascript", "JAVASCRIPT", "Java Script", "JS" (abbreviation only, not a substitute)

Why two capitals?

• The name is a compound of two words: "Java" + "Script"
• Both words retain their capitalisation: "Java" (proper noun) + "Script" (start of second word)
• This is called CamelCase / PascalCase for brand names

Origin note:
Created by Brendan Eich at Netscape in 1995. "JavaScript" was the official trademark name registered by Sun Microsystems (later Oracle). The trademark is still held by Oracle, which is why the ECMAScript specification uses "ECMAScript" as the formal standardised name. But in everyday use, "JavaScript" (both capitals) is universal.

More IT brand capitalisations that are frequently wrong:

• GitHub — capital G and capital H (not "Github" or "github")
• TypeScript — capital T and S (not "Typescript")
• WordPress — capital W and P (not "Wordpress")
• iPhone — lowercase i, capital P (this is intentional Apple branding)
• iOS — lowercase i, capital O, uppercase S
• npm — all lowercase (intentional; the registry name is never "NPM" in prose)
• Node.js — with the period (not "NodeJS" or "nodejs" in official contexts)

In copy and documentation: Always match the official capitalisation of product and language names. It signals professionalism and attention to detail.

GitHub — capital G, capital H:

The platform's official name is GitHub — two capital letters. This is the registered trademark used by Microsoft (which acquired GitHub in 2018).

Why people get it wrong:

• "git" (the version control system) is always lowercase — you type git commit, never Git commit
• People carry the lowercase convention over to "GitHub" — but "GitHub" is a brand name, not a git command
• The pattern is: git (tool, lowercase) vs GitHub / GitLab / Gitea (platforms, CamelCase)

Consistent capitalisation across git platforms:

• GitHub — capital G, capital H (Microsoft)
• GitLab — capital G, capital L (GitLab Inc.)
• Gitea — capital G, lowercase e-a (community project)
• Bitbucket — capital B only (Atlassian)

git the tool:

• When referring to the version control system: lowercase "git"
• "Use git to track changes" / "run git status"
• "a git repository", "git history", "git workflow" — all lowercase when referring to the tool

In professional writing:
"See the related issue on Github" ❌ → "See the related issue on GitHub" ✅
"pushed to github" ❌ → "pushed to GitHub" ✅
"the github.com repository" — acceptable in URLs (domains are case-insensitive), but in prose: "the GitHub repository" ✅

frontend / front-end / back-end / backend — evolving conventions:

This is a genuine style variation, not a clear right/wrong spelling. Here's the current consensus:

Current industry trend (2020s):

• frontend (one word) — increasingly standard as noun in tech writing: "a frontend developer", "the frontend team", "built with frontend frameworks"
• backend (one word) — similarly dominant: "backend API", "backend engineer", "backend service"
• Most major style guides, developer blogs (MDN, GitHub blog, Smashing Magazine) now use the one-word forms

Traditional hyphenated forms:

• front-end and back-end — correct as compound adjectives before a noun: "a front-end developer" (modifies "developer")
• Following standard hyphenation rules: compound modifiers before nouns get hyphens
• Still found in formal documentation and some style guides

Two-word forms (less common):

• "front end" and "back end" as nouns: "work on the front end" — grammatically valid but becoming less common in tech

The most important rule: be consistent within your project

• Pick one form and use it everywhere in your codebase documentation, README, and style guide
• Mixing "frontend" and "front-end" in the same document looks unprofessional
• If you have a project-level style guide (like Google Developer Style Guide), follow it

Related terms (same one-word trend):

• fullstack → full-stack → both used; "full-stack developer" still more common
• codebase — one word (standard)
• open source — two words (standard, no hyphen in noun use)