4 ms·

> Maybe you might, but plenty of other people will not. I have also lied to myself and added "TODO" comments in some small projects I've worked on. So it was c

by yebyen 8y ago

> Maybe you might, but plenty of other people will not. I have also lied to myself and added "TODO" comments in some small projects I've worked on. So it was cheaper to leave the TODOs in the perfectly OK code, sounds like you dodged a bullet there. This strikes me as a slippery slope. Start with "@1 is not an appropriate way to represent this variable" then move onto "I actually don't like the name you've chosen" and finally arrive at "this code isn't important enough for me to take care of those TODOs I placed before I'm old and gray, remind me why are we even worried about how this variable is called, now renaming it for the _third time_?" I'll usually take a collection of "xs" and iterate over each "x" without any pretense that I'm coming back to make it better. We can agree to disagree, but I'm arguing that it's not any better to do that, and it's actually harder to grep for which makes it actively worse. This is a better option.

intertextuality 8y ago
> sounds like you dodged a bullet there. My point is that I never went back and fixed it, because often people do not do that. I, however, can still read that code perfectly fine and well because it has variable names. Not @1 and @2 for hashes, etc. > now renaming it for the _third time_?" Things get renamed from time to time (and less than you're making it out to be, typically). It's part of programming. You will be fine. It's better to be oh-so-inconvenienced than to have to read other peoples' codebases where they just use @1 and @2. Why have any variable names at all then? Just use 0-999, if it's so annoying to have to think for a few seconds to a minute and pick an apt name.
- yebyen 8y ago
  > I, however, can still read that code perfectly fine and well because it has variable names. Not @1 and @2 for hashes, etc. If I do {@1 + @2} exactly once is that really harder to read than {|x, y| x + y}? If I'm doing it everywhere all over my code, sure that's a problem and it will make unreadable garbage. But then again it was already possible to make unreadable garbage code.
  - intertextuality 8y ago
    In real code with actual logic (not simplified examples like here) the inner variables are typically not named |x, y|. |key, value| (or |k, v|) is one common shorthand, but even those -immediately- denote more semantic meaning than |@1, @2|. Usually something is being mapped over, or being selected/filtered etc, with a context, so it's useful to have something like |course|, |report|, or |course_name, course_values|, especially for people-who-are-not-me that may be reading the code. The issue here is that @1 and @2 make it much, much easier to write garbage code. At least with named vars you explicitly have to acknowledge that you're choosing a bad name. @1 makes it so you don't even have to think about it at all. This is a flagrant issue, and doesn't belong in Ruby at all.
    - yebyen 8y ago
      {} is for one-liner blocks, stylistically speaking. I occasionally use it for a longer block without refactoring it into a method (and line-breaks are permitted for sure), but typically if the one-liner is above a single line's worth of complexity, it's already on its way to becoming a method. "In real code with actual logic" this would be a "do-block" or you're violating another stylistic rule, and none of the examples I've seen use numbered parameters with a do-block. Is it allowed? I feel like this is important information that I need to know before I can make a fair judgment about whether this is a "flagrant issue" or not. Do-blocks with numbered parameters, if it is an allowed way to write a block, would definitely be a terrible idea. But I don't think it is, I can't find a source that says so, since all of the results for "numbered parameters" seem to be rants against the inclusion of this feature. Have you ever read bikeshed.com? Because that's exactly what we're doing right now.
      - intertextuality 8y ago
        Even for one liners I think it's a bad idea. It's not that tough to do .map{ |course| course.some_method + some_str } instead of .map { @1.some_method + some_str }. The latter is extremely ugly and does not belong in Ruby whatsoever. I'm not budging on this.
jimbokun 8y ago
"I'll usually take a collection of "xs" and iterate over each "x" without any pretense that I'm coming back to make it better." Those can be perfectly fine names! xs indicates you are writing a generic method or function applicable to just about any kind of collection, and x is an item in xs. So for functions like map and reduce or anything else that deals with arbitrary collections, these names are very clear in expressing the intent and far better than @1, etc. This is similar to using "i" as the index variable in a for loop, an almost universally recognized convention.

by yebyen 8y ago

intertextuality 8y ago

> sounds like you dodged a bullet there. My point is that I never went back and fixed it, because often people do not do that. I, however, can still read that code perfectly fine and well because it has variable names. Not @1 and @2 for hashes, etc. > now renaming it for the _third time_?" Things get renamed from time to time (and less than you're making it out to be, typically). It's part of programming. You will be fine. It's better to be oh-so-inconvenienced than to have to read other peoples' codebases where they just use @1 and @2. Why have any variable names at all then? Just use 0-999, if it's so annoying to have to think for a few seconds to a minute and pick an apt name.

yebyen 8y ago
> I, however, can still read that code perfectly fine and well because it has variable names. Not @1 and @2 for hashes, etc. If I do {@1 + @2} exactly once is that really harder to read than {|x, y| x + y}? If I'm doing it everywhere all over my code, sure that's a problem and it will make unreadable garbage. But then again it was already possible to make unreadable garbage code.
- intertextuality 8y ago
  In real code with actual logic (not simplified examples like here) the inner variables are typically not named |x, y|. |key, value| (or |k, v|) is one common shorthand, but even those -immediately- denote more semantic meaning than |@1, @2|. Usually something is being mapped over, or being selected/filtered etc, with a context, so it's useful to have something like |course|, |report|, or |course_name, course_values|, especially for people-who-are-not-me that may be reading the code. The issue here is that @1 and @2 make it much, much easier to write garbage code. At least with named vars you explicitly have to acknowledge that you're choosing a bad name. @1 makes it so you don't even have to think about it at all. This is a flagrant issue, and doesn't belong in Ruby at all.
  - yebyen 8y ago
    {} is for one-liner blocks, stylistically speaking. I occasionally use it for a longer block without refactoring it into a method (and line-breaks are permitted for sure), but typically if the one-liner is above a single line's worth of complexity, it's already on its way to becoming a method. "In real code with actual logic" this would be a "do-block" or you're violating another stylistic rule, and none of the examples I've seen use numbered parameters with a do-block. Is it allowed? I feel like this is important information that I need to know before I can make a fair judgment about whether this is a "flagrant issue" or not. Do-blocks with numbered parameters, if it is an allowed way to write a block, would definitely be a terrible idea. But I don't think it is, I can't find a source that says so, since all of the results for "numbered parameters" seem to be rants against the inclusion of this feature. Have you ever read bikeshed.com? Because that's exactly what we're doing right now.
    - intertextuality 8y ago
      Even for one liners I think it's a bad idea. It's not that tough to do .map{ |course| course.some_method + some_str } instead of .map { @1.some_method + some_str }. The latter is extremely ugly and does not belong in Ruby whatsoever. I'm not budging on this.

jimbokun 8y ago

"I'll usually take a collection of "xs" and iterate over each "x" without any pretense that I'm coming back to make it better." Those can be perfectly fine names! xs indicates you are writing a generic method or function applicable to just about any kind of collection, and x is an item in xs. So for functions like map and reduce or anything else that deals with arbitrary collections, these names are very clear in expressing the intent and far better than @1, etc. This is similar to using "i" as the index variable in a for loop, an almost universally recognized convention.