Not… really. I can kinda see where you’re coming from, but if you are assigning a .ToString() to a variable, the only type it could be is a string.
It’s not guessing, it’s inference. You’ve provided enough information to know what the type is, so it is now that type. The moment you introduce ambiguity, such as var test = 1 there are many things that variable could be, so you can no longer infer its type.
Inference is not guessing. Can it go wrong? Certainly! But its quite rare. And the solution in those rare cases is explicit typing.
I come from a background of porting code between architectures, like 16 to 32 bit. The int type in C was (is) ambiguous in that case, 16 bit signed int on the 16 bit system, 32 bits on the 32 bit system. First thing I had to do to make the 500,000 LOC package start to run properly when ported from 16 bits to 32 bits was find and replace all " int "with " int16 ", “(int)” with “(int16)” etc. It was only going wrong “quite rarely” - but “quite rarely” doesn’t cut it, they ALL needed to behave predictably the same as they did before the move. I believe that effort took 3 solid work days, 24 hours of my life, because “int” was “good enough” for the previous team.
Er… okay, yes. That would be quite the annoyance, but thats a bit of an edge case in this instance. I’d also wager that current implementations of IDEs would allow you to intelligently replace int with Int16/Int32/Int64 depending on the context before migration. I believe Visual Studio proper has that as an option in its code analysis and cleanup tool. You can also do the same for var => string typing if I remember correctly.
My point is: as a programmer, you should always care how your value is handled. All variable types have limitations, edge cases, and resource demands (infinite capacity big-int representations are slow and memory intense, even if they never overflow or underflow.) KNOW what your code is doing with the value.
I’m O.K. with API style functions accepting all kinds of inputs and dealing with them in a predictable way once called, but if you’re writing code that handles values, once you have been assigned those values you should be getting, deterministically, the same result every time.
Otherwise, you’re like those kids in programming class writing while loops with floating point control variables that increment +0.1 per loop, thresholded to stop at v >= 100.0
You do realize that in C# at least, these compile to strongly typed variables? Barring a major change, such as migrating from 16 to 32 bit, you know what those value types are, you’re just not having to write them out. It saves you from having to type “LongDescriptiveTypeDescriptionBecauseSomeoneWasOverlyVerboseInTheirNaming” which is a small but nice thing to have. We arent talking about dynamics here.
Ooooh my poor fingers… yes, I used to worry about abbreviating everything as short as possible, and I still control my loops with i j and k, but when it comes to ambiguous var vs QString or int32 or float or double or whatever type du jour is, I’ll take the time and effort to write it out rather than taking the time later to untangle how the ambiguity might have resolved and all the unexpected things that might happen as a result of an unexpected resolution.
Controversial take: it doesn’t matter in the slightest.
Breaking News: local dev argues peanut butter on jam is the same as jam on peanut butter.
Try to write some code and see if it matters. Try to argue against a compiler, please.
Typeless variables are a delusion, they’re just guessing what type they should be for you.
Not… really. I can kinda see where you’re coming from, but if you are assigning a .ToString() to a variable, the only type it could be is a string.
It’s not guessing, it’s inference. You’ve provided enough information to know what the type is, so it is now that type. The moment you introduce ambiguity, such as
var test = 1there are many things that variable could be, so you can no longer infer its type.Inference is not guessing. Can it go wrong? Certainly! But its quite rare. And the solution in those rare cases is explicit typing.
I come from a background of porting code between architectures, like 16 to 32 bit. The int type in C was (is) ambiguous in that case, 16 bit signed int on the 16 bit system, 32 bits on the 32 bit system. First thing I had to do to make the 500,000 LOC package start to run properly when ported from 16 bits to 32 bits was find and replace all " int "with " int16 ", “(int)” with “(int16)” etc. It was only going wrong “quite rarely” - but “quite rarely” doesn’t cut it, they ALL needed to behave predictably the same as they did before the move. I believe that effort took 3 solid work days, 24 hours of my life, because “int” was “good enough” for the previous team.
Er… okay, yes. That would be quite the annoyance, but thats a bit of an edge case in this instance. I’d also wager that current implementations of IDEs would allow you to intelligently replace int with Int16/Int32/Int64 depending on the context before migration. I believe Visual Studio proper has that as an option in its code analysis and cleanup tool. You can also do the same for var => string typing if I remember correctly.
My point is: as a programmer, you should always care how your value is handled. All variable types have limitations, edge cases, and resource demands (infinite capacity big-int representations are slow and memory intense, even if they never overflow or underflow.) KNOW what your code is doing with the value.
I’m O.K. with API style functions accepting all kinds of inputs and dealing with them in a predictable way once called, but if you’re writing code that handles values, once you have been assigned those values you should be getting, deterministically, the same result every time.
Otherwise, you’re like those kids in programming class writing while loops with floating point control variables that increment +0.1 per loop, thresholded to stop at v >= 100.0
You do realize that in C# at least, these compile to strongly typed variables? Barring a major change, such as migrating from 16 to 32 bit, you know what those value types are, you’re just not having to write them out. It saves you from having to type “LongDescriptiveTypeDescriptionBecauseSomeoneWasOverlyVerboseInTheirNaming” which is a small but nice thing to have. We arent talking about dynamics here.
Ooooh my poor fingers… yes, I used to worry about abbreviating everything as short as possible, and I still control my loops with i j and k, but when it comes to ambiguous var vs QString or int32 or float or double or whatever type du jour is, I’ll take the time and effort to write it out rather than taking the time later to untangle how the ambiguity might have resolved and all the unexpected things that might happen as a result of an unexpected resolution.