3 ms·

> 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

> 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.
      - yebyen 8y ago
        You can keep your opinion, I don't need to spend any more time trying to convince you, but to be pedantic one last time, you omitted the part of that snippet that would have made it clear the named parameter is not needed and unnecessarily verbose: courses.map{|course| course.some_method + some_str} is unabashedly and unnecessarily verbose, I know it's a course as it's from courses. No need to repeat yourself twice. courses.map{@1.some_method + some_str} by comparison is perfectly clear, once you know the syntax. Edit: I just installed ruby-2.7-head and I made a typo, first thought it is not permitted in a do-block. It is. I think it's bad to use this in a do-block. But like I said, there are already plenty of ways to make your code into unreadable garbage, it's up to the author to make a good decision. Some programmers will choose poorly no matter how hard you try to prevent it. In my opinion, this syntax is for one-liner blocks only. You should avoid using tools in incorrect ways, and code that has numbered parameters strewn everywhere without any attention to naming, is guaranteed to have more than just one bad code smell in it. But I disagree that it's the responsibility of the language to keep potentially dangerous tools out of the hands of developers.
- jimbokun 8y ago
  "If I do {@1 + @2} exactly once is that really harder to read than {|x, y| x + y}?" It's certainly no easier. "{|x, y| x + y}" immediately clearly conveys "this is a block taking exactly two arguments and returns their sum". Adding syntax for "@1 + @2" adds an entirely new construct for every Ruby programmer to learn and recognize as a pattern, in addition to the full block syntax form, and their brains to be able to switch between pattern matching for either pattern to quickly parse what the code is doing. All for zero benefits. String enough of these arbitrarily different syntactic variants for the exact same thing, and you end up with C++.
  - intertextuality 8y ago
    You also lose information, because @1 and @2 magically appear. With || notation you have to explicitly spell out, beforehand, exactly how many variables will be in the block. tuple.collect{ |x,y,z| [x * 3, y * 3, z * 3] } is better than tuple.collect{ [@1 * 3, @2 * 3, @3 * 3] } because with the latter, I need to know in my head that there will be three parameters. The more I read about this syntax the worse I feel about it.
    - yebyen 8y ago
      I don't buy this argument. This is syntactically valid ruby, current state: tuple.collect{ |x,y,z| [x * 3, y * 3] } and so is this: tuple.collect{ |y,z| [x * 3, y * 3, z * 3] } The last one will generate a runtime error (unless "x" is already defined in the closed-over scope the block exists inside of, in that case it might be valid and correct.) But both are valid Ruby expressions. Neither are less inscrutable than: tuple.collect{ [@1 * 3, @2 * 3, @3 * 3] } This expression will return nil for @3 if only two arguments are passed in, again it's a perfectly valid Ruby expression, and you'll get a runtime error from inside of the block in this case, just like the pre-existing standard block syntaxes. It's up to the author of the code to create readable constructions that aren't misleading or confusing. There's no reason why this tool is innately bad, more tools can only make it more likely that the author will find an expressive and clear way to say exactly what they're doing without writing something confusing or redundant. From a language purist perspective, these are all very good reasons not to use Ruby at all. I don't think that adding numbered positional params makes it worse in any objective sense.

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.
    - yebyen 8y ago
      You can keep your opinion, I don't need to spend any more time trying to convince you, but to be pedantic one last time, you omitted the part of that snippet that would have made it clear the named parameter is not needed and unnecessarily verbose: courses.map{|course| course.some_method + some_str} is unabashedly and unnecessarily verbose, I know it's a course as it's from courses. No need to repeat yourself twice. courses.map{@1.some_method + some_str} by comparison is perfectly clear, once you know the syntax. Edit: I just installed ruby-2.7-head and I made a typo, first thought it is not permitted in a do-block. It is. I think it's bad to use this in a do-block. But like I said, there are already plenty of ways to make your code into unreadable garbage, it's up to the author to make a good decision. Some programmers will choose poorly no matter how hard you try to prevent it. In my opinion, this syntax is for one-liner blocks only. You should avoid using tools in incorrect ways, and code that has numbered parameters strewn everywhere without any attention to naming, is guaranteed to have more than just one bad code smell in it. But I disagree that it's the responsibility of the language to keep potentially dangerous tools out of the hands of developers.
jimbokun 8y ago
"If I do {@1 + @2} exactly once is that really harder to read than {|x, y| x + y}?" It's certainly no easier. "{|x, y| x + y}" immediately clearly conveys "this is a block taking exactly two arguments and returns their sum". Adding syntax for "@1 + @2" adds an entirely new construct for every Ruby programmer to learn and recognize as a pattern, in addition to the full block syntax form, and their brains to be able to switch between pattern matching for either pattern to quickly parse what the code is doing. All for zero benefits. String enough of these arbitrarily different syntactic variants for the exact same thing, and you end up with C++.
- intertextuality 8y ago
  You also lose information, because @1 and @2 magically appear. With || notation you have to explicitly spell out, beforehand, exactly how many variables will be in the block. tuple.collect{ |x,y,z| [x * 3, y * 3, z * 3] } is better than tuple.collect{ [@1 * 3, @2 * 3, @3 * 3] } because with the latter, I need to know in my head that there will be three parameters. The more I read about this syntax the worse I feel about it.
  - yebyen 8y ago
    I don't buy this argument. This is syntactically valid ruby, current state: tuple.collect{ |x,y,z| [x * 3, y * 3] } and so is this: tuple.collect{ |y,z| [x * 3, y * 3, z * 3] } The last one will generate a runtime error (unless "x" is already defined in the closed-over scope the block exists inside of, in that case it might be valid and correct.) But both are valid Ruby expressions. Neither are less inscrutable than: tuple.collect{ [@1 * 3, @2 * 3, @3 * 3] } This expression will return nil for @3 if only two arguments are passed in, again it's a perfectly valid Ruby expression, and you'll get a runtime error from inside of the block in this case, just like the pre-existing standard block syntaxes. It's up to the author of the code to create readable constructions that aren't misleading or confusing. There's no reason why this tool is innately bad, more tools can only make it more likely that the author will find an expressive and clear way to say exactly what they're doing without writing something confusing or redundant. From a language purist perspective, these are all very good reasons not to use Ruby at all. I don't think that adding numbered positional params makes it worse in any objective sense.