Repository files navigation

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 mucheasier to understand a large codebase when all the code in it is in a consistentstyle.

“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 styleguidelines we use for Google code. If you are modifying a project thatoriginated at Google, you may be pointed to this page to see the style guidesthat apply to that project.

• AngularJS Style Guide
• Common Lisp Style Guide
• C++ Style Guide
• C# Style Guide
• Go Style Guide
• HTML/CSS Style Guide
• JavaScript Style Guide
• Java Style Guide
• JSON Style Guide
• Markdown Style Guide
• Objective-C Style Guide
• Python Style Guide
• R Style Guide
• Shell Style Guide
• Swift Style Guide
• TypeScript Style Guide
• Vim script Style Guide

This project also containsgoogle-c-style.el, an Emacs settings filefor Google style.

We used to host the cpplint tool, but we stopped making internal updates public.An open source community has forked the project, so users are encouraged to usehttps://github.com/cpplint/cpplint instead.

If your project requires that you create a new XML document format, theXML Document Format Style Guide may be helpful. In addition to actualstyle rules, it also contains advice on designing your own vs. adapting anexisting 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, whichencourages you to share these documents. Seehttps://creativecommons.org/licenses/by/3.0/ for more details.

The following Google style guide lives outside of this project:

• Effective Dart
• Kotlin Style Guide

Since projects are largely maintained in aVCS, writing good commit messagesis important to long term project health. Please refer toHow to Write a GitCommit Message as an excellent resource. While itexplicitly refers to the GitSCM, its principles apply to any system, and manyGit conventions are trivial to translate to others.

With few exceptions, these style guides are copies of Google's internal styleguides to assist developers working on Google owned and originated open sourceprojects. Changes to the style guides are made to the internal style guidesfirst and eventually copied into the versions found here.Externalcontributions are not accepted. Pull requests are regularly closed withoutcomment.

People can fileissues using the GitHub tracker. Issues that raisequestions, justify changes on technical merits, or point out obvious mistakesmay get some engagement and could in theory lead to changes, but we areprimarily optimizing for Google's internal needs.