Jargon
Stay organized with collections
Save and categorize content based on your preferences.
Jargon is the specialized and often figurative terminology of a specific group to represent a
larger concept—for example, camel case, swim lane,
break-glass procedure, or out-of-the-box. Jargon can also include
vaguely defined or overloaded terms like solution, support, or
workload.
Typically, the meaning of jargon isn't understood except by the specific group. For this reason,
jargon can hamper our efforts to publish content that's clear, that reaches a
global audience
in multiple languages, that serves readers at various levels of product knowledge, and that's
inclusive of different groups and cultures. For more information about writing with
inclusivity and diversity in mind, see
Write inclusive documentation.
However, some jargon is widely understood and accepted by our industry or by the intended
audience of a document. It can be valuable to include jargon in a document when you know that
readers search for those terms. If you're going to use jargon, consider the following questions:
- Can you write around the term? If you don't need the term for search engine
optimization (SEO), try writing around it. For example, instead of writing Hold a
post-mortem, write When the project is finished, review what processes worked or didn't
work. Instead of writing Create a back-of-the-envelope design, write Use an informal
design process.
- Can you replace the term with a different, more specific term? For example, the
word list
for this style guide offers several replacement terms: affected area or spatial
impact (for blast radius), import or load (for ingest), and
ready-made or pre-built (for off-the-shelf). When a term on the word list is
marked as "Don't use" (some jargon can be considered offensive, violent, or not inclusive),
replace that term or write around it.
- Are you using the term only once in your document? If so, describe the term in plain
language and refer to it in parentheses, or link to a trusted definition.
Recommended: You then move the task to an
earlier part of the process (also known as shifting left).
Recommended: A
split-brain
situation can develop.
- Are you using the term throughout your document? If so, briefly describe the term in
parentheses on first reference, or link to a trusted definition.
Recommended: The application is in the
same state as a cold standby (a backup or redundant system that's identical to a primary
system).
Recommended: A better approach is to use
a pattern called a
dead letter queue.
Is the term used in a command or code sample? If so, use the words only in direct reference to the code items
(formatted as code), and make it clear
what you're referring to.
Recommended: Add a user to the
allowlist (whitelist) by entering the following:
whitelist adduser EMAIL_ADDRESS.
Not recommended: Add a user to the
whitelist by entering the following: whitelist adduser
EMAIL_ADDRESS.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-06-25 UTC.
[null,null,["Last updated 2025-06-25 UTC."],[[["\u003cp\u003eJargon, while common in specific groups, can hinder clear communication, especially for global or diverse audiences.\u003c/p\u003e\n"],["\u003cp\u003eWhen possible, avoid or replace jargon with plain language for better clarity and inclusivity.\u003c/p\u003e\n"],["\u003cp\u003eIf jargon is necessary (e.g., for SEO), define it clearly on first use or link to a trusted definition.\u003c/p\u003e\n"],["\u003cp\u003ePrioritize clear communication over using specialized terminology that may not be widely understood.\u003c/p\u003e\n"]]],["Jargon, specialized terminology understood by specific groups, can hinder clear communication. When using jargon, consider writing around the term if SEO isn't needed, or replacing it with a more specific term. If used, define the term in plain language on the first occurrence, either in parentheses or via a link to a trusted definition. When a word list indicates \"Don't use\", replace it. Jargon can be valuable if searched for by readers, otherwise its use should be minimized or explained.\n"],null,["# Jargon is the specialized and often figurative terminology of a specific group to represent a\nlarger concept---for example, *camel case* , *swim lane* ,\n*break-glass procedure* , or *out-of-the-box* . Jargon can also include\nvaguely defined or overloaded terms like *solution* , *support* , or\n*workload*.\n\nTypically, the meaning of jargon isn't understood except by the specific group. For this reason,\njargon can hamper our efforts to publish content that's clear, that reaches a\n[global audience](/style/translation)\nin multiple languages, that serves readers at various levels of product knowledge, and that's\ninclusive of different groups and cultures. For more information about writing with\ninclusivity and diversity in mind, see\n[Write inclusive documentation](/style/inclusive-documentation).\n\nHowever, some jargon is widely understood and accepted by our industry or by the intended\naudience of a document. It can be valuable to include jargon in a document when you know that\nreaders search for those terms. If you're going to use jargon, consider the following questions:\n\n- **Can you write around the term?** If you don't need the term for search engine optimization (SEO), try writing around it. For example, instead of writing *Hold a\n post-mortem* , write *When the project is finished, review what processes worked or didn't\n work* . Instead of writing *Create a back-of-the-envelope design* , write *Use an informal\n design process*.\n- **Can you replace the term with a different, more specific term?** For example, the [word list](/style/word-list) for this style guide offers several replacement terms: *affected area* or *spatial\n impact* (for *blast radius* ), *import* or *load* (for *ingest* ), and *ready-made* or *pre-built* (for *off-the-shelf*). When a term on the word list is marked as \"Don't use\" (some jargon can be considered offensive, violent, or not inclusive), replace that term or write around it.\n- **Are you using the term only once in your document?** If so, describe the term in plain language and refer to it in parentheses, or link to a trusted definition.\n\n Recommended: You then move the task to an\n earlier part of the process (also known as *shifting left*).\n\n Recommended: A\n [split-brain](https://en.wikipedia.org/wiki/Split-brain_(computing))\n situation can develop.\n- **Are you using the term throughout your document?** If so, briefly describe the term in parentheses on first reference, or link to a trusted definition.\n\n Recommended: The application is in the\n same state as a *cold standby* (a backup or redundant system that's identical to a primary\n system).\n\n Recommended: A better approach is to use\n a pattern called a\n [*dead letter queue*](https://en.wikipedia.org/wiki/Dead_letter_queue).\n- **Is the term used in a command or code sample?** If so, use the words only in direct reference to the code items\n ([formatted as code](/style/code-in-text)), and make it clear\n what you're referring to.\n\n\n Recommended: Add a user to the\n allowlist (`whitelist`) by entering the following:\n `whitelist adduser `\u003cvar translate=\"no\"\u003eEMAIL_ADDRESS\u003c/var\u003e.\n\n\n Not recommended: Add a user to the\n whitelist by entering the following: `whitelist adduser\n `\u003cvar translate=\"no\"\u003eEMAIL_ADDRESS\u003c/var\u003e."]]
