4 ms·
I'll agree that your second example is less readable than the first.. This could be mitigated with the name of foo() being more descriptive. If the return typ
by asveikau 2y ago
I'll agree that your second example is less readable than the first..
This could be mitigated with the name of foo() being more descriptive.
If the return type is particularly wordy, auto could still be appropriate.
- unleaded 2y ago> This could be mitigated with the name of foo() being more descriptive. welcome back Hungarian notation
- jeremyjh 2y agoauto conn = createConnection(); What does this have to do with hungarian notation?
- pests 2y agoYou’re thinking of it wrong. This works better: auto uasStudents = getClassList() In this case, “uas” prefix standing for an unsafe array of strings. Then say you validate the list auto sasStudents = validate(uasStudents) (Now it’s a safe array of students!)
- dullcrisp 2y agoI feel like I’m missing a joke.
- powercf 2y agoAlone this looks like a reasonable use of auto. In a real codebase, there may be two (or twenty) different connection-like things, multiple of which may be reasonably to call in this context. The "Hungarian notation" comment is correct - it's not strictly Hungarian notation, but annotating function (or variable) names when the language has a type system representing this same information is the same idea with the same problems as Hungarian notation.
- asveikau 2y agolpwszThanks. In seriousness, no, that's not what I'm suggesting, and I find it an unusual thing to read from my comment. I'm saying a descriptive name for foo() can give you a hint about what the type is, even if it doesn't literally and directly tell you what the type is.