3 ms·

> For people who believe code isn't literature descriptive names are wasted characters. Data point: I do read code like books and I can't stand longAndMeaningf

by mtrn 10y ago

> For people who believe code isn't literature descriptive names are wasted characters. Data point: I do read code like books and I can't stand longAndMeaningful variable names. Rather, cut to the chase.

TuringTest 10y ago
What do you do if you find a section of code that solves a problem that you have never seen before? How do you decide what it's supposed to do, and whether it is doing it right or it has a bug?
TheOtherHobbes 10y ago
The chase being what? It takes no time at all to read a longAndMeaningful variable name, and no time at all to work out what it's doing. Assuming you don't name variables a1 to z256, calling a variable something like "items" makes it context dependent, which is a little too much like building state into the syntax. Long names provide an extra informal level of type safety. You should be able to see what a variable is doing by looking at it, and you should also be able to see that it provides a clean level of abstraction/composition instead of just being an arbitrary container with a label.
- Vinnl 10y ago
  I think it's somewhat of a middle ground. What I think hampers your ability to understand code, next to not knowing what variable names are supposed to mean, is not being able to easily discern variables from eachother, making you do double-takes while reading and thus making it more difficult to understand. If your code is littered with variables like longAndMeaningful and longAndWithMeaning and lengthyAndMeaningful etc, that becomes really annoying to read. And of course, there's a difference between longAndMeaninful and reallyVeryLongWindedAndExplicitButOhSoMeaninful. And let's not start about the FactoryFactoryBuilderEtc thingies.
kornakiewicz 10y ago
I'm now reading one book, in which author is using names for variable like "iep" (of type IfExpressionParser), or so. If the code is longer than ten or twenty lines I need to go back to the variable definition to make sure what it really is. Not convenient reading at all.

by mtrn 10y ago

TuringTest 10y ago

What do you do if you find a section of code that solves a problem that you have never seen before? How do you decide what it's supposed to do, and whether it is doing it right or it has a bug?

TheOtherHobbes 10y ago

The chase being what? It takes no time at all to read a longAndMeaningful variable name, and no time at all to work out what it's doing. Assuming you don't name variables a1 to z256, calling a variable something like "items" makes it context dependent, which is a little too much like building state into the syntax. Long names provide an extra informal level of type safety. You should be able to see what a variable is doing by looking at it, and you should also be able to see that it provides a clean level of abstraction/composition instead of just being an arbitrary container with a label.

Vinnl 10y ago
I think it's somewhat of a middle ground. What I think hampers your ability to understand code, next to not knowing what variable names are supposed to mean, is not being able to easily discern variables from eachother, making you do double-takes while reading and thus making it more difficult to understand. If your code is littered with variables like longAndMeaningful and longAndWithMeaning and lengthyAndMeaningful etc, that becomes really annoying to read. And of course, there's a difference between longAndMeaninful and reallyVeryLongWindedAndExplicitButOhSoMeaninful. And let's not start about the FactoryFactoryBuilderEtc thingies.

kornakiewicz 10y ago

I'm now reading one book, in which author is using names for variable like "iep" (of type IfExpressionParser), or so. If the code is longer than ten or twenty lines I need to go back to the variable definition to make sure what it really is. Not convenient reading at all.