mirror of
https://github.com/golang/go
synced 2024-11-21 16:14:42 -07:00
doc/effective_go: Closed some tags; removed extra spaces.
R=golang-dev, adg CC=golang-dev https://golang.org/cl/6488122
This commit is contained in:
parent
804a43ca76
commit
e93891f348
20
doc/effective_go.html
Normal file → Executable file
20
doc/effective_go.html
Normal file → Executable file
@ -714,6 +714,7 @@ func unhex(c byte) byte {
|
|||||||
<p>
|
<p>
|
||||||
There is no automatic fall through, but cases can be presented
|
There is no automatic fall through, but cases can be presented
|
||||||
in comma-separated lists.
|
in comma-separated lists.
|
||||||
|
</p>
|
||||||
<pre>
|
<pre>
|
||||||
func shouldEscape(c byte) bool {
|
func shouldEscape(c byte) bool {
|
||||||
switch c {
|
switch c {
|
||||||
@ -727,6 +728,7 @@ func shouldEscape(c byte) bool {
|
|||||||
<p>
|
<p>
|
||||||
Here's a comparison routine for byte arrays that uses two
|
Here's a comparison routine for byte arrays that uses two
|
||||||
<code>switch</code> statements:
|
<code>switch</code> statements:
|
||||||
|
</p>
|
||||||
<pre>
|
<pre>
|
||||||
// Compare returns an integer comparing the two byte arrays,
|
// Compare returns an integer comparing the two byte arrays,
|
||||||
// lexicographically.
|
// lexicographically.
|
||||||
@ -1180,6 +1182,7 @@ structure with length 10 and a capacity of 100 pointing at the first
|
|||||||
for more information.)
|
for more information.)
|
||||||
In contrast, <code>new([]int)</code> returns a pointer to a newly allocated, zeroed slice
|
In contrast, <code>new([]int)</code> returns a pointer to a newly allocated, zeroed slice
|
||||||
structure, that is, a pointer to a <code>nil</code> slice value.
|
structure, that is, a pointer to a <code>nil</code> slice value.
|
||||||
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
These examples illustrate the difference between <code>new</code> and
|
These examples illustrate the difference between <code>new</code> and
|
||||||
@ -1330,6 +1333,8 @@ func Append(slice, data[]byte) []byte {
|
|||||||
We must return the slice afterwards because, although <code>Append</code>
|
We must return the slice afterwards because, although <code>Append</code>
|
||||||
can modify the elements of <code>slice</code>, the slice itself (the run-time data
|
can modify the elements of <code>slice</code>, the slice itself (the run-time data
|
||||||
structure holding the pointer, length, and capacity) is passed by value.
|
structure holding the pointer, length, and capacity) is passed by value.
|
||||||
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
The idea of appending to a slice is so useful it's captured by the
|
The idea of appending to a slice is so useful it's captured by the
|
||||||
<code>append</code> built-in function. To understand that function's
|
<code>append</code> built-in function. To understand that function's
|
||||||
@ -1545,6 +1550,7 @@ a space in the format (<code>% x</code>) it puts spaces between the bytes.
|
|||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
Another handy format is <code>%T</code>, which prints the <em>type</em> of a value.
|
Another handy format is <code>%T</code>, which prints the <em>type</em> of a value.
|
||||||
|
</p>
|
||||||
<pre>
|
<pre>
|
||||||
fmt.Printf("%T\n", timeZone)
|
fmt.Printf("%T\n", timeZone)
|
||||||
</pre>
|
</pre>
|
||||||
@ -1606,6 +1612,7 @@ func Println(v ...interface{}) {
|
|||||||
We write <code>...</code> after <code>v</code> in the nested call to <code>Sprintln</code> to tell the
|
We write <code>...</code> after <code>v</code> in the nested call to <code>Sprintln</code> to tell the
|
||||||
compiler to treat <code>v</code> as a list of arguments; otherwise it would just pass
|
compiler to treat <code>v</code> as a list of arguments; otherwise it would just pass
|
||||||
<code>v</code> as a single slice argument.
|
<code>v</code> as a single slice argument.
|
||||||
|
</p>
|
||||||
<p>
|
<p>
|
||||||
There's even more to printing than we've covered here. See the <code>godoc</code> documentation
|
There's even more to printing than we've covered here. See the <code>godoc</code> documentation
|
||||||
for package <code>fmt</code> for the details.
|
for package <code>fmt</code> for the details.
|
||||||
@ -1783,6 +1790,7 @@ func init() {
|
|||||||
<p>
|
<p>
|
||||||
Methods can be defined for any named type that is not a pointer or an interface;
|
Methods can be defined for any named type that is not a pointer or an interface;
|
||||||
the receiver does not have to be a struct.
|
the receiver does not have to be a struct.
|
||||||
|
</p>
|
||||||
<p>
|
<p>
|
||||||
In the discussion of slices above, we wrote an <code>Append</code>
|
In the discussion of slices above, we wrote an <code>Append</code>
|
||||||
function. We can define it as a method on slices instead. To do
|
function. We can define it as a method on slices instead. To do
|
||||||
@ -2012,6 +2020,7 @@ Those methods include the standard <code>Write</code> method, so an
|
|||||||
can be used.
|
can be used.
|
||||||
<code>Request</code> is a struct containing a parsed representation
|
<code>Request</code> is a struct containing a parsed representation
|
||||||
of the request from the client.
|
of the request from the client.
|
||||||
|
</p>
|
||||||
<p>
|
<p>
|
||||||
For brevity, let's ignore POSTs and assume HTTP requests are always
|
For brevity, let's ignore POSTs and assume HTTP requests are always
|
||||||
GETs; that simplification does not affect the way the handlers are
|
GETs; that simplification does not affect the way the handlers are
|
||||||
@ -2034,6 +2043,7 @@ func (ctr *Counter) ServeHTTP(w http.ResponseWriter, req *http.Request) {
|
|||||||
(Keeping with our theme, note how <code>Fprintf</code> can print to an
|
(Keeping with our theme, note how <code>Fprintf</code> can print to an
|
||||||
<code>http.ResponseWriter</code>.)
|
<code>http.ResponseWriter</code>.)
|
||||||
For reference, here's how to attach such a server to a node on the URL tree.
|
For reference, here's how to attach such a server to a node on the URL tree.
|
||||||
|
</p>
|
||||||
<pre>
|
<pre>
|
||||||
import "net/http"
|
import "net/http"
|
||||||
...
|
...
|
||||||
@ -2187,6 +2197,7 @@ what a <code>Reader</code> does <em>and</em> what a <code>Writer</code>
|
|||||||
does; it is a union of the embedded interfaces (which must be disjoint
|
does; it is a union of the embedded interfaces (which must be disjoint
|
||||||
sets of methods).
|
sets of methods).
|
||||||
Only interfaces can be embedded within interfaces.
|
Only interfaces can be embedded within interfaces.
|
||||||
|
</p>
|
||||||
<p>
|
<p>
|
||||||
The same basic idea applies to structs, but with more far-reaching
|
The same basic idea applies to structs, but with more far-reaching
|
||||||
implications. The <code>bufio</code> package has two struct types,
|
implications. The <code>bufio</code> package has two struct types,
|
||||||
@ -2378,10 +2389,11 @@ exits, silently. (The effect is similar to the Unix shell's
|
|||||||
background.)
|
background.)
|
||||||
</p>
|
</p>
|
||||||
<pre>
|
<pre>
|
||||||
go list.Sort() // run list.Sort concurrently; don't wait for it.
|
go list.Sort() // run list.Sort concurrently; don't wait for it.
|
||||||
</pre>
|
</pre>
|
||||||
<p>
|
<p>
|
||||||
A function literal can be handy in a goroutine invocation.
|
A function literal can be handy in a goroutine invocation.
|
||||||
|
</p>
|
||||||
<pre>
|
<pre>
|
||||||
func Announce(message string, delay time.Duration) {
|
func Announce(message string, delay time.Duration) {
|
||||||
go func() {
|
go func() {
|
||||||
@ -2393,6 +2405,7 @@ func Announce(message string, delay time.Duration) {
|
|||||||
<p>
|
<p>
|
||||||
In Go, function literals are closures: the implementation makes
|
In Go, function literals are closures: the implementation makes
|
||||||
sure the variables referred to by the function survive as long as they are active.
|
sure the variables referred to by the function survive as long as they are active.
|
||||||
|
</p>
|
||||||
<p>
|
<p>
|
||||||
These examples aren't too practical because the functions have no way of signaling
|
These examples aren't too practical because the functions have no way of signaling
|
||||||
completion. For that, we need channels.
|
completion. For that, we need channels.
|
||||||
@ -2425,7 +2438,7 @@ c := make(chan int) // Allocate a channel.
|
|||||||
// Start the sort in a goroutine; when it completes, signal on the channel.
|
// Start the sort in a goroutine; when it completes, signal on the channel.
|
||||||
go func() {
|
go func() {
|
||||||
list.Sort()
|
list.Sort()
|
||||||
c <- 1 // Send a signal; value does not matter.
|
c <- 1 // Send a signal; value does not matter.
|
||||||
}()
|
}()
|
||||||
doSomethingForAWhile()
|
doSomethingForAWhile()
|
||||||
<-c // Wait for sort to finish; discard sent value.
|
<-c // Wait for sort to finish; discard sent value.
|
||||||
@ -2494,6 +2507,7 @@ One of the most important properties of Go is that
|
|||||||
a channel is a first-class value that can be allocated and passed
|
a channel is a first-class value that can be allocated and passed
|
||||||
around like any other. A common use of this property is
|
around like any other. A common use of this property is
|
||||||
to implement safe, parallel demultiplexing.
|
to implement safe, parallel demultiplexing.
|
||||||
|
</p>
|
||||||
<p>
|
<p>
|
||||||
In the example in the previous section, <code>handle</code> was
|
In the example in the previous section, <code>handle</code> was
|
||||||
an idealized handler for a request but we didn't define the
|
an idealized handler for a request but we didn't define the
|
||||||
@ -3026,7 +3040,7 @@ TODO
|
|||||||
<pre>
|
<pre>
|
||||||
verifying implementation
|
verifying implementation
|
||||||
type Color uint32
|
type Color uint32
|
||||||
|
|
||||||
// Check that Color implements image.Color and image.Image
|
// Check that Color implements image.Color and image.Image
|
||||||
var _ image.Color = Black
|
var _ image.Color = Black
|
||||||
var _ image.Image = Black
|
var _ image.Image = Black
|
||||||
|
Loading…
Reference in New Issue
Block a user