The Ruby Style Guide • Hacker News Board

Re: The Ruby Style Guide

#41

Post by jolmg » Sat, Jun 15, 2019, 1:28 AM UTC

pjungwir wrote: post #4

Oh fun another style discussion! :-) My own taste is for a "book style": write the code like you see in good books. I agree with most of this guide, although I'm pretty loose and case-by-case in practice. I've gradually added rubocop to lots of my projects, but then I wind up disabling tons of the rules. I'm sad all the Ruby guides I've seen ban "and" and "or". I don't find them to be such an issue, and they are nice…

I would do your SQL like this:

  select a, b
    from t1
      left outer join t2
        on t2.t1_id = t1.id
    where t2.c = 'foo'
      and t2.d = 'bar';

- Lowercase

- I don't like that use of variable number of spaces to try to align things you did in both your examples. Doing that kind of thing in code generally leads to having to readjust that spacing whenever a new line is added or removed.

- Constant-width indentation indicates structure. "left outer join" is part of the "from" clause, so it's indented further. "on" is part of the "left outer join" clause, so it's indented further.

Among languages, I imagine SQL is the one with the most varied styling among those who use it.

Re: The Ruby Style Guide

#42

Post by hderms » Sat, Jun 15, 2019, 1:47 AM UTC

All languages should have gofmt at this point. Debating code style is a waste of everyone's time.

Re: The Ruby Style Guide

#43

Post by h1d » Sat, Jun 15, 2019, 3:03 AM UTC

matthewmacleod wrote: post #38

intsunny wrote: post #37

I'll never understand Ruby's obsession with implicit return. When reading code, my eye will immediately notice the `return` keyword and will have less to think about in terms of code execution. The `return` keyword makes for great readability.

I much prefer this, though I accept its not without problems in some cases. I find that say Javascript in comparison has a lot of syntactic noise; it's all annoyingly boiler-plate. Maybe JS's implicit-return-in-arrow-functions is a better compromise.

I feel JS has few syntactic noises but which part are you referring to?

Re: The Ruby Style Guide

#44

Post by h1d » Sat, Jun 15, 2019, 3:07 AM UTC

taffer wrote: post #40

pswenson wrote: post #11

80 char line length in 2019?

There are many good reasons for that IMO: * Too long lines are hard to read. For text 11 words per line are recommended, otherwise your eyes will loose track. 11 Words is roughly 60 characters, but code is indented so you need a bit more. * Some people look at your code in an 80-column terminal, if you use more, this would be rude. * Some people use a GUI diff tool that displays the code side by side, so that's alrea…

- Breaking lines at only 80 chars would make it read horrible by splitting lines in the middle of syntactic contexts.

- Unless that's your team's preference, you're not helping anyone.

- Same as above.

Re: The Ruby Style Guide

#45

Post by h1d » Sat, Jun 15, 2019, 3:14 AM UTC

davnicwil wrote: post #30

pswenson wrote: post #11

80 char line length in 2019?

I know, on the surface it seems silly, but there are a couple of reasons I've found 80 chars makes things easier in real world workflows in 2019: * Split panes in editors. With 80 chars, you can usually have two panes on screen along with a file tree, on most laptop screens. This is pretty nice to have. * Code reviews in a web interface like Github/Gitlab - 80 chars means usually there's no need to pan, even when you…

Enforcing 80 chars on everyone for those reasons doesn't feel justifying.

It will definitely make people use weird variable names instead of meaningful ones.

  is_included = true

could turn into,

  inc = true #included or increment?

That's a far worse side effect than other points raised in this thread.

Re: The Ruby Style Guide

#46

Post by ericb » Sat, Jun 15, 2019, 12:14 PM UTC

h1d wrote: post #45

davnicwil wrote: post #30

Earlier quoted context omitted.

I know, on the surface it seems silly, but there are a couple of reasons I've found 80 chars makes things easier in real world workflows in 2019: * Split panes in editors. With 80 chars, you can usually have two panes on screen along with a file tree, on most laptop screens. This is pretty nice to have. * Code reviews in a web interface like Github/Gitlab - 80 chars means usually there's no need to pan, even when you…

Enforcing 80 chars on everyone for those reasons doesn't feel justifying. It will definitely make people use weird variable names instead of meaningful ones. is_included = true could turn into, inc = true #included or increment? That's a far worse side effect than other points raised in this thread.

Even worse, abbreviations are terrible as there is one way to write a word correctly, and lots of ways to abbreviate it, so now you have to keep track of that too.

Was it inc? incl? incld? includ? in? incldd?

Now you have to break flow to go check. There's many ways it could be written and a chance for bugs to be introduced if you accidentally pick the wrong style. And when you read it, does the inc mean incorporated? included? includes? including? incapable? incestual?

Re: The Ruby Style Guide

#47

Post by davnicwil » Sat, Jun 15, 2019, 10:28 PM UTC

h1d wrote: post #45

davnicwil wrote: post #30

Earlier quoted context omitted.

I know, on the surface it seems silly, but there are a couple of reasons I've found 80 chars makes things easier in real world workflows in 2019: * Split panes in editors. With 80 chars, you can usually have two panes on screen along with a file tree, on most laptop screens. This is pretty nice to have. * Code reviews in a web interface like Github/Gitlab - 80 chars means usually there's no need to pan, even when you…

Enforcing 80 chars on everyone for those reasons doesn't feel justifying. It will definitely make people use weird variable names instead of meaningful ones. is_included = true could turn into, inc = true #included or increment? That's a far worse side effect than other points raised in this thread.

That's a fair point, though I'll say in my experience, it's not been the case. If it were, I wouldn't do it as I agree with you that it outweighs the benefits I mentioned.

Re: The Ruby Style Guide

#48

Post by bozhidar » Tue, Jun 18, 2019, 4:36 AM UTC

steveklabnik wrote: post #5

I made a comment on this thread[1] in 2014, and it was closed two days ago. I wondered why... guess this is why! 1: https://github.com/rubocop-hq/ruby-style-guide/issues/273

Yeah, you're right. I was triaging and cleaning up the open issues prior to launching the new site.

Now that the guide has more editors I'm optimistic that we won't end up in a situation with that many non-triaged tickets down the road.