Read Style Guides

[stevekinney]

Read: Both of the following style guides (30 minutes)

• thoughtbot's style guide for Ruby.
• Airbnb's JavaScript style guide.

When you glanced over the style guides, which aspects made you jump out of your chair and say "YES!" and which ones made you grumble in quiet, reserved discontent?

[skuhlmann]

I like a lot of the thoughbot naming convention guidelines because they help code read like English... and I have some experience reading English.

This one bums me out a bit: "Use spaces around { and before }." I've been considering dropping those spaces recently.

[stevekinney]

I generally like thoughtbot's style guide. Like @skuhlmann, I didn't use to put spaces inside of my curly braces, but I guess I came around because I've been doing it lately.

My big beef is select and detect over find and find_all.

[bayendor]

YES: Finally a style guide!

I have been using Rubocop's default modes for over a year, and have at the end of module 2 tweaked settings and have my own .rubocop.yml file that is now associated with my Hound configuration. I'm a fan of Thoughtbot's style guide, since it basically mirrors bbatsov, although I prefer single quotes where interpolation is not a thing. I prefer having any kind of style guide, since I'm keen on consistency in a project if nothing else.

I don't have much experience with javascript, but I notice that there is a lot of overlap in some areas with basic Ruby style, and single quotes is a thing, even though interpolation does not appear to be. I favor semicolons and curly braces, and explicit declarations from what little time I have in other languages that had similar structures.

[stevekinney]

@bayendor I think the main reason for single quotes in JavaScript is that HTML typically uses double quotes for attributes. You're often working with HTML in JavaScript, so it's much easier to write something like:

var someElement = $('.some-element');
$('<div class="awesome"></div>').appendTo(someElement);

The ES6 spec currently includes a proposal for template strings, which allow for string interpolation. In fact, you can use them in most recent versions of Firefox as well as io.js. They'll also work in any browser if you run your code through the Google Closure Compiler or 6to5.js (which I believe is being included in Rails 5).

console.log(`two plus two equals ${2 + 2}`);

[dglunz]

Consistency is nice so I get the appeal of these guides and having an agreed upon way of doing things. That being said, I don't really care. It all just feels silly and pedantic to me.

I'm a big fan of Hound or anything that automatically eliminates the need to have repetitive discussions about personal preference. I'll conform to whatever style is accepted amongst the group, just make it automated so we don't spend a ton of time on it. Better yet give me something like gofmt that formats everything on save and doesn't make even think twice about it. It'd be ideal if there was something that took all of your formatting preferences and converted any code that you viewed into that style. Such as programmatically swapping a map for a collect and visa versa depending on your preferences.

To answer the question though: One that stuck out was the opposition to ternary.

Avoid ternary operators (boolean ? true : false). Use multi-line if instead to emphasize code branches.

Which makes it even more difficult to follow their other rules about keeping methods below 5 lines.

[bayendor]

@dglunz: I'm in full agreement with you, pedantic is the right word. I run everything through rubocop with the -a switch. It auto-corrects a lot of stuff like map for collect, your choice of single or double quotes, etc, based on the configuration. It also fixes indents, whitespace, and a few other things. I have it mapped to a key-binding in vim at this point, and run it without even thinking about it.

[dglunz]

@bayendor that's awesome. I'll checkout your dotfiles and get the vim setup with rubocop. I like the idea of not having to think about it and just being able to format everything with a vim key-binding.

To add onto my previous comment:

"Engineers are so good at wasting time over the stupidest decisions" -Tom Dale on Shop Talk

[dglunz]

Also, where is the style guide for writing documentation?

[katelane]

@dglunz "I'm a big fan of anything that automatically eliminates the need to have repetitive discussions about personal preference."

[VikiAnn]

"Use a trailing comma after each item in a multi-line list, including the last item." Uh.... that's just weird.

[dalexj]

@VikiAnn Go actually forces you to add the commas after every line. It's extremely annoying if the last item doesn't have a comma at the end and you want to change things sometimes.

JavaScript

I love reading code that doesn't have the curly brackets on new lines, glad they have it that way.

function funcName()
{
  //fuuuuuuuuuck this
}

Now to Ruby

I like most of this, but noooooo I want ternaries. I think multi-assignment is useful too, as long as the line isn't too long.

def initialize(name, size)
  @name, @size = name, size
end

I like most of these other guidelines, since they have the point of keeping the code readable rather than "just do this cuz"

[gregnar]

The trailing comma thing only makes sense when you start adding on stuff that you weren't expecting to need, and then your code breaks because there's no comma between what used to be the last item and the new last item. I did this to myself so many times with semicolons in CSS.

[gregnar]

I think the detect vs. find stuff, as well as map vs. collect, is arbitrary nonsense. Also I like using end-of-line conditionals conservatively; they read nicely. I avoid doing it twice in one place, though.

[stevekinney]

I actually like the trailing comma. If I add stuff to the array or move stuff around, then I don't have to think about it.

In a similar vein, I hate multiple assignment in JavaScript.

Sometimes you might see this:

var x = 1, y = 3;

Usually, it will be written like this:

var x = 1,
    y = 2;

If the person is a hipster (or a Node developer), you may even see this:

var x = 1
,   y = 2
,   z = 3
;

I prefer to write it like this:

var x = 1;
var y = 2;
var z = 3;

If I need to add or remove a variable, I don't have to shuffle commas.

[Tmee]

rails style - I really like the migrations part to set a default string, Nothing really stood out as too crazy for me. The background workers part I am still new to so I couldn't really make a good assessment of it.
ruby style - I was indifferent about the entire thing. Most of them I agreed with. The preferred section made me laugh. Both things they compare do the exact same thing.
js style - I still don't know much about JS so the style guide was more a learning read. It was nice to see different ways of doing it, always good to see a bad way and how to fix

[katelane]

@gregnar I was just gonna say, that's the curse of the CSS semicolon!

[katelane]

Meanwhile, I think these guides are interesting but yeah... if you work for a place that has their shit together they will likely force you to use their preference anyway (frontend battles are similarly fought and there is value to be had in consistency even though sometimes it's frustrating as hell).

Also the term "screaming snake case" has always creeped me out, ngl.

[chandracarney]

Ruby and Rails: These styles and preferences make sense, even if they seem like silly points to argue (inject vs. reduce, for instance). The point that I took away is that it seems to be a matter of staying consistent throughout a project or series of projects at a company.

Rails: I haven't dealt a lot with date, datetime, and time, so I haven't seen the _time _on or _at column names used. Good to know on that front.

JS: These will be really great to have on hand for our JS adventures. I, like Tim, don't have a whole lot of experience with JS yet and learned a goo deal from reading through the style guide.

[VikiAnn]

Rails? Where's everybody seeing this rails stuff?

[stevekinney]

It’s in the same repository somewhere.

On Tue, Feb 3, 2015 at 10:46 PM, Viki Harrod notifications@github.com wrote:

Rails? Where's everybody seeing this rails stuff?

Reply to this email directly or view it on GitHub: https://github.com/turingschool/intermission-assignments/issues/3#issuecomment-72794368

[trayo]

_Rails_ I like these most of all, but I feel most people would consider it bike shedding. I prefer taking into consideration who might look at your code months or years from the time it was written and making it as simple as possible.

Order ActiveRecord associations alphabetically by attribute name.
Order ActiveRecord validations alphabetically by attribute name.
Order ActiveRecord associations above ActiveRecord validations.
Order model contents: constants, macros, public methods, private methods.
Order resourceful routes alphabetically by name.

I didn't realize there wasn't really a difference between buttons and links and this helped clear up their use: Use link_to for GET requests, and button_to for other HTTP verbs.

Super like this because of how frustrating it was looking through data in rails console and having to sift through updated_at and created_at in the middle of a lot of model data when trying to verify contents: List timestamps first when creating a new table.