Internal Change.

PiperOrigin-RevId: 489956630
This commit is contained in:
Gaal Yahas 2022-11-21 15:36:54 +02:00
parent 9d680062ca
commit 228e403052
3 changed files with 26 additions and 25 deletions

View File

@ -823,7 +823,8 @@ func handlePet(...) {
``` ```
Do not attempt to distinguish errors based on their string form. (See Do not attempt to distinguish errors based on their string form. (See
https://google.github.io/styleguide/go/index.html#gotip for more.) [Go Tip #13: Designing Errors for Checking](https://google.github.io/styleguide/go/index.html#gotip)
for more.)
```go ```go
// Bad: // Bad:
@ -1492,11 +1493,11 @@ func (c *Client) Get(url string) (resp *Response, err error)
### Preview ### Preview
Go features a documentation server: Go features a
https://pkg.go.dev/golang.org/x/pkgsite/cmd/pkgsite. It is recommended to [documentation server](https://pkg.go.dev/golang.org/x/pkgsite/cmd/pkgsite). It
preview the documentation your code produces both before and during the code is recommended to preview the documentation your code produces both before and
review process. This helps to validate that the [godoc formatting] is rendered during the code review process. This helps to validate that the
correctly. [godoc formatting] is rendered correctly.
[godoc formatting]: #godoc-formatting [godoc formatting]: #godoc-formatting
@ -2554,8 +2555,8 @@ fails, the user should know where, and why.
**Tip:** Go 1.14 introduced a [`t.Cleanup`] function that can be used to **Tip:** Go 1.14 introduced a [`t.Cleanup`] function that can be used to
register cleanup functions that run when your test completes. The function also register cleanup functions that run when your test completes. The function also
works with test helpers. See works with test helpers. See
https://google.github.io/styleguide/go/index.html#gotip for guidance on [GoTip #4: Cleaning Up Your Tests](https://google.github.io/styleguide/go/index.html#gotip)
simplifying test helpers. for guidance on simplifying test helpers.
The snippet below in a fictional file called `paint_test.go` demonstrates how The snippet below in a fictional file called `paint_test.go` demonstrates how
`(*testing.T).Helper` influences failure reporting in a Go test: `(*testing.T).Helper` influences failure reporting in a Go test:

View File

@ -30,20 +30,19 @@ This document is **not exhaustive** and will grow over time. In cases where
[the core style guide](guide) contradicts the advice given here, **the style [the core style guide](guide) contradicts the advice given here, **the style
guide takes precedence**, and this document should be updated accordingly. guide takes precedence**, and this document should be updated accordingly.
See https://google.github.io/styleguide/go#about for the full set of Go Style See [the Overview](https://google.github.io/styleguide/go#about) for the full
documents. set of Go Style documents.
The following sections have moved from style decisions to another part of the The following sections have moved from style decisions to another part of the
guide: guide:
* **MixedCaps**: see https://google.github.io/styleguide/go/guide#mixed-caps * **MixedCaps**: see [guide#mixed-caps](guide#mixed-caps)
<a id="mixed-caps"></a> <a id="mixed-caps"></a>
* **Formatting**: see https://google.github.io/styleguide/go/guide#formatting * **Formatting**: see [guide#formatting](guide#formatting)
<a id="formatting"></a> <a id="formatting"></a>
* **Line Length**: see * **Line Length**: see [guide#line-length](guide#line-length)
https://google.github.io/styleguide/go/guide#line-length
<a id="line-length"></a> <a id="line-length"></a>
<a id="naming"></a> <a id="naming"></a>
@ -116,7 +115,7 @@ wherever possible for consistency.
<!--#include file="/go/g3doc/style/includes/special-name-exception.md"--> <!--#include file="/go/g3doc/style/includes/special-name-exception.md"-->
See also: https://go.dev/blog/package-names See also: [Go blog post about package names](https://go.dev/blog/package-names).
<a id="receiver-names"></a> <a id="receiver-names"></a>
@ -1494,7 +1493,7 @@ import (
) )
ldb := leveldb.Open("/my/table", &db.Options{ ldb := leveldb.Open("/my/table", &db.Options{
BlockSize int: 1<<16, BlockSize: 1<<16,
ErrorIfDBExists: true, ErrorIfDBExists: true,
// These fields all have their zero values. // These fields all have their zero values.
@ -1517,7 +1516,7 @@ import (
) )
ldb := leveldb.Open("/my/table", &db.Options{ ldb := leveldb.Open("/my/table", &db.Options{
BlockSize int: 1<<16, BlockSize: 1<<16,
ErrorIfDBExists: true, ErrorIfDBExists: true,
}) })
``` ```
@ -2820,7 +2819,7 @@ Exceptions are:
Code using gRPC streaming accesses a context from a `Context()` method in Code using gRPC streaming accesses a context from a `Context()` method in
the generated server type, which implements `grpc.ServerStream`. See the generated server type, which implements `grpc.ServerStream`. See
https://grpc.io/docs/languages/go/generated-code/. [gRPC Generated Code documentation](https://grpc.io/docs/languages/go/generated-code/).
* In entrypoint functions (see below for examples of such functions), use * In entrypoint functions (see below for examples of such functions), use
[`context.Background()`](https://pkg.go.dev/context/#Background). [`context.Background()`](https://pkg.go.dev/context/#Background).
@ -2866,8 +2865,8 @@ and readability review.
Code in the Google codebase that must spawn background operations which can run Code in the Google codebase that must spawn background operations which can run
after the parent context has been cancelled can use an internal package for after the parent context has been cancelled can use an internal package for
detachment. Follow https://github.com/golang/go/issues/40221 for discussions on detachment. Follow [issue #40221](https://github.com/golang/go/issues/40221) for
an open source alternative. discussions on an open source alternative.
Since contexts are immutable, it is fine to pass the same context to multiple Since contexts are immutable, it is fine to pass the same context to multiple
calls that share the same deadline, cancellation signal, credentials, parent calls that share the same deadline, cancellation signal, credentials, parent
@ -3217,7 +3216,7 @@ It is user-configurable and should serve most comparison needs.
[language-defined comparisons]: http://golang.org/ref/spec#Comparison_operators [language-defined comparisons]: http://golang.org/ref/spec#Comparison_operators
[`cmp`]: https://pkg.go.dev/github.com/google/go-cmp/cmp [`cmp`]: https://pkg.go.dev/github.com/google/go-cmp/cmp
[`cmp.Equal`]: https://pkg.go.dev/github.com/google/go-cmp/cmp/cmp#Equal [`cmp.Equal`]: https://pkg.go.dev/github.com/google/go-cmp/cmp#Equal
[`cmp.Diff`]: https://pkg.go.dev/github.com/google/go-cmp/cmp/cmp#Diff [`cmp.Diff`]: https://pkg.go.dev/github.com/google/go-cmp/cmp/cmp#Diff
[`protocmp.Transform`]: https://pkg.go.dev/google.golang.org/protobuf/testing/protocmp#Transform [`protocmp.Transform`]: https://pkg.go.dev/google.golang.org/protobuf/testing/protocmp#Transform
@ -3394,7 +3393,8 @@ See also
The standard Go testing library offers a facility to [define subtests]. This The standard Go testing library offers a facility to [define subtests]. This
allows flexibility in setup and cleanup, controlling parallelism, and test allows flexibility in setup and cleanup, controlling parallelism, and test
filtering. Subtests can be useful (particularly for table-driven tests), but filtering. Subtests can be useful (particularly for table-driven tests), but
using them is not mandatory. See also https://blog.golang.org/subtests. using them is not mandatory. See also the
[Go blog post about subtests](https://blog.golang.org/subtests).
Subtests should not depend on the execution of other cases for success or Subtests should not depend on the execution of other cases for success or
initial state, because subtests are expected to be able to be run individually initial state, because subtests are expected to be able to be run individually

View File

@ -35,12 +35,12 @@ Document | Link | Pr
### Documents ### Documents
1. The **Style Guide** (https://google.github.io/styleguide/go/guide) outlines 1. The **[Style Guide](https://google.github.io/styleguide/go/guide)** outlines
the foundation of Go style at Google. This document is definitive and is the foundation of Go style at Google. This document is definitive and is
used as the basis for the recommendations in Style Decisions and Best used as the basis for the recommendations in Style Decisions and Best
Practices. Practices.
1. **Style Decisions** (https://google.github.io/styleguide/go/decisions) is a 1. **[Style Decisions](https://google.github.io/styleguide/go/decisions)** is a
more verbose document that summarizes decisions on specific style points and more verbose document that summarizes decisions on specific style points and
discusses the reasoning behind the decisions where appropriate. discusses the reasoning behind the decisions where appropriate.
@ -49,7 +49,7 @@ Document | Link | Pr
individual Go programmers at Google should keep up-to-date with this individual Go programmers at Google should keep up-to-date with this
document. document.
1. **Best Practices** (https://google.github.io/styleguide/go/best-practices) 1. **[Best Practices](https://google.github.io/styleguide/go/best-practices)**
documents some of the patterns that have evolved over time that solve common documents some of the patterns that have evolved over time that solve common
problems, read well, and are robust to code maintenance needs. problems, read well, and are robust to code maintenance needs.