Thoughtbot's Style Guide for Ruby

[EmilyMB]

Discuss thoughtbot's style guide for Ruby here. In particular, when you glanced over the style guide, which aspects made you jump out of your chair and say "YES!" and which ones made you grumble in quiet, reserved discontent?

[EmilyMB]

I find it odd that Airbnb likes method call chains to be split with the "." on the new line in JS, while thoughtbot encourages the line to end with the "." in Ruby. Same for single vs double quotes. I realize they are different languages, but since they are used together frequently, having consistency would be helpful!

[Jwan622]

*grumble: "Don't misspell."

[JoshCheek]

@EmilyMB it's probably because on older Rubies, it wouldn't correctly parse leading dots, so you had to put them at the end of the previous line. Now that it does, and those rubies have been end-of-life'd, I think most people agree that they should lead the line. Aside from being more aesthetically pleasing, and easier to parse (for my brain, anyway), it also has the nice advantage that adding/deleting from the end doesn't require you to edit multiple lines.

[JoshCheek]

Keep in mind that I usually code alone these days, and my formatting style may be hard for others to read. Also, keep in mind that other than things like 2 spaces for indentation, I don't have strong opinions on most of these (except for when some robot fails my build).

Formatting

opinion	guide
disagree	Avoid inline comments.
disagree/indifferent	Break long lines after 80 characters.
agree	Delete trailing whitespace.
agree/indifferent	Don't include spaces after (, [ or before ], ).
agree	Don't misspell.
disagree	Don't vertically align tokens on consecutive lines.
indifferent	If you break up an argument list, keep the arguments on their own lines and closing parenthesis on its own line.
indifferent	If you break up a hash, keep the elements on their own lines and closing curly brace on its own line.
it depends	Indent continued lines two spaces.
agree	Indent private methods equal to public methods.
my opinion is too nuanced to say	If you break up a chain of method invocations, keep each method invocation on its own line. Place the . at the end of each line, except the last. Example.
strong agree	Use 2 space indentation (no tabs).
it depends	Use an empty line between methods.
it depends	Use empty lines around multi-line blocks.
indifferent, so long as both sides touch the operator, or neither does	Use spaces around operators, except for unary operators, such as !.
mostly agree	Use spaces after commas, after colons and semicolons, around { and before }.
agree	Use Unix-style line endings.
too ignorant to have an opinion	Use uppercase for SQL key words and lowercase for SQL identifiers.

Naming

opinion	guide
it depends	Avoid abbreviations.
agree	Avoid object types in names (user_array, email_method CalculatorClass, ReportModule).
indifferent	Prefer naming classes after domain concepts rather than patterns they implement (e.g. Guest vs NullUser, CachedRequest vs RequestDecorator).
agree	Name the enumeration parameter the singular of the collection.
it depends	Name variables created by a factory after the factory (user_factory creates user).
agree	Name variables, methods, and classes to reveal intent.
indifferent	Treat acronyms as words in names (XmlHttpRequest not XMLHTTPRequest), even if the acronym is the entire name (class Html not class HTML).
wait, doesn't this contradict #2?	Suffix variables holding a factory with _factory (user_factory).

Organization

opinion	guide
okay	Order methods so that caller methods are earlier in the file than the methods they call.
sure, but if this winds up mattering, you probably have a class in need of extraction	Order methods so that methods are as close as possible to other methods they call.

[nathanows]

• Conditional modifiers: I use these mostly for conditional error handling, maybe thats the issue, but when used I think it helps keep code clean :-1:
• Multiple assignments: The only time I've found this useful (necessary?) was when doing some text parsing (word_one, word_two, *rest = "one two three four five etc".split(" ")).
• Organizational comments: like them in specific circumstances, but the more I think about it, having to organize things in to sub-categories may mean I'm breaking single responsibility to start with... hmm...
• Ternaries: I kind of like them for small switch/case statements :/
• Bang! method names: I've used them on occasion, but not really a big fan
• Prefer if over unless: Not sure i agree with this one, i think you should use whichever makes the code more human readable (for example, i think 'do x unless array.length == 0' is better that 'do x if !array.length == 0')
• Predicate methods: didnt know that's what they were called.... but agree (http://pragmati.st/2012/03/24/the-elements-of-ruby-style-predicate-methods/)
• Trailing comma after multi-line lists: Makes sense, except... FOR THE LAST ITEM TOO?!?!
• Dont understand the last one protected vs private for accessors

[Lydias303]

:+1: (agree with) avoid: using semicolons, prefer: map over collect, prefer && and || over and/or, &:method_name for simple method calls.

:-1: (disagree with) avoid: conditional modifier, ternary operators prefer: detect over find, reduce over inject

[laurawhalin]

With a few of these, I didn't even know there were alternatives, such as Prefer && and || over and and or. Prefer ! over not. I do appreciate the brevity these semantics allow, but too many of them makes a language too difficult to read for beginners. A comma after the last item gives me a facial tick. It's good to state double quotes. I've don't have a preference over single vs double, but I'm inconsistent without someone (or something) hounding me about it.

[KristaANelson]

After seeing AirBnB's I appreciate theirs even more! Showing examples to show your point has so much value!

Explicit return statements, if this is what I think it is (using it to return and end a method for a one off case, then that makes me sad because I love those.

Detect, didn't realize this was a choice.

Double quoted I get except for spending so much time replacing single quotes that autopopulate with double quotes. That completely defeats the purpose of this practice in the first place! I want to kill hound for this! Use _ for unused block parameters. Would like to see an example of what they mean by this.

I actually like the trailing comma, even on the last line because so many times I add a new line and forget to add a comma to the previous line! Good habit!

[bmrsny]

Use def with parentheses when there are arguments, is a rule I feel strongly about. I get so confused when I don't see the parentheses here. I like the ternary operator, but I read this before and have been since trying not to use it. I still kind of like it. I had no idea class << self is the same as def self.method. I am glad I didn't know.

Found this one in the Rails section. I have to say I agree. Use def self.method, not the scope :method DSL.

[mikedao]

I'm a huge fan of their style guide, and much to the dismay of some, a fan of Hound. I think the one most people complain about is the 80 character limit, but I feel that this sets up your code for a worst case scenario when someone is looking at your code directly connected to a server with a monitor that only displays 640x480. It's a good exercise in learning how to name things in a concise, yet clear manner.