3 ms·
The problem likely results from: var i = someFunctionWithANonObviousReturnType(); Type inference may be easy when the left-hand side is a literal, but that's
by curun1r 8y ago
The problem likely results from:
var i = someFunctionWithANonObviousReturnType();
Type inference may be easy when the left-hand side is a literal, but that's often not the case. And when the left-hand side isn't a literal, it definitely optimizes writing code at the expense of reading code. You can argue that IDEs should be helping us by show us the type when we mouse over or auto-completing available methods on the variable's type, but there are situations (code review, pair programming, etc) where we can't rely on tooling to help in this regard. I get why people like type inference and I use languages that have it on a daily basis, but I've also realized that I need to adapt my coding style to it or I'll end up with code that's difficult to read. In particular, I'm constantly considering whether the code I'm writing is understandable using local reasoning only and that I'm not forcing a reader of my code (who's likely to be me several months from now) to jump to some declaration somewhere else in the code.
- melling 8y agoThen add a type in that instance. var i:ReturnType = someFunctionWithANonObviousReturnType I found that in practice I don't need it.