[vips7L]

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?

[fluoridation]

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]

Types are context.

[neuromanser]

    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

[vips7L]

I agree but my coworkers don’t :)

[PaulDavisThe1st]

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".