5 ms·
And it's also one of the easiest ways to write unmaintainable codes. I once inherited a code where the previous developer seemed to just have found out how cool
by maxxxxx 7y ago
And it's also one of the easiest ways to write unmaintainable codes. I once inherited a code where the previous developer seemed to just have found out how cool operator overloading is. So there were a ton of overloads everywhere and you couldn't really tell what is just built-in operators and which is our own code. Total nightmare. After this I would be fine with operator overloading removed from languages.
Nothing wrong with writing:
Matrix_Multiply(m1,m2);
vs.
m1*m2
The first is not harder to read and not harder to write but I know exactly what's going on.
- fauigerzigerk 7y agoSo this code is from Go's big.Int documentation (slightly adapted): func main() { a := big.NewInt(0) b := big.NewInt(1) var limit big.Int limit.Exp(big.NewInt(10), big.NewInt(99), nil) for a.Cmp(&limit) < 0 { a.Add(a, b) a, b = b, a } fmt.Println(a) } I can't say I'm particularly keen on having to read a.Cmp(&limit) < 0 instead of a < limit The question is whether it's worth it to write code like this in order to prevent others from misusing operator overloading. I guess it may depend on how much math code you write and how disciplined your coworkers are.
- AnimalMuppet 7y ago> The first is not harder to read and not harder to write but I know exactly what's going on. For your example, maybe so. But: m = a * b * c + d * e + f will be clearer than three Matrix_Multiply and two Matrix_Add calls. And one screen full of lines like mine will be far clearer than five screens full of Matrix_Add and Matrix_Multiply calls.
- maxxxxx 7y agoI agree if it’s very mathy but I have seen operator overloading for things like invoices and orders. That’s just horrible.
- AnimalMuppet 7y agoOh, I agree. invoice++ is not better than invoice.addToSystem()