9 ms·

> it's not reasonable to argue that your code should always be in the optimal state. This is a strawman and not what I believe. I never said your codebase shou

> it's not reasonable to argue that your code should always be in the optimal state. This is a strawman and not what I believe. I never said your codebase should always be optimal in every way. I believe @1 instead of even the most basic of variable names is actively an anti-pattern. > That's the kind of thing that I'd search for in my codebase before I closed the project, and assign a name before it's too late for me to remember what that bit of code was for. 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. Months and years later I sometimes see "TODO" comments because I ended up working on something else or forgot. It's simply way too easy to not go back and refactor or fix things. There is nothing more permanent than temporary code. Sometimes you have to go back and rename things multiple times. This is vastly better than what you know full well will happen: People will immediately gravitate towards the easiest option of @1, and then never change it because they've moved onto other parts of the code or different projects, etc. We should not be adding ugly, terse syntax to programming languages because it's "just more convenient" to not name things. That is not a tenable argument for a permanent change to a mature language. Being lazy is not an argument.

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.
kazinator 8y ago
You can see all the TODO comments if you choose to; they are a grep away.
- intertextuality 8y ago
  Of course I can. That doesn't mean I actually will go back and fix them. TODO statements are little lies that programmers tell themselves. "I'll go back and fix this/refactor it, yeah, yeah...". And most of the time, that doesn't happen.

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.

kazinator 8y ago

You can see all the TODO comments if you choose to; they are a grep away.

intertextuality 8y ago
Of course I can. That doesn't mean I actually will go back and fix them. TODO statements are little lies that programmers tell themselves. "I'll go back and fix this/refactor it, yeah, yeah...". And most of the time, that doesn't happen.