For some reason git won't let me write doc/effective_go.html: reword confusing sentence or even doc/effective_go: reword confusing sentence as the subject line for this CL, but that's not important. The actual CL just rewrites one sentence and adds an option to grep in the associated example. Fixes #15875 Change-Id: Iee159ea751caf4b73eacf3dfc86e29032646373f Reviewed-on: https://go-review.googlesource.com/32110 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Effective Go has references to a function call f(c, req) made by ServeHTTP mixed with f(w, req). c is dropped in favor of w to maintain consistency Fixes #17128 Change-Id: I6746fd115ed5a58971fd24e54024d29d18ead1fa Reviewed-on: https://go-review.googlesource.com/29311 Reviewed-by: Rob Pike <r@golang.org>
New Gophers sometimes misconstrue the advice in the "Generality" section as "export interfaces instead of implementations" and add needless interfaces to their code as a result. Down the road, they end up needing to add methods and either break existing callers or have to resort to unpleasant hacks (e.g. using "magic method" type-switches). Weaken the first paragraph of this section to only advise leaving types unexported when they will never need additional methods. Change-Id: I32a1ae44012b5896faf167c02e192398a4dfc0b8 Reviewed-on: https://go-review.googlesource.com/24892 Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
Fixes #14656. Change-Id: I37a9aa51705ae18bd034f2cc6dbf06a55f969197 Reviewed-on: https://go-review.googlesource.com/23202 Reviewed-by: Rob Pike <r@golang.org>
Named returned values should only be used on public funcs and methods when it contributes to the documentation. Named return values should not be used if they're only saving the programmer a few lines of code inside the body of the function, especially if that means there's stutter in the documentation or it was only there so the programmer could use a naked return statement. (Naked returns should not be used except in very small functions) This change is a manual audit & cleanup of public func signatures. Signatures were not changed if: * the func was private (wouldn't be in public godoc) * the documentation referenced it * the named return value was an interesting name. (i.e. it wasn't simply stutter, repeating the name of the type) There should be no changes in behavior. (At least: none intended) Change-Id: I3472ef49619678fe786e5e0994bdf2d9de76d109 Reviewed-on: https://go-review.googlesource.com/20024 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
Fixes #11781 Change-Id: Idc46a6a4fb5bf1c4d394eadf2d860d7ef75c8ccf Reviewed-on: https://go-review.googlesource.com/12390 Reviewed-by: Rob Pike <r@golang.org>
Fixes #11383 Change-Id: I7ef0bb8b535ef513afdfcda19317ae4ff21f7166 Reviewed-on: https://go-review.googlesource.com/11490 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Change-Id: Ib52854169f3dd18f54d3ae9263c897d3f45ea869 Reviewed-on: https://go-review.googlesource.com/10982 Reviewed-by: Andrew Gerrand <adg@golang.org>
In the Slices section of Effective Go, the os package's File.Read function is used as an example. Unfortunately the function signature does not match the function's code in the example, nor the os package's documentation. This change updates the function signature to match the os package and the pre-existing function code. Change-Id: Iae9f30c898d3a1ff8d47558ca104dfb3ff07112c Reviewed-on: https://go-review.googlesource.com/9845 Reviewed-by: Rob Pike <r@golang.org>
When printing the type of the function there was no newline printed in case of unexpected type. Change-Id: I5946413f0864f712a1b955f488b436793018e0e0 Reviewed-on: https://go-review.googlesource.com/7480 Reviewed-by: Minux Ma <minux@golang.org>