Source: https://developers.google.com/style

# About this guide



      Stay organized with collections



      Save and categorize content based on your preferences.

- Home
- Products
- Style


## Page Summary

- This style guide helps you write clear and consistent technical documentation for software developers and other technical practitioners.
- Refer to project-specific guidelines first, then this guide, and finally third-party references like Merriam-Webster or the Chicago Manual of Style for questions.
- While this guide offers recommendations, prioritize clarity and consistency for your specific domain and readers, even if it means deviating from the guidelines.
- For Android or Google Cloud specific guidelines, look for the respective platform logos within the documentation.

This style guide helps you write clear and consistent technical documentation for software developers and other technical practitioners.

Refer to project-specific guidelines first, then this guide, and finally third-party references like Merriam-Webster or the Chicago Manual of Style for questions.

While this guide offers recommendations, prioritize clarity and consistency for your specific domain and readers, even if it means deviating from the guidelines.

For Android or Google Cloud specific guidelines, look for the respective platform logos within the documentation.

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:


Type of question
Third-party reference


Spelling
Follow Merriam-Webster.com.
          See also Spelling.


Nontechnical style
Follow The
          Chicago Manual of Style, 17th edition (subscription required).


Technical style
See the
          Microsoft
          Writing Style Guide. But consider whether Microsoft's guidance applies; some of it
          might apply only to Microsoft products and interfaces.

This style guide. If project-specific style guidelines don't provide explicit
    guidance, then follow this guide.


[Table omitted - see original]

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:

- Apple Style Guide
- Red Hat supplementary style guide for product documentation


## 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

—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.