Discussion on "Common anti-patterns in Go"

Saif Sadiq · 2021-03-24T06:05:42.000Z

It has been widely acknowledged that coding is an art, and like every artisan who crafts wonderful art and is proud of them, we as developers are also really proud of the code we write. In order to achieve the best results, artists constantly keep se...

This is a good article but these aren't really anti-patterns, right? Like, if we were talking C, and I said:

Bad Practice: i = i + 1;

Good Practice: i++;

The first example isn't so much an anti-pattern as a novice mistake, not idiomatic or stylistic. One can, and many have, written perfectly fine software with misunderstandings or incomplete understanding of how a language works.

To be an anti-pattern, it has to be "ineffective and/or counterproductive in practice". And I think generally, if they're not straight-up wrong, they have to be a smell—an indication of a poor design choice. #1 works counts, I think.

#9 is akin to a "poltergeist" (an anti-pattern where an object does nothing but act through another object) but it's interesting to note that, in Go, this is far less serious because it's far less hidden. A lot of this stuff is something an experience Go programmer would just say, "Oh, yeah, you don't need that," and take it out on a casual pass-through.

Anti-patterns usually require more serious refactoring.

Agree. I would call this some kind of coding best practices in the language.

Saif, the blog was really a pleasure to read and very informative. Would want to share feedback on two points.

For point 5: The function printAndReturnFoofoo where we have a named return type, we would get error if we try to initialize variable with same name inside the function, it is already initialized for the return, so we can update foofoo := "foofoo" to foofoo = "foofoo"

For point 9: The example is missing the simplified version.

Hey Sagar Jha,

Its great to hear that you found the post helpful. Thanks for the suggestion regarding the point 5. Have made the changes by removing the short variable declaration.

Regarding point 9, I think it does have a simplified solution. Here is an example to help you understand its simplified solution in a better way :

// add sums up x and y
func add(x int, y int) int {
    return x + y
}
func main() {
    complexFn := func(x int, y int) int { return add(x, y) }
    fmt.Println("sum:", complexFn(1,2))
    simpleFn := add
    fmt.Println("sum:", simpleFn(1,2))
}

Do let me know if you have any queries/thoughts. Thanks.

There is something wrong with the code formatting - please fix...

Fixed, thanks for noticing.

Discussion

Common anti-patterns in Go

Responses(3)

Recent in Forum

Search Hashnode

Common anti-patterns in Go

Responses(3)

Recent in Forum