I remember one GitHub project that implemented some algorithm (I think it was Dijkstra's) but only used 4 or 5 single letter variables and just kept reusing them.
When I was in college, I had a guy that I was working on a project with that did this constantly. At one point I looked at one of his files and the variables were named a, b, c, aa, ab, ac, ba, bb, etc. That when I was like, bro, you gotta stop doing this.
"Inside you there are two wolves..." or something:
Option 1: Sit down with them and go line by line through it. Make him identify each variable's purpose and then immediately find and replace to rename every instance with a more descriptive name.
Option 2: Small script to shuffle the variable names in his code around after each of his commits.
Declare result in the first line of the function and return result is the last line. In C++, this is a big hint to the compiler that you want return value optimization to kick in.
I've had instances where I worked with an API so badly designed in a dynamic language that I had no idea what I might receive.
This, when I get something back that's not what I expected, I just logged the type because I really don't know what it is. It's the result. Whatever that means.
Yup, I also do that. If I just need a variable to put in what will be returned, I call it result. What it means should be clear from the function name. Repeating that feels redundant.
GitHub doesn’t show types. So if the value is given to another function you would have no way of knowing what type it is unless you read the file that other function is declared in.
You declare it as the first line after "function getNextDay() : date {", then it is glaringly obvious that is a date variable that will (eventually) contain tomorrow's date, and will be returned by the function.
However, I would only use "var" if it's initialized in the same statement. It prevents Smurf code, and the compiler knows the type straight away.
Given a small and clean context, variable names don't need to be specific.