6 ms·
I thought the whole single-char-var thing was for very short-lived variables. I very much prefer for c in internalProductCategories p = fetchProduc
by libria 7y ago
I thought the whole single-char-var thing was for very short-lived variables.
I very much prefer
for c in internalProductCategories
p = fetchProductsInCategory(c.id)
m = getAccountManagerName(c.id)
results.append({categoryName: c.name, products: p, manager: m.name})
to
for internalProductCategory in internalProductCategories
products = fetchProductsInCategory(internalProductCategory.id)
manager = getAccountManagerName(internalProductCategory.id)
results.append({categoryName: internalProductCategory.name, products: products, manager: manager.name})
They're both clear, neither needs comments, but one is unnecessarily verbose.
- Kaze404 7y agoThe latter requires you to read the assignment to figure out what the variables mean.
- ludamad 7y agoThis is true, it is classic data denormalization - in the latter example, if all we want to gloss is the results appending, we need to read less
- Silhouette 7y agoOn the other hand, the former is much more scannable, so maybe that doesn't matter.
- Kaze404 7y agoI don't understand what this means.
- Silhouette 7y agoJust that the shorter names make for a more concise presentation, which in turn is quicker to scan than having to see and parse all the long names to reach the same conclusion.
- ysavir 7y agoWhile that's definitely better than single letter variables everywhere, I still think an explicit variable name is better. In general, I follow a rule of "If I can't search the file for this variable and find it easily, it's a bad name".
- Silhouette 7y agoIsn't this the standard argument for making names more specific as the scope where they are visible gets larger? Something only used within a short function, so it only ever appears within a few lines of where it's defined, can probably be very short or even a single letter, and that conciseness can be beneficial. Something used elsewhere in a file should probably have a more descriptive name, so it can be easily distinguished and located. Something exported from a module and used elsewhere in the program should probably have both the more descriptive element and then, one way or another, some further way to identify that it's the version from that particular module that is being used.
- ysavir 7y agoI get what the argument is saying, but there might still be times where I want to find every mention of a variable within a 3-line block. If that variable is a single letter, and possibly a letter that's used 10-20 times in the code in that block, I would consider that block confusing. Ultimately, I don't think there's any hard rule or standard, just an evaluation of how easy it is to understand the code. Sometimes a single-letter variable will be fine, sometimes not. But I'd bet a 4-letter variable will always lead to code that is easier to understand.
- karmakaze 7y agoWhat if the references are all [i] or [i + 1]?
- Red_Leaves_Flyy 7y agoPut a comment block at eof defining them and their usage. Use these variables in such a way that ctrl,f replace all with a descriptive name doesn't break anything except the line count and pretty print. If you want to get really clever, write a script that automatically renames everything and reflows the file on commit. Damn it. Now I need to make this...
- deleted 7y ago[deleted]
- ppeetteerr 7y agoStrongly disagree there. If there was a crash at line 4, in the first example you would only see this: > results.append({categoryName: c.name, products: p, manager: m.name}) In the second example you would see this: > results.append({categoryName: internalProductCategory.name, products: products, manager: manager.name}) Do you know what the error would be? Probably that you're assigning the manager's name to a property called `manager` ;)