5 ms·

We break everything down and then we reach one of the most difficult problems in software engineering: Coming up with good and short names for all these extra i

We break everything down and then we reach one of the most difficult problems in software engineering: Coming up with good and short names for all these extra intermediate variables and functions.

zhte415 4y ago
Just be consistent, whatever it is.
jstimpfle 4y ago
Typically, relatively unspecific names like "i" or "size" are good enough. It's better than not naming at all and producing a complicated expression tree instead. More specific names cost energy, both inventing and reading them (because they are typically longer). Err on the side of short and not too specific.
- leetcrew 4y ago
  in most situations, I would rather see a complicated statement split over several lines than several simple statements with vague/unhelpful variable names. if the variable name itself doesn't help me understand what it means, I have to remember the full expression anyway.
- kevin_thibedeau 4y ago
  It depends. Go spelunking through old Unix and Gnu code from the 80s and you'll see a lot of maddening usage of single and double letter variables all over the place where a descriptive name would make things much more readable.
  - Teckla 4y ago
    Or go spelunking through modern Go code. Variable names that are so terse it hinders reading and comprehension.
mixedCase 4y ago
It takes some deliberate practice and being able to create decent contexts within your code. It's not a trivial problem but it's not a hard one. It's just that most people don't even try to dedicate a sliver of active brain power to the task because they don't deem it worth it even if they claim to agree on the importance of readability.
mike_hock 4y ago
Yes, and a source file littered with tiny helper functions that do very specific things and don't make any sense except in the precise context in which they get called, isn't necessarily more readable. Here, "query_params" means "extract the last three query parameters, raw (i.e. not unescaped and not broken into key-value pairs)." The transformation shown makes precisely nothing more readable or easy to understand. "The second argument to map()" is just as easy for your brain to group into a black box to be analyzed later as a call to an opaque "query_params" function that you need to read the implementation of to really understand what the code is actually doing. Of course sometimes it's the best solution to just extract local helper functions, especially if the actual function just becomes too unwieldy and/or the helpers are called from more than one place, but in general I try to extract things that do something more general than the thing I'm extracting it from and have an interface / a purpose that's easy to understand and describe on its own. To stay with the example, actually extracting the query parameters would be a generic, extractable utility. Half-extracting the last three parameters because the function I'm writing needs precisely that for some reason, is a local helper function, and I'd only extract it if there's a good reason, certainly not to make an already trivial function no easier to read.
- lbriner 4y ago
  I wouldn't attack the example too much, it does seem a little contrived to make the point - the very thing I don't like about contriving examples! It is hard to know whether the principle is valuable with such a weird example. In this example there are lots of other ways it could have been done more meaningfully but, again, don't know if the example is real.
  - mike_hock 4y ago
    What doesn't generalize is that the example doesn't necessarily stand for a simple one-liner, but as an example it has to be trivial, of course. But everything else generalizes. I took "splitting out the last 3 params" to mean "doing something very specific to the problem at hand" and extracting that isn't _always_ better.
- overgard 4y ago
onion2k 4y ago
short names You don't really need short names. I wouldn't advocate going full Java naming but trying to compress names just to save a bit of typing is unnecessary. Your IDE will help you out. Just learn to press tab when you've entered enough of the name instead of typing the whole thing.
- patrick451 4y ago
  Short names are easier to read, because they fit on fewer lines. Doubly so if the statement fits on one line.
  - onion2k 4y ago
    Shorter names aren't easier to read if you have several similar names used in close proximity. More characters can reduce the congruence and make it easier to differtiate between names. I agree about fitting things onto one line though. It's usually better to break things up into to several short one line steps rather than have a long multi line statement.
    - philipwhiuk 4y ago
      I tend to think length should be proportionate to broadness of usage within the file/project If it's used in lots of places, go for MAXIMUM_MONSTER_DENSITY_SCORE_MULTIPLIER If it's used in a single file/function, then maxDensityMultiplier might be okay. (You can infer the rest from context). If it's used in a very confined section, then multiplier. If it's a loop variable then, sure use m.
    - ziml77 4y ago
      More characters can make it harder to differentiate names. The longer the name is, the harder it is to see it as a single unit while reading. Also, if the long names cause many extra lines, it becomes easier to lose context from the extra distance one moves down the document while reading.
      - Shorel 4y ago
nicwolff 4y ago
Crisis == opportunity ツ TFA missed the point of splitting complex expressions into separate lines: naming the single-use vars clearly makes the whole calculation easy to follow. In the example given, nothing about the one-line `map split over split of split` tells a reader that it's parsing a query string – just splitting it in two and naming the temp var `query_params` makes it clear. Although `last_3_query_params` would be more precise, and something that explains why TF you'd want that would be better... ツ
quickthrower2 4y ago
React makes it funner. [score, setScore] = useState … means you gotta think of another name for any intermediate “score”-like sub calculations in all the scope levels of the functional component. (Or yuk keep track of the scope you are in mentally). Then throw the firebase api on top of that with it’s myriad intermediate step api and fun fun fun.

We break everything down and then we reach one of the most difficult problems in software engineering: Coming up with good and short names for all these extra intermediate variables and functions.

zhte415 4y ago

Just be consistent, whatever it is.

jstimpfle 4y ago

Typically, relatively unspecific names like "i" or "size" are good enough. It's better than not naming at all and producing a complicated expression tree instead. More specific names cost energy, both inventing and reading them (because they are typically longer). Err on the side of short and not too specific.

leetcrew 4y ago
in most situations, I would rather see a complicated statement split over several lines than several simple statements with vague/unhelpful variable names. if the variable name itself doesn't help me understand what it means, I have to remember the full expression anyway.
kevin_thibedeau 4y ago
It depends. Go spelunking through old Unix and Gnu code from the 80s and you'll see a lot of maddening usage of single and double letter variables all over the place where a descriptive name would make things much more readable.
- Teckla 4y ago
  Or go spelunking through modern Go code. Variable names that are so terse it hinders reading and comprehension.

mixedCase 4y ago

It takes some deliberate practice and being able to create decent contexts within your code. It's not a trivial problem but it's not a hard one. It's just that most people don't even try to dedicate a sliver of active brain power to the task because they don't deem it worth it even if they claim to agree on the importance of readability.

mike_hock 4y ago

Yes, and a source file littered with tiny helper functions that do very specific things and don't make any sense except in the precise context in which they get called, isn't necessarily more readable. Here, "query_params" means "extract the last three query parameters, raw (i.e. not unescaped and not broken into key-value pairs)." The transformation shown makes precisely nothing more readable or easy to understand. "The second argument to map()" is just as easy for your brain to group into a black box to be analyzed later as a call to an opaque "query_params" function that you need to read the implementation of to really understand what the code is actually doing. Of course sometimes it's the best solution to just extract local helper functions, especially if the actual function just becomes too unwieldy and/or the helpers are called from more than one place, but in general I try to extract things that do something more general than the thing I'm extracting it from and have an interface / a purpose that's easy to understand and describe on its own. To stay with the example, actually extracting the query parameters would be a generic, extractable utility. Half-extracting the last three parameters because the function I'm writing needs precisely that for some reason, is a local helper function, and I'd only extract it if there's a good reason, certainly not to make an already trivial function no easier to read.

lbriner 4y ago
I wouldn't attack the example too much, it does seem a little contrived to make the point - the very thing I don't like about contriving examples! It is hard to know whether the principle is valuable with such a weird example. In this example there are lots of other ways it could have been done more meaningfully but, again, don't know if the example is real.
- mike_hock 4y ago
  What doesn't generalize is that the example doesn't necessarily stand for a simple one-liner, but as an example it has to be trivial, of course. But everything else generalizes. I took "splitting out the last 3 params" to mean "doing something very specific to the problem at hand" and extracting that isn't _always_ better.
overgard 4y ago

onion2k 4y ago

short names You don't really need short names. I wouldn't advocate going full Java naming but trying to compress names just to save a bit of typing is unnecessary. Your IDE will help you out. Just learn to press tab when you've entered enough of the name instead of typing the whole thing.

patrick451 4y ago
Short names are easier to read, because they fit on fewer lines. Doubly so if the statement fits on one line.
- onion2k 4y ago
  Shorter names aren't easier to read if you have several similar names used in close proximity. More characters can reduce the congruence and make it easier to differtiate between names. I agree about fitting things onto one line though. It's usually better to break things up into to several short one line steps rather than have a long multi line statement.
  - philipwhiuk 4y ago
    I tend to think length should be proportionate to broadness of usage within the file/project If it's used in lots of places, go for MAXIMUM_MONSTER_DENSITY_SCORE_MULTIPLIER If it's used in a single file/function, then maxDensityMultiplier might be okay. (You can infer the rest from context). If it's used in a very confined section, then multiplier. If it's a loop variable then, sure use m.
  - ziml77 4y ago
    More characters can make it harder to differentiate names. The longer the name is, the harder it is to see it as a single unit while reading. Also, if the long names cause many extra lines, it becomes easier to lose context from the extra distance one moves down the document while reading.
    - Shorel 4y ago

nicwolff 4y ago

Crisis == opportunity ツ TFA missed the point of splitting complex expressions into separate lines: naming the single-use vars clearly makes the whole calculation easy to follow. In the example given, nothing about the one-line `map split over split of split` tells a reader that it's parsing a query string – just splitting it in two and naming the temp var `query_params` makes it clear. Although `last_3_query_params` would be more precise, and something that explains why TF you'd want that would be better... ツ

quickthrower2 4y ago

React makes it funner. [score, setScore] = useState … means you gotta think of another name for any intermediate “score”-like sub calculations in all the scope levels of the functional component. (Or yuk keep track of the scope you are in mentally). Then throw the firebase api on top of that with it’s myriad intermediate step api and fun fun fun.