google/styleguide: 17 language guides, no checker

Seventeen guides in mixed file formats, and no command to run

google/styleguide is a documentation repository rather than a program. Its default branch is gh-pages, and the tree carries the layout files a generated site needs, `_config.yml`, `_includes/`, `_sass/` and `assets/`, next to the guides themselves as loose documents. The split runs across formats: `cppguide.html`, `javaguide.html`, `jsguide.html`, `tsguide.html` and `htmlcssguide.html` on one side, `pyguide.md`, `shellguide.md`, `haskellguide.md`, `lispguide.md`, `objcguide.md`, `jsoncguide.md`, `csharp-style.md` and `xmlguide.md` on the other. There is no install step to describe. No package manifest, no dependency file, no binary. A team that wants the Python rules either reads the page at the published homepage, https://google.github.io/styleguide/, or clones the branch and opens `pyguide.md` itself. The only artifact the README links for direct download is `google-c-style.el`, an Emacs settings file served as a raw file from the gh-pages branch, and it belongs to no guide. The repository has no GitHub releases, so there is nothing to install and nothing to pin.

cpplint left the repository and the C++ guide stayed

The C++ guide is still the centrepiece of the tree, and the checker that used to police it is not. The README says the project used to host cpplint, that it stopped making internal updates public, and that an open source community forked the tool, so readers are pointed at https://github.com/cpplint/cpplint instead. That split shapes everything downstream. The prose still sets out naming, formatting and include rules in `cppguide.html`; the part that reported a line number is now a separate download with its own maintainers and its own release history. If your build pins an older copy of cpplint, no file in this repository records which revision of the guide it was last reconciled against, so checker and document separate at a rate you notice only when a fresh warning appears in a pull request. That is the whole difference between the two artifacts. A guide states a preference. A linter states a verdict, and only one of the two can fail your build. One editor artifact from that world did survive in the top level, `eclipse-cpp-google-style.xml`, but that is a formatter profile you import, not a gate you pass.

External pull requests are closed without comment

Contribution policy is the sharpest boundary in the repository. The guides here are, with few exceptions, copies of Google's internal style guides, and changes are made to the internal versions first before being copied into these files. The README states that external contributions are not accepted and that pull requests are regularly closed without comment. The GitHub issue tracker is the only channel left, and the stated bar is narrow: an issue that raises a question, justifies a change on technical merits, or points out an obvious mistake may get some engagement. For a team that finds a rule wrong, the consequence is immediate. You cannot send the correction upstream and expect it to land. Your realistic paths are a fork you maintain yourself or a written variant of your own, and in both cases somebody now owns a document that will never converge with Google's. Nothing in the repository tracks that fork, and nothing warns you when the upstream text moves underneath it.

Dart, Kotlin and Angular are three links that leave the repository

Three guides that people ask for are not in the tree at all. The repository lists Angular Style Guide, Effective Dart and the Kotlin Style Guide as living outside the project, pointing to angular.dev, dartlang.org and developer.android.com respectively. For those three stacks the deliverable is a link, and what sits behind the link is not versioned, dated or mirrored next to the seventeen documents you do get here. A team that copies `cppguide.html` into an internal documentation bundle holds a file it can diff later. A team that links to Effective Dart holds nothing, and this repository gives no signal when the target page changes. The gap is wider for Dart and Kotlin because neither external document is described anywhere in the tree, so nothing here tells you whether the page behind the link covers formatting, API shape or something else entirely. If your stack is one of the three, treat the link as a starting point and copy the text you rely on into a file you control.

Six files change what your tools do, and none of them come with instructions

`pylintrc`, `google_python_style.vim`, `google-c-style.el`, `eclipse-cpp-google-style.xml`, `eclipse-java-google-style.xml` and `intellij-java-google-style.xml` are the files in this repository that change what your editor or your tooling does rather than what you read. The README documents none of them. It does not say which pylint version `pylintrc` was written against or which checks it changes from the defaults, and it does not say whether `google_python_style.vim` belongs in a plugin manager or in a `.vim` directory, or what your Emacs setup needs before `google-c-style.el` loads. For the Emacs file the raw link on the gh-pages branch at least tells you where the bytes live. Past that point you are reading source files with no version statement attached, and a config that quietly disagrees with the guide it came from is worse than no config: code stops matching the prose, and no reviewer can point to the line where the two diverged.

Nothing in the repository can fail your build

Treat the project as an enforcement story and there is nothing inside it. No CI configuration sits in the top level, no linter ships with it, no pre-commit hook is described, and the repository has no GitHub releases to pin a version against. The one enforcement tool it once carried went to a community fork. The consequence is that style becomes a review-time conversation between two people reading prose, and a disagreement about a rule in `pyguide.md` gets settled by whoever reviews the pull request rather than by a consistent answer. The README's own examples of what style covers make the gap concrete. The range runs from "use camelCase for variable names" to "never use global variables" to "never use exceptions". A linter can check the first and must refuse the last, so the rules most likely to start an argument are exactly the ones with no automated form anywhere in this repository. If your requirement is that a bad import order or a stray global fails the build, this project cannot deliver it and never has.

The XML guide is about designing a format, not writing XML

One document in the list answers a different question from the rest. The XML Document Format Style Guide is offered for the case where you are creating a new XML document format, and it carries advice on designing your own format versus adapting an existing one, on instance document formatting, and on the choice between elements and attributes. That is schema design guidance, not a style checklist for XML files you already maintain, and the repository offers no code style guide for XML source to sit beside it. Two further boundaries matter if you plan to adopt the set as your house rules. The first is shape: Markdown lives at `docguide/style.md`, Vim script has both `vimscriptguide.md` and `vimscriptfull.md`, and the C# and Objective-C guides are Markdown files while their C++, Java, JavaScript and TypeScript equivalents are HTML pages, so any pipeline that expects one consistent format across the seventeen documents needs special cases for several languages. The second is history: with no releases and no changelog file in the tree, a reader asking what changed last quarter has the commit log and nothing else.

Editorial conclusion

Use these documents when you maintain code that came out of Google and want its conventions to match the ones Google used. Do not expect enforcement, version pinning, or an upstream that will take your fix. Before you commit, record the commit hash of the guide you copied, because the last push to the gh-pages branch landed on 2026-09-29 and nothing inside the tree tells you which revision your team adopted.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository