4 ms·

There are cases (when writing template libraries) where you don't know the types you'll be using yet, and you need auto to express what you want. Apart from th

by roel_v 8y ago

There are cases (when writing template libraries) where you don't know the types you'll be using yet, and you need auto to express what you want. Apart from those (admittedly) rare cases, after a few years using auto, I'm not as opposed as I was. Generally I use auto by default, and replace it with the actual type when I re-visit that code and have to actually think what the type would be. I'd guesstimate that I do that in, maybe 10% of the cases where I initially used auto. Makes code much more readable (as in, 'reading over'), too. Turns out it's only when you try to reason an algorithm through line by line that you actually need the type, and in the other cases (where you're just roughly following along, which I find happens more often than the other case) having 'auto' abstracts away some of the mental overhead of having type declarations.

mlthoughts2018 8y ago
> “Turns out it's only when you try to reason an algorithm through line by line that you actually need the type,” Yes, but for other people reading your code, this would be way more often than 10% of the time. So you save a tiny bit of effort in 90% of cases for you, while other people have to exert more effort in probably 90% of cases for them. It seems like the minute the number of people needing to read and understand that section of code exceeds 2 (you & one other), then this type of use of auto is actually increasing the amount of overall work required linearly for every additional person added in.
- roel_v 8y ago
  I don't really agree. I don't think there is much difference between reading code you wrote a few weeks ago and code someone else wrote - at least not in this context.
  - mlthoughts2018 8y ago
    We might just have to agree to disagree, but I would disagree with your claim here in the strongest possible terms. When someone new comes into a project, you can’t assume what skill level they’re at, how they think about code, what design patterns have been most strongly used in the teams they were previously on. Code you wrote a few weeks ago is still going to be hugely similar to the types of code you often write, the ways you think about design patterns, etc., especially if you’re on a team for a long time. Code someone else wrote very frequently looks completely alien, especially for new people, or someone from a different team that has to collaborate on one small cross-cutting problem, or people who look at your code long after you left the company. Using things like auto because it has some benefit as you write the code, in your mind, is deceptive for exactly this reason. Those criteria are hardly ever still relevant when it is someone else reading the code.
    - roel_v 8y ago
      Sure. Do you have experience using 'auto'? I'm asking because I once thought exactly like you, but changed my mind after a few years of real-world experience. But of course, YMMV.
      - mlthoughts2018 8y ago
        Yes. Previously at a proprietary trading company, we refactored a large subset of the code to use auto, and found that people, especially traders and quants, who have to do projects extending that code on a more ad hoc basis, had a drastically harder time reading and reasoning about it, so we rolled back and instead had a company convention to disallow the use of auto. If the only people reading the code was my team, then it probably would have been fine (though still a silly thing to get rid of or to stop writing new type annotations). But that’s never the case in real software. Other people needing to quickly grok it is usually concern #1, even higher than performance most of the time (and that stuff powered a real-time trading system).

by roel_v 8y ago

mlthoughts2018 8y ago

> “Turns out it's only when you try to reason an algorithm through line by line that you actually need the type,” Yes, but for other people reading your code, this would be way more often than 10% of the time. So you save a tiny bit of effort in 90% of cases for you, while other people have to exert more effort in probably 90% of cases for them. It seems like the minute the number of people needing to read and understand that section of code exceeds 2 (you & one other), then this type of use of auto is actually increasing the amount of overall work required linearly for every additional person added in.

roel_v 8y ago
I don't really agree. I don't think there is much difference between reading code you wrote a few weeks ago and code someone else wrote - at least not in this context.
- mlthoughts2018 8y ago
  We might just have to agree to disagree, but I would disagree with your claim here in the strongest possible terms. When someone new comes into a project, you can’t assume what skill level they’re at, how they think about code, what design patterns have been most strongly used in the teams they were previously on. Code you wrote a few weeks ago is still going to be hugely similar to the types of code you often write, the ways you think about design patterns, etc., especially if you’re on a team for a long time. Code someone else wrote very frequently looks completely alien, especially for new people, or someone from a different team that has to collaborate on one small cross-cutting problem, or people who look at your code long after you left the company. Using things like auto because it has some benefit as you write the code, in your mind, is deceptive for exactly this reason. Those criteria are hardly ever still relevant when it is someone else reading the code.
  - roel_v 8y ago
    Sure. Do you have experience using 'auto'? I'm asking because I once thought exactly like you, but changed my mind after a few years of real-world experience. But of course, YMMV.
    - mlthoughts2018 8y ago
      Yes. Previously at a proprietary trading company, we refactored a large subset of the code to use auto, and found that people, especially traders and quants, who have to do projects extending that code on a more ad hoc basis, had a drastically harder time reading and reasoning about it, so we rolled back and instead had a company convention to disallow the use of auto. If the only people reading the code was my team, then it probably would have been fine (though still a silly thing to get rid of or to stop writing new type annotations). But that’s never the case in real software. Other people needing to quickly grok it is usually concern #1, even higher than performance most of the time (and that stuff powered a real-time trading system).