Since many Google projects refer to this site for writing git commit
messages already, or have guidance that is well aligned with it, link
to them rather than write our own document.
Fixes: #336
This is the GH avatar and is slightly different from the icon used on
other Google properties. This makes it easier to distinguish in a big
tab strip.
Fixes: #489
We have not pushed updates to the public cpplint code from our internal
version in years. No one seems interested in picking it up either.
Since an open source community has formed & forked & updated it, let's
delete our ancient version and just send people to that project now.
This update explicitly declares quirks mode to be against the style guide and strengthens the recommendation from “preferred” to “mandatory”. It also updates examples to use lowercase for consistency and clarifies that the style guide applies to Sass.
- Explicitly ban `long double`
- Use absl formatting libraries or `std::ostream` over printf-style
functions.
- Portability: use serialization libraries instead of copying the
in-memory representation.
- Update guidance to use `uintptr_t` (previously `intptr_t`) when
working with pointers as integers.
- Ban C++20 modules.
- Ban coroutines (though this is expected to be temporary).
- Minor wording updates.
The updates chiefly include copy editing, simplifications of code
bodies, explanation of error handling in package initialization,
discussion of zero value declarations, enhancement of initialisms, and
further hardening of goroutine lifetimes and resource leak avoidance.
The file uses UTF-8 encoding, so use UTF-8 directly instead of HTML
entities. This is handled by the export/publish code, but seemed a
bit nicer to split this out into a separate commit for review.
Internally, we've turned down the JS styleguide in favor of a merged
TS/JS guide (with heavy emphasis on TS). That variant doesn't exist
publicly yet, and even then, we probably want to keep around the JS
version as-is more or less indefinitely like we have with the older
ES5 guide. Once we update the TS guide, we can add a deprecation
notice to this file like we do with the ES5 guide.
There is one change that has been left out: the heavy emphasis on
only using clang-format as the rules are heavily geared towards
google3, and there is no external guidance for formatting. If we
could provide public guidance here, it'd be great to update, but
since the guide is no more internally, that seems unlikely, so it's
probably best to freeze the pre-clang-format guidance here.
This text is easy to miss as it's only at the top, and in the same size
and weight as other intro text. If people follow links to sections (as
is the norm for style guides), this will be completely skipped.
Let's make the notice into a sticky butter bar at the top so it's always
shown regardless of where the person is on the page.
Pull in changes:
* improve Egyptian brackets link
* Add a note about JEP421 to #s6.4-finalizers
* Fix broken link in java-style
* Adding special camel case where word begins with number
* Found an unclosed <span> tag
* Change `<a name` anchors to `<a id` anchors
* Improve inclusive language usage
* Reword title sentence about documenting a warning to better reflect the advice that follows it
* Fix an unclosed <a> tag around sort_java_imports
* Clarify guidance on java vs javatests
PiperOrigin-RevId: 648433358
- Give more explicit guidance about when angle bracket includes should
be used.
- Expand the guidance for disallowing const reference parameters that
outlive the call to *all* references, const or mutable; instead, these
parameters should be pointers.
- Add a brief section about how concepts should be named
There are also additional minor formatting changes or updating
recommendations to prefer std over absl.
- Encourage single line nested namespace declarations.
- Reference and allow `constinit` in the relevant sections
- Update operator overloading guidance for comparison operators: prefer
only to overload `==` and optionally `<=>` when there is an obvious
ordering, and allow the compiler to derive the other comparison
operators.
- Discourage prefixing `uint32_t`, et cetera with `std::`.
- Document when and how to use concepts:
- Use `requires` expressions rather than the alternatives, e.g. a
template parameter.
- Do not reimplement existing concepts/traits.
- Do not expose concepts across API boundaries.
- Do not use concepts unnecessarily.
- Do not implement concepts that are not compile-time checkable.
Tony Ruscoe