Punctuation in Technical Writing

Option D follows the Conventional Commits format: type(scope): short description. Breaking it down: fix = commit type (fix, feat, docs, refactor, test, chore); (auth) = optional scope; the message is specific and uses the em dash (—) to separate the primary fix from the secondary action. Rules for commit messages: (1) Use imperative mood ("add", "fix", "remove" — not "added", "fixing"); (2) Keep under 72 characters in the subject line; (3) No trailing period; (4) Be specific about what changed and why. The Oxford comma ("token, and log" in C) is correct English but a commit message should be even more concise. Option D wins because it's typed, scoped, and specific.

When however is used as a conjunctive adverb (connecting two independent clauses), the correct punctuation is: semicolon before, comma after — "; however,". The semicolon joins the two independent clauses; the comma after "however" separates it from the rest of the clause. Option A (comma before "however") creates a comma splice — a common error. Option C uses a colon incorrectly (colons introduce lists or explanations, not contrasts). Option D (em dash) is acceptable in informal writing but less standard in technical documentation. Other conjunctive adverbs that follow the same pattern: therefore, consequently, nevertheless, meanwhile, furthermore, moreover. Example: "The tests passed; however, we still need manual verification."

A colon is used to introduce a list, explanation, or elaboration that follows a complete clause. "The API accepts three parameters" is a complete clause, and the list that follows directly explains what those parameters are — a perfect use case for a colon. Rule: what comes before the colon must be a complete sentence on its own. ✅ "The following fields are required: name, email, password." ❌ "The required fields are: name, email, password." (the clause before the colon is incomplete). In technical documentation, colons are common before: lists of parameters, enumerations, definitions, examples, and code blocks. Em dash (option C) could work for emphasis, but a colon is the standard choice here. The Oxford comma before "and active" is correct and mandatory in formal technical writing.

Option B correctly uses paired em dashes to set off a parenthetical phrase ("auth, payments, and notifications") in the middle of a sentence — similar to parentheses but more emphatic. Em dash rules in tech writing: (1) Paired em dashes for interruptions or asides — used without spaces in most style guides; (2) Single trailing em dash to introduce an explanation or afterthought: "The endpoint was deprecated — it had been replaced in v2." Common confusions: hyphen (-) joins compound words or splits multi-part terms ("client-server", "read-only", "45-second build"); en dash (–) shows ranges ("v1–v3", "Monday–Friday", "5–10 requests"); em dash (—) is a strong pause or parenthetical. Option A incorrectly hyphens a time value (no hyphen needed: "took 45 seconds"). Option C incorrectly follows a semicolon with an em dash.

In technical documentation, backtick code formatting (inline code) is the standard for: terminal commands (npm install, git commit), file names and paths (config.yml, src/index.ts), environment variables (NODE_ENV), function or method names (handleClick()), and code values (null, true, 404). This formatting makes it unambiguous that the text is a literal value or command — the reader should type it exactly. Convention by context: UI elements (button labels, menu items) often use bold or quotation marks in UX writing — "Click Save" or 'Click "Save"'. But for anything typed in a terminal or used in code, backtick formatting is universal. In Markdown documentation (README, GitHub, Notion): surround with backticks `like this`. In Word/Google Docs: use a monospace font. In JIRA/Confluence: use inline code blocks.