4 ms·

I'm clueless about ruby. Never learned it. But this makes me cringe (obviously I'm coming from a different context, but is this really a good idea? And who want

I'm clueless about ruby. Never learned it. But this makes me cringe (obviously I'm coming from a different context, but is this really a good idea? And who wants to have a table like this?) .. >The length of an identifier determines its scope. Use one-letter variables for short block/method parameters, according to this scheme: a,b,c: any object d: directory names e: elements of an Enumerable ex: rescued exceptions f: files and file names i,j: indexes k: the key part of a hash entry m: methods o: any object r: return values of short methods s: strings v: any value v: the value part of a hash entry x,y,z: numbers

jameskilton 15y ago
I'm a heavy Ruby user and I've never seen or heard of this until now. The rest of the document is pretty close to what I follow, but this one is theirs and theirs alone.
- nplusone 15y ago
  This Ruby style guide is based on https://github.com/chneukirchen/styleguide/blob/master/RUBY-STYLE https://github.com/chneukirchen/styleguide/blob/master/RUBY-... , as stated in the introductory paragraph. That style guide also contains these conventions for one-letter variable names. Many others have forked this guide and made modifications according to their tastes.
michaelchisari 15y ago
In the past, I've used naming methods like this, and at first, it seemed really intuitive. But it becomes unnecessarily dense over time, and often results in awkward readability. I've moved instead to simply using reasonably descriptive variable names where the type is easily inferred. The extra type information isn't missed. sZipCode = "90210" really isn't necessary. Instead: zipCode = "90210" works just fine. And leaving out the type information for a variable with no repercussions is 95% of use cases for variables.
- baha_man 15y ago
  No, you're talking about Hungarian notation, the guide is talking about standardised one-letter names for certain variables.
  - michaelchisari 15y ago
    The way I'm reading it, they're casting a wider net than Hungarian notation, but it's similar to it.
    - pbreit 15y ago
      It seems pretty clear to me: "Use one-letter variables"
      - michaelchisari 15y ago
        On re-reading, you're right. My fault for giving them the benefit of the doubt. One letter variables? I'm a little bit speechless. I don't recommend one letter variables. I don't know if I've ever seen an official style guide that has.
        adbge 15y ago
        > I don't recommend one letter variables. I don't know if I've ever seen an official style guide that has. Not that familiar with idiomatic Ruby, but using one letter variables as iterators in for loops (and some other things) is pretty idiomatic C: int i; for (i = 0; i < queue_size; i++) queue[i] = get_rarest_peer(t->peer_list);
        kshipley 15y ago
        The key modifying phrase was "for short block/method parameters." The authors aren't advocating one letter variables throughout your code, only in situations like: [1, 2, 3].each { |e| puts e } Object.methods.each { |m| "Method is: #{m}" }
bphogan 15y ago
Interestingly enough, some of the entries in this list are the conventions I tend to use for "short block level params." If you're not used to Ruby, here's an example of what he's referring to: To work with the keys and values of a hash (dictionary / associative array) I use the .each method on the hash itself. The .each method gives me access to the key and value of each entry in the hash. hash = {"name => "Homer", "age" => 42} hash.each{|k, v| puts k + " " + v} Where 'k' is key, and 'v' is value. I never really gave much thought to "standardizing" this.
- randomdata 15y ago
  As far as I am concerned, the full name is more readable. A few keystrokes mean nothing in the grand scheme of things. Readable code does. hash.each { |key,value| puts "#{key} #{value}" }
  - bphogan 15y ago
    It's all about style. Which is what makes it really interesting. In your implementation you used string interpolation, a different kind of shortcut. And in my example, I used + to make it more readable for the parent poster who said they weren't familiar with Ruby. Interesting how "more readable" is somewhat objective, isn't it?
    - randomdata 15y ago
      I chose interpolation in this example because I found the lack of any break character between the method and the variable to not read well. puts k + " " + v Does that execute as puts(k) + " " + v, puts(k + " ") + v or any other combination? While those of us familiar with Ruby know the answer, I would still argue that it takes greater cognitive resources to evaluate over the single string, especially in the presence of a syntax highlighting editor who clearly defines the string boundaries in colour. You are right that it is definitely subjective. Coding is user interface design, but we don't usually have the luxury of processes like A/B testing to validate our work like other interface designers do. It would be interesting to put both of our code samples along with some other variations in front of an audience and see how they are received.

jameskilton 15y ago

I'm a heavy Ruby user and I've never seen or heard of this until now. The rest of the document is pretty close to what I follow, but this one is theirs and theirs alone.

nplusone 15y ago
This Ruby style guide is based on https://github.com/chneukirchen/styleguide/blob/master/RUBY-STYLE https://github.com/chneukirchen/styleguide/blob/master/RUBY-... , as stated in the introductory paragraph. That style guide also contains these conventions for one-letter variable names. Many others have forked this guide and made modifications according to their tastes.

michaelchisari 15y ago

In the past, I've used naming methods like this, and at first, it seemed really intuitive. But it becomes unnecessarily dense over time, and often results in awkward readability. I've moved instead to simply using reasonably descriptive variable names where the type is easily inferred. The extra type information isn't missed. sZipCode = "90210" really isn't necessary. Instead: zipCode = "90210" works just fine. And leaving out the type information for a variable with no repercussions is 95% of use cases for variables.

baha_man 15y ago
No, you're talking about Hungarian notation, the guide is talking about standardised one-letter names for certain variables.
- michaelchisari 15y ago
  The way I'm reading it, they're casting a wider net than Hungarian notation, but it's similar to it.
  - pbreit 15y ago
    It seems pretty clear to me: "Use one-letter variables"
    - michaelchisari 15y ago
      On re-reading, you're right. My fault for giving them the benefit of the doubt. One letter variables? I'm a little bit speechless. I don't recommend one letter variables. I don't know if I've ever seen an official style guide that has.
      - adbge 15y ago
        > I don't recommend one letter variables. I don't know if I've ever seen an official style guide that has. Not that familiar with idiomatic Ruby, but using one letter variables as iterators in for loops (and some other things) is pretty idiomatic C: int i; for (i = 0; i < queue_size; i++) queue[i] = get_rarest_peer(t->peer_list);
      - kshipley 15y ago
        The key modifying phrase was "for short block/method parameters." The authors aren't advocating one letter variables throughout your code, only in situations like: [1, 2, 3].each { |e| puts e } Object.methods.each { |m| "Method is: #{m}" }

bphogan 15y ago

Interestingly enough, some of the entries in this list are the conventions I tend to use for "short block level params." If you're not used to Ruby, here's an example of what he's referring to: To work with the keys and values of a hash (dictionary / associative array) I use the .each method on the hash itself. The .each method gives me access to the key and value of each entry in the hash. hash = {"name => "Homer", "age" => 42} hash.each{|k, v| puts k + " " + v} Where 'k' is key, and 'v' is value. I never really gave much thought to "standardizing" this.

randomdata 15y ago
As far as I am concerned, the full name is more readable. A few keystrokes mean nothing in the grand scheme of things. Readable code does. hash.each { |key,value| puts "#{key} #{value}" }
- bphogan 15y ago
  It's all about style. Which is what makes it really interesting. In your implementation you used string interpolation, a different kind of shortcut. And in my example, I used + to make it more readable for the parent poster who said they weren't familiar with Ruby. Interesting how "more readable" is somewhat objective, isn't it?
  - randomdata 15y ago
    I chose interpolation in this example because I found the lack of any break character between the method and the variable to not read well. puts k + " " + v Does that execute as puts(k) + " " + v, puts(k + " ") + v or any other combination? While those of us familiar with Ruby know the answer, I would still argue that it takes greater cognitive resources to evaluate over the single string, especially in the presence of a syntax highlighting editor who clearly defines the string boundaries in colour. You are right that it is definitely subjective. Coding is user interface design, but we don't usually have the luxury of processes like A/B testing to validate our work like other interface designers do. It would be interesting to put both of our code samples along with some other variations in front of an audience and see how they are received.