About this guide
Stay organized with collections
Save and categorize content based on your preferences.
This style guide provides editorial guidelines for writing clear and consistent technical
documentation for an audience of software developers and other technical practitioners.
If you're new to the guide and looking for introductory topics about our style, then start with
Highlights, Voice and tone, and
Text-formatting summary. Otherwise, use the guide as
a reference document for specific questions. For example, you can look up terms in the
word list.
Editorial resources
We recommend using the following editorial resources.
Reference hierarchy
Use the following references, including this guide, in this order:
- Project-specific style. Follow style guidance specific to your project or product, such
as necessary exceptions to this guide or terms that are relevant only to your product.
This style guide. If project-specific style guidelines don't provide explicit
guidance, then follow this guide.
- Third-party references. If the preceding references don't provide explicit guidance,
then see these third-party references, depending on the nature of your question:
At multiple stages of this hierarchy, it can be helpful to look to established usage. For
example, search your organization's documentation, or check a broad language corpus such
as Google Ngram Viewer.
Other editorial resources
You can use additional resources to research and inform your thinking, but don't consider them
part of Google developer documentation style.
Here are some other style guides from the tech community:
Annotations used in this guide
For guidance that applies only to Android or Google Cloud documentation, look for the following
logos:
-
precedes terms and guidelines specific to Android
documentation.
-
precedes terms and guidelines specific to Google Cloud
documentation.
Break the rules
Break any of these rules sooner than say anything outright barbarous.
—George Orwell,
"Politics and the English Language"
This guide contains guidelines, not rules. Depart from it when doing so improves your
content.
For example, if we recommend spelling a term as one word, and you determine that the
hyphenated version of a term in your domain is more appropriate for your readers, then
it's fine to use that instead. We acknowledge that sometimes there are competing forms
of the same word in wide use, especially as new terms emerge, and you might have good
reasons for departing from our guidance.
When you depart from this guide, be consistent throughout your document.
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-01-15 UTC.
[null,null,["Last updated 2025-01-15 UTC."],[[["\u003cp\u003eThis style guide helps you write clear and consistent technical documentation for software developers and other technical practitioners.\u003c/p\u003e\n"],["\u003cp\u003eRefer to project-specific guidelines first, then this guide, and finally third-party references like Merriam-Webster or the Chicago Manual of Style for questions.\u003c/p\u003e\n"],["\u003cp\u003eWhile this guide offers recommendations, prioritize clarity and consistency for your specific domain and readers, even if it means deviating from the guidelines.\u003c/p\u003e\n"],["\u003cp\u003eFor Android or Google Cloud specific guidelines, look for the respective platform logos within the documentation.\u003c/p\u003e\n"]]],["This guide provides technical documentation style guidelines for software developers. When writing, prioritize project-specific style, then this guide, and lastly, third-party references like Merriam-Webster, the Chicago Manual of Style, and the Microsoft Writing Style Guide. It is recommended to check established usage like existing organizational documentation or Google Ngram Viewer. Android or Google cloud specific guidelines have designated logos. While guidelines are provided, it's permissible to deviate if it improves clarity. However, any chosen deviation should be consistently applied.\n"],null,["# About this guide\n\nThis style guide provides editorial guidelines for writing clear and consistent technical\ndocumentation for an audience of software developers and other technical practitioners.\n\nIf you're new to the guide and looking for introductory topics about our style, then start with\n[Highlights](/style/highlights), [Voice and tone](/style/tone), and\n[Text-formatting summary](/style/text-formatting). Otherwise, use the guide as\na reference document for specific questions. For example, you can look up terms in the\n[word list](/style/word-list).\n\nEditorial resources\n-------------------\n\nWe recommend using the following editorial resources.\n\n### Reference hierarchy\n\nUse the following references, including this guide, in this order:\n\n1. **Project-specific style**. Follow style guidance specific to your project or product, such as necessary exceptions to this guide or terms that are relevant only to your product.\n2. **This style guide**. If project-specific style guidelines don't provide explicit\n guidance, then follow this guide.\n\n3. **Third-party references** . If the preceding references don't provide explicit guidance, then see these third-party references, depending on the nature of your question:\n\n | Type of question | Third-party reference |\n |--------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n | Spelling | Follow [Merriam-Webster.com](https://www.merriam-webster.com/). See also [Spelling](/style/spelling). |\n | Nontechnical style | Follow [*The Chicago Manual of Style*, 17th edition](https://www.chicagomanualofstyle.org/home.html) (subscription required). |\n | Technical style | See the [Microsoft Writing Style Guide](https://docs.microsoft.com/style-guide/welcome/). But consider whether Microsoft's guidance applies; some of it might apply only to Microsoft products and interfaces. |\n\nAt multiple stages of this hierarchy, it can be helpful to look to established usage. For\nexample, search your organization's documentation, or check a broad language corpus such\nas [Google Ngram Viewer](https://books.google.com/ngrams/).\n\n### Other editorial resources\n\nYou can use additional resources to research and inform your thinking, but don't consider them\npart of Google developer documentation style.\n\nHere are some other style guides from the tech community:\n\n- [Apple Style Guide](https://help.apple.com/applestyleguide/)\n- [Red Hat supplementary style guide for product documentation](https://redhat-documentation.github.io/supplementary-style-guide/)\n\nAnnotations used in this guide\n------------------------------\n\nFor guidance that applies only to Android or Google Cloud documentation, look for the following\nlogos:\n\n- precedes terms and guidelines specific to Android documentation.\n- precedes terms and guidelines specific to Google Cloud documentation.\n\nBreak the rules\n---------------\n\n\u003e *Break any of these rules sooner than say anything outright barbarous.*\n\u003e\n\u003e ---George Orwell,\n\u003e \"[Politics and the English Language](https://www.orwellfoundation.com/the-orwell-foundation/orwell/essays-and-other-works/politics-and-the-english-language/)\"\n\nThis guide contains guidelines, not rules. Depart from it when doing so improves your\ncontent.\n\nFor example, if we recommend spelling a term as one word, and you determine that the\nhyphenated version of a term in your domain is more appropriate for your readers, then\nit's fine to use that instead. We acknowledge that sometimes there are competing forms\nof the same word in wide use, especially as new terms emerge, and you might have good\nreasons for departing from our guidance.\n\nWhen you depart from this guide, be consistent throughout your document."]]
