You must log in or register to comment.
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.
The guy thinks in Excel.
When you are used to math equations, it’s easy to slip into that habit.
Single letter variables, yes. Reusing them? No.
Only if they are well-known in the language you’re using or domain you’re writing for.
xandyare fine for coordinates.iandjare fine for loop indices. But abbreviating things unnecessarily is bad IMO.s = GetSession()is too terse, for example.No, I mean single-letter vars are standard in physics and math, but reusing vars is not acceptable. Obviously they’re not good practice except in the scenarios you describe, but mathies gonna math.
Removed by mod
Length might have mattered in the 80s and 90s when IDEs were crap but we got autocomplete in pretty much all our text editors (even TUI ones like vim).
As for readability there is an argument to be had in specific contexts, but 9 out of 10 times it makes more sense to use a proper word.
Example:
let list = [1, 2, 3]; for i in list { println!("{}", i); }In this case using
itemin the place ofiwould be more fitting.
Maybe they had a background in low-level assembly code? If you’re writing assembly that’s kinda sorta how you’d handle registers.
“result” is fine. That is the variable you will end up returning that you have to fill with stuff first.
“data” on the other hand…
I came here to say this.
Declare
resultin the first line of the function andreturn resultis the last line. In C++, this is a big hint to the compiler that you want return value optimization to kick in.
As a person who victimizes coworkers like this, I apologize. Thank you for pointing it out, and I will stop doing it.
Be proud that it’s a step up from var x
Be scared that your coworkers are planning how to best apply the baseball bat to your knees anyway
Even using absolute best prackies, developers are gonna find a bunch of stuff to complain about.
Well obviously it’s the result of some algorithm that will happen.
function algorithm(input)
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.
It could be that this is a habit left over from pascal, where result is a reserved word, and is automatically made the return value of the function.
If it is in the context of a short function, I don’t see that it’s all that bad.
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.
I’m good with this in C#
Exactly. If it’s a statically typed language and the function has a clear name? I know what type it is, I know what it’s for, I’m good.
There are far worse sins, like intermediate variables or worse, public class members named “obj” or “data”.
deleted by creator
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.
As someone who uses ‘result’ as a variable name in functions all the time, please tell me what you think is wrong with it?
If a function is called for example ‘transformAtoB’ it should be totally obvious what the variable will contain.
It’s not necessarily bad, it just provides very little information.
The only issue is “var”.
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.
yah because we’d rather die than use return type hints.
