37
Name before type: why 'age int' is better than 'int age'
(benhoyt.com)
This is a most excellent place for technology news and articles.
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.