Clone this repo:
  1. 75e85d0 csharp: update GH link after branch rename by Kung, Li-Chieh · 18 hours ago gh-pages
  2. 19e30ce objcguide: restore code style to `g` prefix by nickcheng · 3 days ago
  3. 3850022 style.scss: clarify purpose of leading comment block by Mike Frysinger · 3 days ago
  4. e80daa0 Add favicons to guides that lacked them by Sidney San Martín · 8 years ago
  5. dc0c092 docguide: pull in updates from internal docs by Mike Frysinger · 4 days ago

Google Style Guides

Every major open-source project has its own style guide: a set of conventions (sometimes arbitrary) about how to write code for that project. It is much easier to understand a large codebase when all the code in it is in a consistent style.

“Style” covers a lot of ground, from “use camelCase for variable names” to “never use global variables” to “never use exceptions.” This project (google/styleguide) links to the style guidelines we use for Google code. If you are modifying a project that originated at Google, you may be pointed to this page to see the style guides that apply to that project.

This project also contains cpplint, a tool to assist with style guide compliance, and google-c-style.el, an Emacs settings file for Google style.

If your project requires that you create a new XML document format, the XML Document Format Style Guide may be helpful. In addition to actual style rules, it also contains advice on designing your own vs. adapting an existing format, on XML instance document formatting, and on elements vs. attributes.

The style guides in this project are licensed under the CC-By 3.0 License, which encourages you to share these documents. See https://creativecommons.org/licenses/by/3.0/ for more details.

The following Google style guide lives outside of this project:

Contributing

With few exceptions, these style guides are copies of Google's internal style guides to assist developers working on Google owned and originated open source projects. Changes to the style guides are made to the internal style guides first and eventually copied into the versions found here. External contributions are not accepted. Pull requests are regularly closed without comment.

People can file issues using the GitHub tracker. Issues that raise questions, justify changes on technical merits, or point out obvious mistakes may get some engagement and could in theory lead to changes, but we are primarily optimizing for Google's internal needs.