4 ms·

Many text editors and IDEs can reveal the type of an expression in real time. I'm surprised the author doesn't mention this.

azhenley 7y ago
I thought I did in the paragraph starting with “Tools can help a lot with this.” Or do you mean something else? I also make the point that often I’m reading code on GitHub or outside an IDE, which does not have such features.
- matt2000 7y ago
  Agreed, better to use an IDE to insert the full type of a variable automatically so the code is readable in any environment afterwards. Inferred types feels like an invention for people who don’t like IDEs, that somehow forces everyone _else_ to use an IDE.
  - rienbdj 7y ago
    But then an otherwise small change might result in changes to type annotations all over a code base.
    - matt2000 7y ago
      Again, I find refactoring tools handle this well, and also this is kind of the point for me - I want to see the effect of type changes.
- chmaynard 7y ago
  Mea culpa. I didn't read the article closely enough and I missed this.
- o_nate 7y ago
  This is maybe slightly off-topic but one reason I prefer Java to C# when it comes to reading code outside an IDE is that it forces you to explicitly declare where every external class is being imported from, which makes it much easier to go looking for the definition if you need it, when you don't have access to the IDE's right-click "Go to Definition".
matt2000 7y ago
Many IDEs can automatically insert the type of a variable when developing. This seems preferable: have one person do this one action once, rather than every person reading the code in the future having to do work to decode the type.
- jddj 7y ago
  As a reader, faced with: Dictionary<string, KeyValuePair<int, string>> contrivedExample = new Dictionary<string, KeyValuePair<int, string>>(); And DictionaryOfStringsWithKeyValuePairs contrivedExample = new DictionaryOfStringsWithKeyValuePairs(); And var contrivedExample = new Dictionary<string, KeyValuePair<int, string>>(); I'd definitely prefer the latter. -- Edit: rephrased to be less presumptuous
  - matt2000 7y ago
    I hear you, but the current state of affairs in Java (I know this isn't quite Java, but just for illustration) is more like: Dictionary<string, KeyValuePair<int, string>> contrivedExample = new Dictionary<>(); Which seems ok to me? And we don't enter the slippery slope of allowing variables without types, and hoping people just use it where appropriate.
    - balfirevic 7y ago
      C# developer here, which has local variable type inference. It is appropriate in 95% of places. It hasn't caused an apocalypse yet. It has, in fact, been great!
  - hibbelig 7y ago
    I think if it avoids having to repeat the type then type inference helps. And especially that last Java example, there I feel it is useful: for (var x : someMap.entrySet()) { String key = x.getKey(); Entity value = x.getValue(); ... } Here, the reader just needs look at the next two lines to understand the type of x. In the article, the key and value types were long and complicated, and they asked us to refactor. But in the above example, the types are very simple, yet still it's better than for (Map.Entry<String, Entity> x : someMap.entrySet()) { String key = x.getKey(); Entity value = x.getValue(); ... } I feel in this example, the type in front of x doesn't help me, as a reader.

azhenley 7y ago

I thought I did in the paragraph starting with “Tools can help a lot with this.” Or do you mean something else? I also make the point that often I’m reading code on GitHub or outside an IDE, which does not have such features.

matt2000 7y ago
Agreed, better to use an IDE to insert the full type of a variable automatically so the code is readable in any environment afterwards. Inferred types feels like an invention for people who don’t like IDEs, that somehow forces everyone _else_ to use an IDE.
- rienbdj 7y ago
  But then an otherwise small change might result in changes to type annotations all over a code base.
  - matt2000 7y ago
    Again, I find refactoring tools handle this well, and also this is kind of the point for me - I want to see the effect of type changes.
chmaynard 7y ago
Mea culpa. I didn't read the article closely enough and I missed this.
o_nate 7y ago
This is maybe slightly off-topic but one reason I prefer Java to C# when it comes to reading code outside an IDE is that it forces you to explicitly declare where every external class is being imported from, which makes it much easier to go looking for the definition if you need it, when you don't have access to the IDE's right-click "Go to Definition".

matt2000 7y ago

Many IDEs can automatically insert the type of a variable when developing. This seems preferable: have one person do this one action once, rather than every person reading the code in the future having to do work to decode the type.

jddj 7y ago
As a reader, faced with: Dictionary<string, KeyValuePair<int, string>> contrivedExample = new Dictionary<string, KeyValuePair<int, string>>(); And DictionaryOfStringsWithKeyValuePairs contrivedExample = new DictionaryOfStringsWithKeyValuePairs(); And var contrivedExample = new Dictionary<string, KeyValuePair<int, string>>(); I'd definitely prefer the latter. -- Edit: rephrased to be less presumptuous
- matt2000 7y ago
  I hear you, but the current state of affairs in Java (I know this isn't quite Java, but just for illustration) is more like: Dictionary<string, KeyValuePair<int, string>> contrivedExample = new Dictionary<>(); Which seems ok to me? And we don't enter the slippery slope of allowing variables without types, and hoping people just use it where appropriate.
  - balfirevic 7y ago
    C# developer here, which has local variable type inference. It is appropriate in 95% of places. It hasn't caused an apocalypse yet. It has, in fact, been great!
- hibbelig 7y ago
  I think if it avoids having to repeat the type then type inference helps. And especially that last Java example, there I feel it is useful: for (var x : someMap.entrySet()) { String key = x.getKey(); Entity value = x.getValue(); ... } Here, the reader just needs look at the next two lines to understand the type of x. In the article, the key and value types were long and complicated, and they asked us to refactor. But in the above example, the types are very simple, yet still it's better than for (Map.Entry<String, Entity> x : someMap.entrySet()) { String key = x.getKey(); Entity value = x.getValue(); ... } I feel in this example, the type in front of x doesn't help me, as a reader.