4 ms·

I recently learned that Godot forbids auto in its core C++ codebase, their rationale was based on code review: > Keep in mind hover documentation often isn't r

I recently learned that Godot forbids auto in its core C++ codebase, their rationale was based on code review: > Keep in mind hover documentation often isn't readily available for pull request reviewers. Most of the time, reviewers will use GitHub's online viewer to review pull requests. `using` directives and typedefs are not forbidden, so this would avoid situations where a type is never explicitly declared. Having worked in large code bases that used `auto` almost exclusively when possible… I’m not sure I agree. However, I understand. https://docs.Godotengine.org/en/stable/contributing/development/cpp_usage_guidelines.html#auto-keyword https://docs.Godotengine.org/en/stable/contributing/developm...

vips7L 3y ago
We've taken this approach with var in Java. If we can't tell the type from the right hand side it should be declared on the left. var m = new Thing(); // you know its a thing var t = a.b().c(); // what is it?
- PaulDavisThe1st 3y ago
  in loops, the lack of knowing can be considered a positive though: for (auto const & thing : container_of_things) { thing->method (); } in this context (and this context alone) i love not knowing or having to explicit denote the type of "thing".
- fluoridation 3y ago
  Naming issues aside, the type of t shouldn't matter, in the same way that the type of a.b() doesn't matter. What matters is how t relates to the code around it. What's the purpose of t in the context where it's used? What does it store? If you don't know whether t is an iterator over a sequence, the timestamp of an event, or the measurement of a sensor, knowing whether t is an int or a string won't help you much. If you do know that, knowing the specific type of t will probably not provide much more additional information, since in any given codebase for almost all non-primitive types there's at most two different types with comparable purpose.
  - vips7L 3y ago
    Types are context.
- neuromanser 3y ago
  var t = a.b().c(); // what is it? Most likely bad code (on the right hand side) https://en.m.wikipedia.org/wiki/Law_of_Demeter https://en.m.wikipedia.org/wiki/Law_of_Demeter
  - vips7L 3y ago
    I agree but my coworkers don’t :)

vips7L 3y ago

We've taken this approach with var in Java. If we can't tell the type from the right hand side it should be declared on the left. var m = new Thing(); // you know its a thing var t = a.b().c(); // what is it?

PaulDavisThe1st 3y ago
in loops, the lack of knowing can be considered a positive though: for (auto const & thing : container_of_things) { thing->method (); } in this context (and this context alone) i love not knowing or having to explicit denote the type of "thing".
fluoridation 3y ago
Naming issues aside, the type of t shouldn't matter, in the same way that the type of a.b() doesn't matter. What matters is how t relates to the code around it. What's the purpose of t in the context where it's used? What does it store? If you don't know whether t is an iterator over a sequence, the timestamp of an event, or the measurement of a sensor, knowing whether t is an int or a string won't help you much. If you do know that, knowing the specific type of t will probably not provide much more additional information, since in any given codebase for almost all non-primitive types there's at most two different types with comparable purpose.
- vips7L 3y ago
  Types are context.
neuromanser 3y ago
var t = a.b().c(); // what is it? Most likely bad code (on the right hand side) https://en.m.wikipedia.org/wiki/Law_of_Demeter https://en.m.wikipedia.org/wiki/Law_of_Demeter
- vips7L 3y ago
  I agree but my coworkers don’t :)