Mike Frysinger
4042cd6681
This is a port of the existing styleguide.js auto TOC logic from the
HTML guides to the newer markdown guides. Rather than generate the
entire TOC in JS, rely on GH's generator to create, and then process
it slightly with minimal CSS+JS.
While GH's builtin markdown renderer automatically creates sidepanel
TOCs, the GH pages export does not. Use the `* TOC {:toc}` form so
the export automatically generates for us. The downside is that it
also shows up in GH's builtin markdown renderer, but it's only one
line at the top, so it shouldn't be onerous.
The CSS logic tweaks which levels are displayed in the generated
TOC: we hide the single top-level, and omit levels deeper than 2.
The JS logic puts the TOC into a <details> HTML element (internally
called a zippy) so that it's collapsed by default.
While the old auto TOC codebase supported "horizontal" and "vertical"
formats, the new one only supports "vertical". Most of our guides do
not care and take the default since that's what internal & external
markdown renderers use, but notably some are using horizontal still:
* C++, HTML/CSS, Java, JS, TS: external, but not internal
* shell: internal & external (via manual TOC)
We'll leave the shell guide alone, but the rest will be switched over
in the future as we regenerate things, and discuss with respective
maintainers.
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.
- Common Lisp Style Guide
- C++ Style Guide
- C# Style Guide
- Go Style Guide
- Haskell 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
- Verilog Style Guide
- Vim script Style Guide
This project also contains google-c-style.el, an Emacs settings file for 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 use https://github.com/cpplint/cpplint instead.
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:
Since projects are largely maintained in a VCS, writing good commit messages is important to long term project health. Please refer to How to Write a Git Commit Message as an excellent resource. While it explicitly refers to the Git SCM, its principles apply to any system, and many Git conventions are trivial to translate to others.
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.
