3 ms·
> I think this is where we differ! I prefer to know what I can do with something without having to ask a compiler or IDE. This helps, for example, when looking
by JadeNB 7y ago
> I think this is where we differ! I prefer to know what I can do with something without having to ask a compiler or IDE. This helps, for example, when looking at a pull request -- you don't have the code easily accessible for the compiler or IDE.
I think, in accordance with "variables won't and constants aren't", I would propose the less pithy: "any invariant that is not enforced is broken". The compiler doesn't check that the capabilities or roles advertised by your variable names are actually present, so eventually they won't be. That means that you can't just check the variable name when reviewing code, must must check the declaration (as well as possibly elsewhere) in case the variable names lies; and, once you're checking that, what have you gained in reviewability?
- zck 7y agoNothing can prevent all errors. Having explicit typing does not prevent `List<Users> bankAccount`, but almost all programmers prefer variable names that encode things not in the data types. So I disagree that you must check that `employeesById` or similar are still a map type if a PR uses it. If it wasn't a map type, I would have expected that to be flagged in the PR that introduced the variable.