Accept suggestion: replace "—ones" with " that"

Co-Authored-By: Lasse Martin Jakobsen <lmj@corti.ai>
This commit is contained in:
Aleksandr H 2019-07-01 08:57:49 -04:00 committed by GitHub
parent f159685f10
commit 0d8bea3073
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -1222,7 +1222,7 @@ As mentioned in a previous section, Go determines whether a concrete type implem
type EmptyInterface interface {} type EmptyInterface interface {}
``` ```
The above is equivalent to the built-in type `interface{}`. A natural consequence of this is that we can write generic functions&mdash;ones that accept any type as arguments. This is extremely useful for certain kinds of functions, such as print helpers. Interestingly, this is actually what makes it possible to pass in any type to the `Println` function from the `fmt` package: The above is equivalent to the built-in type `interface{}`. A natural consequence of this is that we can write generic functions that accept any type as arguments. This is extremely useful for certain kinds of functions, such as print helpers. Interestingly, this is actually what makes it possible to pass in any type to the `Println` function from the `fmt` package:
```go ```go
func Println(v ...interface{}) { func Println(v ...interface{}) {
@ -1348,4 +1348,4 @@ As a final note, it's worth mentioning that the notion of clean code is particul
It's also important to understand that fanaticism is never the goal with clean code. A codebase will most likely never be fully 'clean,' in the same way that your office desk probably isn't either. There's certainly room for you to step outside the rules and boundaries covered in this article. However, remember that the most important reason for writing clean code is to help yourself and other developers. We support engineers by ensuring stability in the software we produce and by making it easier to debug faulty code. We help our fellow developers by ensuring that our code is readable and easily digestible. We help <em>everyone</em> involved in the project by establishing a flexible codebase that allows us to quickly introduce new features without breaking our current platform. We move quickly by going slowly, and everyone is satisfied. It's also important to understand that fanaticism is never the goal with clean code. A codebase will most likely never be fully 'clean,' in the same way that your office desk probably isn't either. There's certainly room for you to step outside the rules and boundaries covered in this article. However, remember that the most important reason for writing clean code is to help yourself and other developers. We support engineers by ensuring stability in the software we produce and by making it easier to debug faulty code. We help our fellow developers by ensuring that our code is readable and easily digestible. We help <em>everyone</em> involved in the project by establishing a flexible codebase that allows us to quickly introduce new features without breaking our current platform. We move quickly by going slowly, and everyone is satisfied.
I hope you will join this discussion to help the Go community define (and refine) the concept of clean code. Let's establish a common ground so that we can improve software&mdash;not only for ourselves but for the sake of everyone. I hope you will join this discussion to help the Go community define (and refine) the concept of clean code. Let's establish a common ground so that we can improve software&mdash;not only for ourselves but for the sake of everyone.