3 ms·
My personal grudge with Go is its sorting interface. You have to typedef various kinds of slices and define methods for them. I mean, all Len() and Swap() calls
by echaozh 14y ago
My personal grudge with Go is its sorting interface. You have to typedef various kinds of slices and define methods for them. I mean, all Len() and Swap() calls look exactly the same (at least in the sort package), it's such a horrible duplication of code.
Also, the Less() method should not be defined for the slice types. They should be defined for the types in the slices. Every sane language lets you define comparing methods for types themselves, rather than bind them to the container types, to honor some software principles.
Also, "err" is a surprisingly common name for variables even in the same function. When it's previously defined, and the variable after it is not, the ":=" operator doesn't work (I seem to remember). Appending numbers to "err" is ugly IMO. I don't mind no exceptions if not for this. Speaking of it, making "err" a keyword or special global variable may be a good idea, like the "errno" in C.
- jff 14y agoYou should be checking errors immediately after they are returned. Once you've checked it, re-use the variable: x, err := f(a) if err != nil { // probably time to return from the func } y, err := g(x) // we have at least 1 new var, so := still works if err != nil { // handle } x, err = h(y) // since we're re-using both x and err, just use = I've never appended a number to "err".