Writers face ongoing challenges with consistent terminology and spelling, especially when juggling multiple projects or referencing varied sources. Choices like "email" versus "e-mail" or "log in" versus "login" often slip through unnoticed in drafts. These inconsistencies can make writing look less polished and may distract readers from the main point. Editorial style sheets help by turning repeated language decisions into clear, checkable rules instead of relying on memory or personal habits. For instance, the Supabase documentation style guide keeps a word list covering spelling, capitalization, product names, and usage conventions, stating directly: "Write email, not e-mail." (Supabase documentation style guide).
Building a Personal Style Sheet
Setting up a personal style sheet as a plain text file offers a practical fix. The file, called style.txt, sits next to your drafts and lists preferred word forms on the left, with variants to flag on the right. For example:
# preferred | variants to flag email | e-mail, E-mail website | web site log in to | login to JavaScript | Javascript, javascript GitHub | Github, github
Each line records a choice about spelling, capitalization, or terminology. Comments start with #, and only words that have caused inconsistency get added. This keeps the file short and focused on your real writing patterns. Supabase's method also separates grammatical roles and technical context, using "sign in," "sign out," and "sign up" as verbs, while hyphenated forms like "sign-in" and "sign-out" are for nouns or adjectives. The guide points out that forms like "login," "log in," "logout," "log out," and logOut should stay as-is when quoting third-party interfaces, code, routes, URL slugs, or command-line syntax. This shows why a style sheet should record context instead of making blanket substitutions (Supabase documentation style guide).
Why Use a Plain Text File?
Keeping the style sheet as a plain text file brings clear benefits. It opens instantly in any editor, works with standard search tools, and stays with your project folder. Unlike notes apps or spreadsheets, a plain file fits easily into coding workflows and can be read by scripts without extra setup. This approach matches independent proofreading advice, which suggests keeping a short list of intentional exceptions—like brand terms or deliberate sentence fragments—since automatic correction can erase technical or authorial intent. In software writing, where product names, commands, and API identifiers need specific capitalization, a style sheet helps automated systems flag deviations for review instead of silently changing facts, names, dates, or numbers (Coursium editorial guidance).
Automating Checks with Python
Manual review for style issues is slow and easy to miss errors. To speed things up, a short Python script called check_style.py reads the style sheet and scans drafts for flagged variants. The script builds a list of (preferred, variant) pairs, then checks each line of the files for matches. It uses regular expressions to match whole words, avoiding false positives inside longer words. Here is the core logic:
import re
import sys
from pathlib import Path
rules = []
for line in Path("style.txt").read_text(encoding="utf-8").splitlines():
line = line.strip()
if not line or line.startswith("#"):
continue
preferred, variants = line.split("|")
for variant in variants.split(","):
rules.append((preferred.strip(), variant.strip()))
for path in sys.argv[1:]:
lines = Path(path).read_text(encoding="utf-8").splitlines()
for number, text in enumerate(lines, start=1):
for preferred, variant in rules:
if re.search(r"\b" + re.escape(variant) + r"\b", text):
print(f"{path}:{number}: '{variant}' -> '{preferred}'")This script uses Python's built-in re module, which supplies the regular-expression tools needed for a lightweight style checker without extra packages. The module supports functions like search, match, fullmatch, findall, finditer, sub, and split. These let the script flag occurrences or make controlled changes. Regular-expression word boundaries, shown as \b, are designed to spot transitions between word and non-word characters, which cuts down on false positives when checking a variant inside a draft (SQATools Python regex tutorial).
Running the script on a folder of drafts gives output showing the file, line number, variant found, and the preferred replacement. For example:
drafts/post.md:1: 'e-mail' -> 'email' drafts/post.md:1: 'web site' -> 'website' drafts/post.md:2: 'Javascript' -> 'JavaScript' drafts/post.md:2: 'Github' -> 'GitHub' drafts/post.md:3: 'login to' -> 'log in to'
Lessons from Using the Script
The script is set to be case-sensitive. This means "E-mail" and "e-mail" count as separate variants, which helps avoid false positives when correct capitalization matters, as with "GitHub." Some rules need context, so phrases like "login to" are flagged only when used incorrectly, while "login" as a noun is still fine. The script does not fix issues automatically; it just points them out, leaving the final call to the writer. Code blocks in drafts might also trigger matches, but these can be skipped if needed. This warning-only setup matches current proofreading advice, which treats consistency checking as a strong use case for automation but keeps mechanical detection separate from editorial judgment. Automated tools can scan long documents for spelling, grammar, punctuation, and terminology inconsistencies, but keeping meaning intact still needs human review. Coursium editorial guidance stresses that "the only real check is reading the edited version against the original yourself, sentence by sentence, not asking the editor to grade its own edit."
Maintaining and Growing the Style Sheet
This approach works best when the style sheet is updated regularly. Whenever you pause over a spelling or term, make a decision, add it to the file, and keep writing. Over time, this habit leads to more consistent drafts and eases the mental load of remembering every style choice. Lightweight consistency tools are now seen as review aids rather than full editors, especially for documents with factual or branded material. Coursium guidance recommends giving explicit style rules, asking a tool to flag issues, and keeping human control over the final wording. It specifically warns that general-purpose systems may change official names, company suffixes, product capitalization, dates, or numbers unless those items are checked against trusted sources.
This workflow fits with other developer tools and code maintenance strategies, as covered in the earlier breakdown of reusable templates and Python refactoring. By combining a personal style sheet and a simple script, writers can bring the same discipline to their prose as they do to their code.
