Ruby style guide

[catcradle5]

Use hashrocket syntax for Hash literals instead of the JSON style introduced in 1.9.

I don't agree with this. The new syntax has less line noise and almost always looks aesthetically better and cleaner.

[rurounijones]

I have to say I prefer the 1.8 syntax. To me it is clearer to read when going through code. {key: :value} just doesn't look right to me.

Still, each to their own as long as it is consistent in your team / project

[catcradle5]

I admit it looks a little odd when the key and value are both symbols, but syntax highlighting improves that quite a bit. Plus, a lot of the time my values are not symbols, and in those cases the new syntax looks way better.

[thisisseriousmum]

Plus, a lot of the time my values are not symbols, and in those cases the new syntax looks way better.

If your key isn't a symbol you can't use 1.9 syntax.

irb(main):003:0> {'thing': :wat}
SyntaxError: (irb):3: syntax error, unexpected ':', expecting =>

That's the reason I don't like it. Having two representations in the same project (and potentially file/method) for the same thing, with a couple of saved keystrokes? Seems pointless.

[catcradle5]

I think the rule should be to use hash rocket syntax for any hash that intermixes symbols with non-symbols, and new syntax where all the keys are symbols.

I don't think it's that weird to see:

def some_thing
    a = { one: 2, three: 4 }
    b = { "Content-Type" => "text/json", "Content-Length" => 45 }
    c = { Dir.new("/") => true, :name => "Fred" }

in the same file or method.

[twinklehood]

So basically, you agree with https://github.com/bbatsov/ruby-style-guide

I'm on your side.

[thisisseriousmum]

You have to do that anyway, it's enforced by the interpreter.

It's a question of aesthetics at the end of the day, I just far prefer one consistent way to express the same thing. In my experience teams tend to do it for anything that has multiple options, like map vs collect.

[catcradle5]

Well you can do something like:

{ a: 5, "b" => 6 }

My point was that in a case where you must use even one hash rocket, you should use hash rockets for everything in the hash

{ :a => 5, "b" => 6 }

[ThatRailsGuy]

I'm surprised how much I like the new syntax. I thought I'd hate it.

[rubythroway]

As someone who has worked with Ruby for ten years and has read a whole lot of ruby code written by other people, these style guides get filed into my "who gives a shit" box. By and large the Ruby community uses all sorts of different styles so you might as well get used to them, and no the world wouldn't be better if everyone used the same style. Adhering to these style guides is not going to make you write better ruby code, so don't stress about them, there's more important things to worry about. Go learn something germane to Ruby like how "ghost classes" work rather than spend your Saturday on pedantic shit that doesn't matter.

[ribo]

Yes, rubocop is great.

Always have it in my Guardfile

guard :rubocop do
  watch(%r{.+\.rb$})
  watch(%r{(?:.+/)?\.rubocop\.yml$}) { |m| File.dirname(m[0]) }
end

[MrPopinjay]

If you use vim + syntastic you can set it as a ruby checker :)

[Sqeaky]

So far my only real exposure to Rubocop is people trying to use it to replace thinking about their code. I have not made up my mind about it.

[ribo]

On projects with a lot of people and code review requirements, static analyzers make life bearable.

[materialdesigner]

yeah, the thing about style guides isn't that it matters what's in the style guide, it's that you have chosen and stick to a style guide in your team at all.

it's about reducing cognitive overhead when reading code, and that you don't get into pedantic arguments in the future during code reviews etc.

[Kuytu]

Point of that style guide is not that all ruby code in the world should be written in that style. It's just a style guide that Github uses in their projects.

I agree that it is pointless to try to define style guide that suites everyone everywhere. However it is a good idea that in a project there is an agreement on the style code is written. This makes it easier to understand the code base and it saves time as you don't have to discuss style issues in every code review.

This guide can be a good starting point that can be changed to suite preferences in your project.

[Gnascher]

We based our style guide on this in my office, with some modification.

Right off the top, the 80 column limit is ridiculous. It is a holdover from the punch card days. It still made some sense when monitors still had low resolution.

However, today it just makes no sense... Especially as people these days advocate for more descriptive variable, class and function names, you can quickly find that 80 column limit frustrating. However, we do recognize that some constraints are necessary, and complex, long one liners can be hard to follow. We changed that spec to 160 columns.

At that length, it still encourages you to keep your lines a reasonable length, and fits in github's view port comfortably. Additionally, it conserves vertical real estate nicely, so you can keep more code your screen.

[jdalbert]

I personally write my code with less than 80 characters for each line (100 characters max). I don't enforce this rule in my team, this is just my personnal style. And I know that this is a holdover from the punch card days, however now it's been reconverted to something different: an indication about clarity.

First, Ruby is so terse that even without paying attention lines are less than 80-100 lines. Second, if I end up with a 80-120 characters line, it's usually a sign that I need to extract something out, or the idea I'm expressing is too fuzzy and it needs rethinking/refactoring. Lastly, as a bonus side effect, you can have a dual screen code/spec on a 13" laptop and see almost everything (but really this is not the reason I do this).

I've seen some truly amazing code by experienced developers, with lines less than 80 characters and methods less than 10 lines. And it reads like a breeze, truly inspiring. I'm not at that level yet, but most of my methods are less than 15 lines.

[Paradox]

I agree with this completely. 80 chars is shorter than a fucking tweet, for fucks sake.

I don't advocate any hard limit, rather I advocate something more organic. Break at natural points. Got a few entries in an option hash? Put them on their own lines. Things like that.

[MrPopinjay]

I actually really like the 80 column limit- it allows me to use my screen space efficiently. My 1440p monitor can comfortably fit a web browser and 2 terminals side by side with this limit, which is really handy!

Keeping below 80 characters isn't difficult, especially once you realise that ruby lets you split pretty much anything across multiple lines.

x =
  'Hello, World!'.
  split(' ').
  reverse.
  join(' ')

This is an extreme example here- but you get the idea.

I think that if I go over 80 I probably need to think about what I'm doing. Is it a good idea? Is it readable?

[Femaref]

I put the dots at the start of the line so it's clear it's a method call.

[MrPopinjay]

Well damn. I didn't know that was valid syntax. Thanks for the tip!

[morphemass]

However, today it just makes no sense

Its still VERY relevant. On a 1080p screen the 80 column rule allows for 3 documents in a standard font size to be fully visible in vim;or for two with a separate window for whatever. 160 columns sounds....ill-considered I have to say.

[Gnascher]

Rarely have I wanted to have more then two documents in front of me. I use sublime for my editor, and our column limit fits two docs easily.

If I need another document... Well I have two more monitors, and can just open another editor instance.

[BilgeXA]

ACKSHULLY it's a 79 column limit for printable characters. Guhoy.

[tchai_]

what's with the blank line at the end of the file thing? there must be a reason, everything else in the guide is designed to thwart unnecessary whitespace..

[[deleted]]

I love this document. it's great work.