3 ms·

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 sh

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.
    - intertextuality 8y ago
      In that example, fair enough. However often one unpacks a tuple or operates on a hash, where it's not immediately obvious what the inner values are. So we can bikeshed if you want, but I still think it's a bad idea (and looks very ugly).
    - jimbokun 8y ago
      "But I disagree that it's the responsibility of the language to keep potentially dangerous tools out of the hands of developers." That is pretty much entirely the point of higher level programming languages. Like preventing you from allocating and freeing memory on your own, because you might screw it up. Or removing pointer arithmetic. Or reducing the scope of mutability. Or preventing access to "private" object variables. Many programming language features are basically guards to make it less likely you cut your hand off.
      - 8y ago

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.
  - intertextuality 8y ago
    In that example, fair enough. However often one unpacks a tuple or operates on a hash, where it's not immediately obvious what the inner values are. So we can bikeshed if you want, but I still think it's a bad idea (and looks very ugly).
  - jimbokun 8y ago
    "But I disagree that it's the responsibility of the language to keep potentially dangerous tools out of the hands of developers." That is pretty much entirely the point of higher level programming languages. Like preventing you from allocating and freeing memory on your own, because you might screw it up. Or removing pointer arithmetic. Or reducing the scope of mutability. Or preventing access to "private" object variables. Many programming language features are basically guards to make it less likely you cut your hand off.
    - 8y ago