6 ms·

Ruby style guide

30 points by r11t 18y ago

bazookaaa 18y ago
This is the second time in the past few days I've been told to use two spaces instead of tabs. Can anyone provide any insight as to what difference this makes?
- defunkt 18y ago
  Ian Macdonald puts it well: Unlike in some other communities, there is no contention in the Ruby community over whether to use two, four or eight spaces. Everyone is happy to use just two. Furthermore, never use tabs, which includes the practice of mixing tabs with spaces. That's not to say spaces are better than tabs, or two spaces are better than four spaces. Just that idiomatic Ruby code uses two spaces.
- joshuaxls 18y ago
  Tabs are not fixed-width. Tabs are interpreted by the viewing application according to that application's settings. Two spaces are always two spaces.
  - Xichekolas 18y ago
    Upvoted, but would like to add to bazookaaa: easiest way to change this habit is to set your editor to insert two spaces when you hit the tab key, that way you don't have to think about it ever again.
  - johnswamps 18y ago
    I've always viewed this as a plus for tabs. Personally, I think two spaces is too small. If I'm looking at someone's code and it's hardcoded to two space indentation, I'm screwed. But if it's using tabs, I can set it to whatever I want. Some people like 2, some 4, and some 8. I prefer to use tabs to denote logical indentation, and then space for formatting. But not many people agree with me, so I usually just use spaces.
    - joshuaxls 18y ago
      Generally I agree, but for the pedantic there are other issues. Tabs at the beginning of lines aren't a problem. But, for example, it's common to see multi-line declarations of, let's say, a hash where each line looks like this: key <tab> => <tab> value This might look perfectly fine for someone using 8-width tabs, but it will most likely be screwy for anyone using 4-width tabs or smaller. The tab's location is calculated as the distance where the cursor position modulo the tab width is 0. E.g. one key is 2 chars long and another is 5 chars long. You tabbed it using 8-width tabs. Looks fine. If someone loads it with 4-width tabs, they see the two lines aligned differently.
  - wildjim 18y ago
    I've heard all sorts of arguments for and against, but in the end it only matters that you consistently choose only tabs or spaces, and that you use whatever header-settings your IDE provides to enforce the decision across all the coders, e.g. for emacs: #!/usr/bin/ruby -w #-*- standard-indent: 2; indent-tabs-mode: nil; -*- [...]
swombat 18y ago
I'm not quite sure why this style guide is more noteworthy than all the other ruby style guides out there.. e.g.: http://www.caliban.org/ruby/rubyguide.shtml http://www.caliban.org/ruby/rubyguide.shtml and http://www.pathf.com/blogs/2008/10/elements-of-ruby-style/ http://www.pathf.com/blogs/2008/10/elements-of-ruby-style/
- defunkt 18y ago
  Christian is a very well known Ruby developer. I'd say having a noteworthy developer write a style guide is noteworthy.
  - tomjen 18y ago
    Well all it tells me is to stay out of his projects. Everybody knows that there is only _one_ space after a dot.
masonlee 18y ago
Hm. Use one letter variable names for scoped variables? Excerpt from lines 92-112: "* 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 And in general, the first letter of the class name if all objects are of that type."
- wildjim 18y ago
  This is explicitly disallowed within some companies...
azanar 18y ago
Do not program defensively. (See http://www.erlang.se/doc/programming_rules.shtml#HDR11. http://www.erlang.se/doc/programming_rules.shtml#HDR11.) I cross-referenced to the Erlang documentation, and they provided no other real justification for this rule, other than to say that the burden lies on the caller. Is there a history behind this convention? Is there a considerable benefit, other than more stream-lined code, to coding this way?
- troels 18y ago
  I suppose it's a duck-type thing. A strength of dynamic typing is that you don't need to anticipate all uses of your api. By allowing anything as input, you make things more flexible. For example, instead of assuming that a parameter should be a string, you should just treat it like a string and have the caller deal with the consequences if he passes something else. One positive effect of this is that validation/error handling code tends to be kept in a single place rather than scattered out over the model layer. I'm not sure if I completely buy in to this sentiment, but that's how I read it.
- DavidMcLaughlin 18y ago
  Firstly, it's basic DRY principles. Rather than have code dotted around your system dealing with data integrity issues, put it in one place and make your business logic more readable and easier to maintain. When trying to understand a subroutine or Class I should not have to wade through all the lines of code that try to make sure the input is 'safe.' Secondly, something I've noticed about defensive programming is that generally it creates a culture of "meta rules" that only exist in the system architect's head. When someone else reuses one of their models, then the danger is they don't know all these different rules because they are scattered around different controllers or scripts. This has been a particularly vicious source of bugs in our legacy systems. Domain experience becomes critical. Lastly, defensive programming by its nature is also traditionally a big red warning sign that says "there is no data integrity strategy in place for this system." It doesn't matter if that data is coming from a CRUD form, a relational database or a file... there should be some validation layer that ensures the data is 'correct' before making it 'safe' to reuse across the rest of the system. I've found that defensive programming is particularly rife in systems powered by MySQL databases. MySQL has traditionally lacked the data integrity mechanisms of Oracle or other Enterprisey systems and thus has created a whole bunch of MySQL 'experts' that actually don't know anything about data integrity. A system I'm working with this very minute has a function where the first 20 lines of code (out of 28 total) is compensating for potential orphan entries in the database. The reason? The admin tool for removing entries does not do cascading deletes. Rather than fix the root of the problem, we have this 20 line check everywhere that we need to access the data safely. I could go on and on, but in short: defensive programming is one of the major 'code smells.'
wildjim 18y ago
I really hate other people's style-guides. Most of it is common-sense, but there's always some aspect or another that really grates against my preferences, e.g. "Keep lines fewer than 80 characters" is a pet hate; when did we return to Green-screen terminals?? My current company enforces this, and it often creates worse multi-line dischord cf. adding an extra 10 to 20 char's to the current line. And "Read other style guides and apply the parts that don't dissent with this list" is a little too arrogant for any coder in the entire world -- perhaps should be "Replace any parts of this list that don't conform to your style".
- dhotson 18y ago
  Actually, I find limiting to ~80-100 chars makes code more readable. On a 24" screen I like to have 2-3 files open side by side. Having to scroll down is no big deal, scrolling sideways is pretty awkward. It also makes diffs harder to read if lines are too long. I certainly wouldn't argue for a hard limit of 80, but I find it's generally a good idea to break up lines if they're getting too long.
  - wildjim 18y ago
    That's kind-of the point: emphasis should be on readability, not "this long, and no longer!", and that applies to all points in any style-guide, i.e. it's a "guide" not a rule-book.

30 points by r11t 18y ago

This is the second time in the past few days I've been told to use two spaces instead of tabs. Can anyone provide any insight as to what difference this makes?

defunkt 18y ago
Ian Macdonald puts it well: Unlike in some other communities, there is no contention in the Ruby community over whether to use two, four or eight spaces. Everyone is happy to use just two. Furthermore, never use tabs, which includes the practice of mixing tabs with spaces. That's not to say spaces are better than tabs, or two spaces are better than four spaces. Just that idiomatic Ruby code uses two spaces.
joshuaxls 18y ago
Tabs are not fixed-width. Tabs are interpreted by the viewing application according to that application's settings. Two spaces are always two spaces.
- Xichekolas 18y ago
  Upvoted, but would like to add to bazookaaa: easiest way to change this habit is to set your editor to insert two spaces when you hit the tab key, that way you don't have to think about it ever again.
- johnswamps 18y ago
  I've always viewed this as a plus for tabs. Personally, I think two spaces is too small. If I'm looking at someone's code and it's hardcoded to two space indentation, I'm screwed. But if it's using tabs, I can set it to whatever I want. Some people like 2, some 4, and some 8. I prefer to use tabs to denote logical indentation, and then space for formatting. But not many people agree with me, so I usually just use spaces.
  - joshuaxls 18y ago
    Generally I agree, but for the pedantic there are other issues. Tabs at the beginning of lines aren't a problem. But, for example, it's common to see multi-line declarations of, let's say, a hash where each line looks like this: key <tab> => <tab> value This might look perfectly fine for someone using 8-width tabs, but it will most likely be screwy for anyone using 4-width tabs or smaller. The tab's location is calculated as the distance where the cursor position modulo the tab width is 0. E.g. one key is 2 chars long and another is 5 chars long. You tabbed it using 8-width tabs. Looks fine. If someone loads it with 4-width tabs, they see the two lines aligned differently.
- wildjim 18y ago
  I've heard all sorts of arguments for and against, but in the end it only matters that you consistently choose only tabs or spaces, and that you use whatever header-settings your IDE provides to enforce the decision across all the coders, e.g. for emacs: #!/usr/bin/ruby -w #-*- standard-indent: 2; indent-tabs-mode: nil; -*- [...]

swombat 18y ago

I'm not quite sure why this style guide is more noteworthy than all the other ruby style guides out there.. e.g.: http://www.caliban.org/ruby/rubyguide.shtml http://www.caliban.org/ruby/rubyguide.shtml and http://www.pathf.com/blogs/2008/10/elements-of-ruby-style/ http://www.pathf.com/blogs/2008/10/elements-of-ruby-style/

defunkt 18y ago
Christian is a very well known Ruby developer. I'd say having a noteworthy developer write a style guide is noteworthy.
- tomjen 18y ago
  Well all it tells me is to stay out of his projects. Everybody knows that there is only _one_ space after a dot.

masonlee 18y ago

Hm. Use one letter variable names for scoped variables? Excerpt from lines 92-112: "* 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 And in general, the first letter of the class name if all objects are of that type."

wildjim 18y ago
This is explicitly disallowed within some companies...

azanar 18y ago

Do not program defensively. (See http://www.erlang.se/doc/programming_rules.shtml#HDR11. http://www.erlang.se/doc/programming_rules.shtml#HDR11.) I cross-referenced to the Erlang documentation, and they provided no other real justification for this rule, other than to say that the burden lies on the caller. Is there a history behind this convention? Is there a considerable benefit, other than more stream-lined code, to coding this way?

troels 18y ago
I suppose it's a duck-type thing. A strength of dynamic typing is that you don't need to anticipate all uses of your api. By allowing anything as input, you make things more flexible. For example, instead of assuming that a parameter should be a string, you should just treat it like a string and have the caller deal with the consequences if he passes something else. One positive effect of this is that validation/error handling code tends to be kept in a single place rather than scattered out over the model layer. I'm not sure if I completely buy in to this sentiment, but that's how I read it.
DavidMcLaughlin 18y ago
Firstly, it's basic DRY principles. Rather than have code dotted around your system dealing with data integrity issues, put it in one place and make your business logic more readable and easier to maintain. When trying to understand a subroutine or Class I should not have to wade through all the lines of code that try to make sure the input is 'safe.' Secondly, something I've noticed about defensive programming is that generally it creates a culture of "meta rules" that only exist in the system architect's head. When someone else reuses one of their models, then the danger is they don't know all these different rules because they are scattered around different controllers or scripts. This has been a particularly vicious source of bugs in our legacy systems. Domain experience becomes critical. Lastly, defensive programming by its nature is also traditionally a big red warning sign that says "there is no data integrity strategy in place for this system." It doesn't matter if that data is coming from a CRUD form, a relational database or a file... there should be some validation layer that ensures the data is 'correct' before making it 'safe' to reuse across the rest of the system. I've found that defensive programming is particularly rife in systems powered by MySQL databases. MySQL has traditionally lacked the data integrity mechanisms of Oracle or other Enterprisey systems and thus has created a whole bunch of MySQL 'experts' that actually don't know anything about data integrity. A system I'm working with this very minute has a function where the first 20 lines of code (out of 28 total) is compensating for potential orphan entries in the database. The reason? The admin tool for removing entries does not do cascading deletes. Rather than fix the root of the problem, we have this 20 line check everywhere that we need to access the data safely. I could go on and on, but in short: defensive programming is one of the major 'code smells.'

wildjim 18y ago

I really hate other people's style-guides. Most of it is common-sense, but there's always some aspect or another that really grates against my preferences, e.g. "Keep lines fewer than 80 characters" is a pet hate; when did we return to Green-screen terminals?? My current company enforces this, and it often creates worse multi-line dischord cf. adding an extra 10 to 20 char's to the current line. And "Read other style guides and apply the parts that don't dissent with this list" is a little too arrogant for any coder in the entire world -- perhaps should be "Replace any parts of this list that don't conform to your style".

dhotson 18y ago
Actually, I find limiting to ~80-100 chars makes code more readable. On a 24" screen I like to have 2-3 files open side by side. Having to scroll down is no big deal, scrolling sideways is pretty awkward. It also makes diffs harder to read if lines are too long. I certainly wouldn't argue for a hard limit of 80, but I find it's generally a good idea to break up lines if they're getting too long.
- wildjim 18y ago
  That's kind-of the point: emphasis should be on readability, not "this long, and no longer!", and that applies to all points in any style-guide, i.e. it's a "guide" not a rule-book.