mirror of
https://github.com/teivah/100-go-mistakes.git
synced 2026-06-25 19:06:58 +08:00
Add tl;dr
This commit is contained in:
parent
aa06a2f79d
commit
55dcbb6464
1 changed files with 15 additions and 20 deletions
|
|
@ -166,9 +166,6 @@ The value element in a `range` loop is a copy. Therefore, to mutate a struct, fo
|
||||||
|
|
||||||
#### #31: Ignoring how arguments are evaluated in `range` loops (channels and arrays)
|
#### #31: Ignoring how arguments are evaluated in `range` loops (channels and arrays)
|
||||||
|
|
||||||
* Channels
|
|
||||||
* Arrays
|
|
||||||
|
|
||||||
Understanding that the expression passed to the `range` operator is evaluated only once before the beginning of the loop can help you avoid common mistakes such as inefficient assignment in channel or slice iteration.
|
Understanding that the expression passed to the `range` operator is evaluated only once before the beginning of the loop can help you avoid common mistakes such as inefficient assignment in channel or slice iteration.
|
||||||
|
|
||||||
#### #32: Ignoring the impacts of using pointer elements in `range` loops
|
#### #32: Ignoring the impacts of using pointer elements in `range` loops
|
||||||
|
|
@ -177,7 +174,7 @@ Using a local variable or accessing an element using an index, you can prevent m
|
||||||
|
|
||||||
#### #33: Making wrong assumptions during map iterations (ordering and map insert during iteration)
|
#### #33: Making wrong assumptions during map iterations (ordering and map insert during iteration)
|
||||||
|
|
||||||
To ensure predictable outputs when using maps, remember that a map data structure
|
To ensure predictable outputs when using maps, remember that a map data structure:
|
||||||
* Doesn’t order the data by keys
|
* Doesn’t order the data by keys
|
||||||
* Doesn’t preserve the insertion order
|
* Doesn’t preserve the insertion order
|
||||||
* Doesn’t have a deterministic iteration order
|
* Doesn’t have a deterministic iteration order
|
||||||
|
|
@ -247,7 +244,7 @@ Passing a pointer to a `defer` function and wrapping a call inside a closure are
|
||||||
|
|
||||||
#### #48: Panicking
|
#### #48: Panicking
|
||||||
|
|
||||||
* Using `panic` is an option to deal with errors in Go. However, it should only be used sparingly in unrecoverable conditions: for example, to signal a programmer error or when you fail to load a mandatory dependency.
|
Using `panic` is an option to deal with errors in Go. However, it should only be used sparingly in unrecoverable conditions: for example, to signal a programmer error or when you fail to load a mandatory dependency.
|
||||||
|
|
||||||
#### #49: Ignoring when to wrap an error
|
#### #49: Ignoring when to wrap an error
|
||||||
|
|
||||||
|
|
@ -504,8 +501,6 @@ Being conscious of the cache line concept is critical to understanding how to or
|
||||||
|
|
||||||
* Slice of structs vs. struct of slices
|
* Slice of structs vs. struct of slices
|
||||||
|
|
||||||
See above.
|
|
||||||
|
|
||||||
* Predictability
|
* Predictability
|
||||||
|
|
||||||
Making code predictable for the CPU can also be an efficient way to optimize certain functions. For example, a unit or constant stride is predictable for the CPU, but a non-unit stride (for example, a linked list) isn’t predictable.
|
Making code predictable for the CPU can also be an efficient way to optimize certain functions. For example, a unit or constant stride is predictable for the CPU, but a non-unit stride (for example, a linked list) isn’t predictable.
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue