6 ms·

> There is no law that requires the use of the same variable naming style as std. Also, While that's technically true, it doesn't work out in practice because

> There is no law that requires the use of the same variable naming style as std. Also, While that's technically true, it doesn't work out in practice because people look to the standard library as "the way" to write golang. It's basically an implied rule and I haven't seen anyone not folllow it so far. > It would be good to know the domain here Both infrastructure level work as well as CRUD type work. > interface{} is really really rare We have to use them everywhere for things like JSON parsing, config file handling, and pagerduty integration. Not to mention wrappers around SQL handling (e.g. batch inserts, pagination, etc.) Generics will fix some things in the language, but not all. There are too many issues with it like the ones I already mentioned. It's still a very cludgy language to work with.

ikiris 5y ago
Having worked with the people doing those standard libraries, you're pulling justifications out of your butt for bad practices. Just as a start: variables names should always be clear by context. You only see the one letter ones if its literally the next line or similar use case. Also, bare interface{} should basically never be the case for a function signature. None of the code you've described thus far would pass a proper review.
- gher-shyu3i 5y ago
  Code bases in reality still do what I'm describing, and they pass code reviews. Kubernetes is one example of the atrocities caused by the language.
majewsky 5y ago
> JSON parsing, config file handling I assume you're not referring to things like json.Marshal(), where the function argument is legitimately of type interface{} since it really accepts any value. Hence I'm going to assume that you're referring to situations where a value can have one of multiple types (e.g. a float value that sometimes gets provided as a string). It's true that people sometimes unmarshal into interface{} and then type-assert in those scenarios, but that use of interface{} is a code smell that should be flagged in review. The proper way is to unmarshal into a custom type with a json.Unmarshaler implementation that accepts all possible input formats (and vice versa for json.Marshaler if encoding is required). This is a real-world example from one of my codebases: https://github.com/sapcc/limes/blob/d833228e976ac1ddc4b9577922824b045e7fab16/pkg/plugins/client_ironic.go#L126-L151 https://github.com/sapcc/limes/blob/d833228e976ac1ddc4b95779...
- gher-shyu3i 5y ago
  Algebraic types would solve the issue in the example you're giving. However, those don't exist in golang either.

ikiris 5y ago

Having worked with the people doing those standard libraries, you're pulling justifications out of your butt for bad practices. Just as a start: variables names should always be clear by context. You only see the one letter ones if its literally the next line or similar use case. Also, bare interface{} should basically never be the case for a function signature. None of the code you've described thus far would pass a proper review.

gher-shyu3i 5y ago
Code bases in reality still do what I'm describing, and they pass code reviews. Kubernetes is one example of the atrocities caused by the language.

majewsky 5y ago

> JSON parsing, config file handling I assume you're not referring to things like json.Marshal(), where the function argument is legitimately of type interface{} since it really accepts any value. Hence I'm going to assume that you're referring to situations where a value can have one of multiple types (e.g. a float value that sometimes gets provided as a string). It's true that people sometimes unmarshal into interface{} and then type-assert in those scenarios, but that use of interface{} is a code smell that should be flagged in review. The proper way is to unmarshal into a custom type with a json.Unmarshaler implementation that accepts all possible input formats (and vice versa for json.Marshaler if encoding is required). This is a real-world example from one of my codebases: https://github.com/sapcc/limes/blob/d833228e976ac1ddc4b9577922824b045e7fab16/pkg/plugins/client_ironic.go#L126-L151 https://github.com/sapcc/limes/blob/d833228e976ac1ddc4b95779...

gher-shyu3i 5y ago
Algebraic types would solve the issue in the example you're giving. However, those don't exist in golang either.