5 ms·
> Meaningless names, like `x` or `fn`, require the programmer to understand and remember extra layers of context while reading code that uses them. Reading cod
by veltas 5y ago
> Meaningless names, like `x` or `fn`, require the programmer to understand and remember extra layers of context while reading code that uses them.
Reading code always requires context, which humans are actually very good at handling. And if you refuse to use short names where they suffice you will clutter the code. This feels like a false optimisation of our ability to handle context.
What's more readable/understandable?
/* Gets sum of numbers from 1 to n */
sum(n)
{
return n * (n + 1) / 2;
}
Or:
/* Gets sum of numbers from 1 to largestNumber */
sum(largestNumber)
{
return largestNumber * (largestNumber + 1) / 2;
}
Have mathematicians been wrong for hundreds of years by using short symbolic names for their different variables? Imagine what maths would be like today if they were told they needed to use long names every to optimise 'context'.
- stinos 5y agoJust like with other design principles / best practices / ... this is context-dependent and there's a certain threshold wrt number of lines, number of variables, complexity of the function. Above which, in this case, n starts to lose its meaning and the OP's principle starts to make sense imo.
- ivanche 5y agoNow imagine your function is 50 lines long and has 9 variables inside. Ooops!
- veltas 5y ago"where they suffice" i.e. not always.
- TomSwirly 5y agoThe key idea is this: > require the programmer to understand and remember extra layers of context in sum(i for i in texts) I have no chance to forget what `i` is, but if I write: for i in texts: # A page of code without i in it. Then I'll just have no idea when I scroll down.
- lordgrenville 5y ago> Have mathematicians been wrong for hundreds of years by using short symbolic names for their different variables? To be fair most of that time they were optimising for writing in pen/chalk, where shorter names save a lot of work.
- mhink 5y agoI mean, you can come up with a silly example like `sum`, but here's a more real-world example (takes the width and height of a container, and calculates a scaling factor and translation which make an element fit inside the container at a target aspect ratio). const containerRatio = (containerWidth / containerHeight); const targetRatio = (targetWidth / targetHeight); const useVertical = (containerRatio > targetRatio); const scaleFactor = (isVertical ? (containerHeight / targetHeight) : (containerWidth / targetWidth) ); const scaledWidth = targetWidth * scaleFactor; const scaledHeight = targetHeight * scaleFactor; let x0 = 0; if (isVertical) { x0 = 0.5 * (containerWidth - scaledWidth); x0 /= (1 - scaleFactor); } let y0 = 0; if (!isVertical) { y0 = 0.5 * (containerHeight - scaledHeight); y0 /= (1 - scaleFactor); } return [[x0, y0], scalingFactor]; You could also write this as: const r = (w / h); const tr = (tw / th); const m = (r > tr ? (h / th) : (w / tw)); const o = [0, 0]; if (r > tr) { o[0] = (0.5 * (w - tw * m)) / (1 - m); } else { o[1] = (0.5 * (h - th * m)) / (1 - m); } return [o, m]; It's certainly terser (and I could have made it terser still), but the first example scans better IMO, because it breaks the expression evaluation down into steps which explain what the calculation is doing. If there was a problem with the second example, I'd have to more or less rewrite the logic myself into the first form in order to figure out what it was doing.
- ativzzz 5y agoOutside of super simple examples like your sum, I've come across multiple codebases written in C/C++ that look exactly like that with shorthand variables and function names, and it makes approaching the codebase nigh impossible without already having knowledge about the codebase.