4 ms·

When you can use auto without hampering readability, and while improving maintainability, by all means do so. This is often the case when the actual type doesn'

When you can use auto without hampering readability, and while improving maintainability, by all means do so. This is often the case when the actual type doesn't matter to the reader, for example. I basically said this in my earlier comment. But that's second priority to readability, because people read code much more often than they refactor it, and they need to be able to easily anchor their understanding when reading. Optimizing code for efficiency of editing instead of the ability to understand it is getting the priorities very wrong.

fluoridation 3y ago
Sure, but like I said in a sibling comment, I don't believe that knowing the types of the objects is actually helpful in understanding a piece of code. You'll need to know the actual types to know its exact performance characteristics, but if you can't understand what the code does even at a high level when you can't see any types then there's a problem anyway.
- dataflow 3y ago
  > but if you can't understand what the code does even at a high level when you can't see any types then there's a problem anyway. Who says this implies you can't understand what the code does at a high level? Often you know the high level behavior but need to figure out how it works so you can update the code. If anything, the high level behavior is often easier to understand, since you have the API documentation etc. available. And in the cases where that is the case, what does "there's a problem anyway" mean? That the reader is too stupid to figure it out?
  - fluoridation 3y ago
    No, that the code is poorly documented, or that the names are poorly chosen.
    - dataflow 3y ago
      Sometimes, but not necessarily. Even when that's the case (and nobody always gets all the names perfect in the first iteration), you still face the problem of understanding it before you can fix that, so throwing your hands up is not a solution. Regardless, the rest of my comment stands.

fluoridation 3y ago

Sure, but like I said in a sibling comment, I don't believe that knowing the types of the objects is actually helpful in understanding a piece of code. You'll need to know the actual types to know its exact performance characteristics, but if you can't understand what the code does even at a high level when you can't see any types then there's a problem anyway.

dataflow 3y ago
> but if you can't understand what the code does even at a high level when you can't see any types then there's a problem anyway. Who says this implies you can't understand what the code does at a high level? Often you know the high level behavior but need to figure out how it works so you can update the code. If anything, the high level behavior is often easier to understand, since you have the API documentation etc. available. And in the cases where that is the case, what does "there's a problem anyway" mean? That the reader is too stupid to figure it out?
- fluoridation 3y ago
  No, that the code is poorly documented, or that the names are poorly chosen.
  - dataflow 3y ago
    Sometimes, but not necessarily. Even when that's the case (and nobody always gets all the names perfect in the first iteration), you still face the problem of understanding it before you can fix that, so throwing your hands up is not a solution. Regardless, the rest of my comment stands.