mirror of
https://github.com/Pungyeon/clean-go-article.git
synced 2024-11-10 09:24:04 +00:00
Accept suggestion: replace "that point" with "pointing"
Co-Authored-By: Lasse Martin Jakobsen <lmj@corti.ai>
This commit is contained in:
parent
f81827672d
commit
5ecca2ca95
|
@ -940,7 +940,7 @@ Again, this is a very standard implementation of a getter function for our store
|
||||||
|
|
||||||
> NOTE: Consider the case where our application uses multiple threads. In this scenario, passing pointers to the same memory location can also potentially result in a race condition. In other words, we aren't only potentially corrupting our data—we could also cause a panic from a data race.
|
> NOTE: Consider the case where our application uses multiple threads. In this scenario, passing pointers to the same memory location can also potentially result in a race condition. In other words, we aren't only potentially corrupting our data—we could also cause a panic from a data race.
|
||||||
|
|
||||||
Please keep in mind that there is intrinsically nothing wrong with returning pointers. However, the expanded scope of variables (and the number of owners that point to those variables) is the most important consideration when working with pointers. This is what categorises our previous example as a smelly operation. This is also why common Go constructors are absolutely fine:
|
Please keep in mind that there is intrinsically nothing wrong with returning pointers. However, the expanded scope of variables (and the number of owners pointing to those variables) is the most important consideration when working with pointers. This is what categorises our previous example as a smelly operation. This is also why common Go constructors are absolutely fine:
|
||||||
|
|
||||||
```go
|
```go
|
||||||
func AddName(user *User, name string) {
|
func AddName(user *User, name string) {
|
||||||
|
|
Loading…
Reference in a new issue