3 ms·

> In a strongly typed language, you shouldn't encode type information in the name, it's statically derivable. This is completely true! > The name doesn't need

by zck 7y ago

> In a strongly typed language, you shouldn't encode type information in the name, it's statically derivable. This is completely true! > The name doesn't need to tell you that, you already know and the language will prevent you from misusing it. 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. Possibly a difference is that I prefer to use languages that are more dynamically typed -- Clojure, Emacs Lisp, etc. And so you don't have `Map<EmployeeId, Employee> employeesById`; you only have the variable name. But I do wonder -- even in the most explicitly typed, statically typed languages, what is the eser experience for finding this out? It seems that unless one is looking at the declaration, there must be at least one level of indirection to find out what the type of something is. Say you're looking at a use of the variable `employees`. Here's the ways I can think of that would let you know what the type is: 1. Scan upwards until you find the declaration, if it even is on screen. Then look back to where the use was. 2. Move the cursor to the variable, and use the "go to definition" functionality built into the IDE. Then look at the declaration, and use the "go back" IDE function. 3. Move the cursor to the variable, and the IDE has somewhere that tells you the type. This is relatively simple, but still requires you to move to the variable, and to look somewhere else and back. On the other hand, with a name like `employeesById`, all you need is in that thirteen characters.

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 ago
  Nothing 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.
joshuamorton 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. Same (I mostly use python, which puts your dynamic languages to shame), so structure your code such that this is possible. Keep your functions relatively short. Then the declaration of a type, if its a local or an argument, will be close by (usually the same screen). Globals should be defined at the top, so those are easy too. That leaves only class members that might require spelunking. Be judicious with those, they're often more pain than is worth it. As for your statement about employeesById not being a map should be called out in review, that's true. But over time those things can change unless enforced. You're not just relying on the initial review, but all follow up changes not breaking the invariants.

by zck 7y ago

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 ago
Nothing 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.

joshuamorton 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. Same (I mostly use python, which puts your dynamic languages to shame), so structure your code such that this is possible. Keep your functions relatively short. Then the declaration of a type, if its a local or an argument, will be close by (usually the same screen). Globals should be defined at the top, so those are easy too. That leaves only class members that might require spelunking. Be judicious with those, they're often more pain than is worth it. As for your statement about employeesById not being a map should be called out in review, that's true. But over time those things can change unless enforced. You're not just relying on the initial review, but all follow up changes not breaking the invariants.