mirror of
https://github.com/google/styleguide.git
synced 2024-03-22 13:11:43 +08:00
Style guides for Google-originated open-source projects
01e47236c8
456 - Tweak lint to sometimes allow { on line following array initialization.
455 - Recognize more types.
454 - Try a bit harder to detect templated types.
453 - Changed error message wording on build/storage_class to be less ambiguous.
452 - Recognize more types to silence false positives for brace warnings.
451 - <skipped>
450 - <skipped>
449 - Ignore whitespace/tab for Linux Kernel files.
448 - Remove some more false positive lint warnings for int64{n}.
447 - Just one warning message for line length is enough, don't need two.
446 - Allow braced conversions to int16, uint64, etc. per the style guide.
445 - Fixed handling of backslash escapes for checking whether a "//" is quoted.
444 - Reduced dependency on hardcoded .cc extension.
443 - Disable single-arg constructor checks by default, since ClangTidy has the
same check. We could just delete the check entirely, but it's slightly
useful in places that can't run ClangTidy.
442 - Fix matching of macro names in CheckTrailingSemicolon to include digits.
441 - Deleted checks:
- All checks for RValue references.
- Spacing check around boolean &&, because those look like RValue
references.
A huge amount of code and effort were dedicated to tell RValue
references apart from boolean expressions, and to differentiate
allowed versus banned RValue references. But we still get regular
false positives from this one check. Rather than making the check
more complex than what it already is, it seemed safer to just delete
it altogether for now, and have a different process for catching
RValue references.
440 - Add rule to cpplint to throw error on empty if statement bodies without
else clauses. If statement bodies with comments are not considered empty.
439 - Allow spaces before closing brace of namespace block so that namespaces
inside of macro definitions (where the entire macro definition is
indented) are not treated as errors.
438 - cpplint: fix a false positive on `new const int(x)`.
437 - Only check for function length when current line is inside a function.
436 - cpplint: Catch static `std::string` instances as well as those written as
`string`. Previously users would sometimes work around the lint warning by
changing their code to even worse code by adding the "std::" prefix.
435 - cpplint: Be a little smarter about warning on indentation.
434 - cpplint: Remove false positives on some functions returning string const&.
433 - cpplint: improve diagnostics of global/static string objects.
432 - Allow non-const reference parameters for iostream based types.
431 - Better handling of raw strings inside comments.
430 - <noop>
429 - <skipped>
428 - <skipped>
427 - Add support to CHECK_NOTNULL when checking if a member variable is
initialized with itself.
426 - Allow suppressing specific warnings in C headers.
425 - Allow spaces before parens for inline assembly.
424 - Remove lint checks for {EXPECT,ASSERT}_.*_M.
423 - Allow comment lines of more than 80 characters if they contain a single
"word" (without any spaces).
422 - cpplint: Warn on inclusion of C++14 headers.
421 - cpplint: recognize <shared_mutex> as a standard library header.
420 - Add <scoped_allocator> to cpplint's list of C++ standard headers.
419 - Add cpplint check for tr1/ headers. We removed the nanny guards for these
418 - <skipped>
417 - Update the styleguide and cpplint to allow unnamed parameters
416 - Remove the rule explicitly banning non-default move operations.
415 - Remove the check for explicit multi arg constructors
414 - Include clarity of lambda default captures in "pros" section, mention
of capturing `this` and lambdas which escape the current scope in "cons".
Soften the ban on default captures to a preference, with admonition against
using them for capturing `this` or when they will escape the current scope.
This is a fairly straightforward change with a brief inclusion
of 2 problematic cases for implicit capture. As this is the style
guide, I'm not sure how much more detail is appropriate.
413 - Fixed a bug by making regex in CleanseRawStrings match multiple raw strings
on a single line in left-to-right order.
412 - Fixed false positive for classes derived using decltype()
411 - <skipped>
410 - Recognize '1LL<<20' as numeric and don't flag it for spacing.
|
||
|---|---|---|
| cpplint | ||
| docguide | ||
| include | ||
| angularjs-google-style.html | ||
| cppguide.html | ||
| cppguide.xml | ||
| eclipse-cpp-google-style.xml | ||
| eclipse-java-google-style.xml | ||
| google_python_style.vim | ||
| google-c-style.el | ||
| google-r-style.html | ||
| htmlcssguide.xml | ||
| intellij-java-google-style.xml | ||
| javaguide.css | ||
| javaguide.html | ||
| javaguidelink.png | ||
| javascriptguide.xml | ||
| jsoncstyleguide_example_01.png | ||
| jsoncstyleguide_example_02.png | ||
| jsoncstyleguide.html | ||
| jsoncstyleguide.xml | ||
| lispguide.xml | ||
| objcguide.xml | ||
| pyguide.html | ||
| README.md | ||
| Rguide.xml | ||
| shell.xml | ||
| styleguide.css | ||
| styleguide.xsl | ||
| vimscriptfull.xml | ||
| vimscriptguide.xml | ||
| xmlstyle.html | ||
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 holds 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.
Our C++ Style Guide, Objective-C Style Guide, Java Style Guide, Python Style Guide, R Style Guide, Shell Style Guide, HTML/CSS Style Guide, JavaScript Style Guide, AngularJS Style Guide, Common Lisp Style Guide, and Vimscript Style Guide are now available. We have also released 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, our 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.
These style guides 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.
