Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Github Ruby Styleguide

github.com

Post reply on HN
Print view View original

31–40 of 73 posts

Re: Github Ruby Styleguide

#31

Post by OriginalSyn »

danenania wrote: post #28
OriginalSyn wrote: post #22

Earlier quoted context omitted.

In team environments you typically sacrifice convenience for maintainability and while you may not have a problem with optional parenthesis, it invites ambiguity and a more junior programmer may make a mistake because of it so the idea is to close off that edge case completely and not have to worry about it. This is the same reason a lot of shops ban the terniary operator for anything more than the simplest of variab…

I agree with your general point, but I don't really see how omitting those parentheses invites ambiguity. def reply_to_post text end What could anyone imagine text to be in this context aside from an argument? I get that using parentheses is more familiar coming from languages with C syntax, but I see no other rationale. I've never worked with anyone who stumbled over this. It's always just: 'oh cool, I didn't realiz…

I may have been thinking of a edge case in CoffeeScript when I wrote that, but you're right.

Re: Github Ruby Styleguide

#33

Post by alanctgardner2 »

pooriaazimi wrote: post #30
alanctgardner2 wrote: post #29

Earlier quoted context omitted.

> first_user = User.find(4) && second_user = User.find(6) It looks like it would evaluate as: first_user = (User.find(4) and second_user = User.find(6)) That is to say, the assignment comes after the boolean operation, which is unexpected.

Well, I expect first_user = User.find(4) && second_user = User.find(6) to be literally equivalent to second_user = User.find(6) first_user = User.find(4) && second_user I honestly can't see why you might want it to mean something else... Edit: I see. if you do something like if (first_user = User.find(4) && second_user = User.find(6)) { .. } it might bite you. You might expect it to be equivalent to first_user = User…

Personally, I'm almost painfully verbose with my parens to avoid exactly this scenario. Better to be explicit about my intent to the interpreter and other coders.

Having an assignment that could be skipped by short-circuiting also seems like bad practice, but I realize it was designed to be a toy example

Re: Github Ruby Styleguide

#34

Post by yalue »

viseztrance wrote: post #26
yalue wrote: post #8

I agree with almost everything except for using named groups over the $1-$9 variables in regular expression matching. This may be the case if there are many capture groups in the expression, but I would argue that /(? regexp)/ =~ string is a fair deal more difficult to read than simply /(regexp)/ =~ string Almost everybody familiar with PCRE will be familiar with the simpler form, and it's usually the case that the s…

The following are equivalent: if /(? regexp)/ =~ string puts meaningful_var end if /(regexp)/ =~ string puts $1 end This may not look like much, but bare in mind you may be using the current selection in several places, at which point you'll probably use the following for readability either way: meaningful_var = $1 In any case I think that sometimes the latter is preferable, that's why I'm not into these kind of blac…

It is true that one will probably immediately reassign the $- variables. And that's definitely true that there are cases when conventions impede good style. I would probably say, though, that in most cases the latter of your examples is preferable.

    if string =~ /First: (.*?) Last: (.*?)\s/
      first_name = $1
      last_name = $2
      # etc...
    end
looks far better to me than

    if string =~ /First: (?.*?) Last: (?.*?)\s/
      # etc...
    end

Re: Github Ruby Styleguide

#35

Post by dsr12 »

Now-a-days we have computers which can show more than 80 characters at a time. "Keep lines fewer than 80 characters", Is this recommendation still valid?

Re: Github Ruby Styleguide

#36

Post by barclay »

dsr12 wrote: post #35

Now-a-days we have computers which can show more than 80 characters at a time. "Keep lines fewer than 80 characters", Is this recommendation still valid?

Yes(!) Goddamn you kids and your Xcode.

Now get off my damned lawn.

Re: Github Ruby Styleguide

#37

Post by lloeki »

philwelch wrote: post #19
alanctgardner2 wrote: post #14

Earlier quoted context omitted.

To anyone who's wondering, it seems like 'and' and 'or' are the same as && and ||, but with lower precedence [0]. Does anyone have a good reason why they both exist? It's a pretty big gotcha. [0] http://stackoverflow.com/questions/1426826/difference-betwee...

It's an imported Perlism, back from the days of the old assert idiom `foo == bar or die`. If `foo == bar` evaluates to true, the `or` is short-circuited, else it calls the built-in `die` function which kills the process.

More precisely && and || are meant to stand in boolean tests, whereas and and or are meant to tie expressions together DSL style, as an alternative to if/then, like so:

   @current_user.logged_in? or redirect_to login_path
   @current_user.can? :do_this or render :status => 403
   shirt.blue? and return bar
   put_suit_on or put_pants_on

Re: Github Ruby Styleguide

#38

Post by bryanlarsen »

dsr12 wrote: post #35

Now-a-days we have computers which can show more than 80 characters at a time. "Keep lines fewer than 80 characters", Is this recommendation still valid?

Shorter lines are easier to read. Short lines let you put up several editor windows side by side even on a cramped laptop. Short lines let you use a larger font to save your eyes.

There can also be a code win: when forced to deal with short lines, it's often easier to split a long line of code into two easier to understand lines than it is to split on an operator.

Sometimes a split line is a lot worse than a long line, which is why the rule shouldn't be applied religious -- you should only be called on it if you have many lines over the limit.

IMO, 80 is a little bit tight; I prefer 100. But I wouldn't bike shed it if there was a standard in place.

Re: Github Ruby Styleguide

#39

Post by Pewpewarrows »

kreeger wrote: post #11

I can't stress enough how important it is to _not_ use `and` and `or`. As a former die-hard fan of those operators, it bit me in the ass so hard when those didn't exactly work the way they were supposed to. I've been using && and || now for years and I haven't looked back. /PSA

I agree. But in all code that I write, regardless of pretty much whatever language it's written in, I always explicitly add parentheses around what I want the order of operations to be.

"1 * 3 + 4 / 20 && foo" is unreadable. No one wants to memorize the order of operations for every language they use and have to figure it out in their head. Make life easier for the people who have to maintain that line of code you just wrote.

Re: Github Ruby Styleguide

#40

Post by fox91 »

dsr12 wrote: post #35

Now-a-days we have computers which can show more than 80 characters at a time. "Keep lines fewer than 80 characters", Is this recommendation still valid?

I really can't stand longer lines, I think that this is a best practice for every code. I usually work with the monitor splitted in two parts with maybe 2 different files in each half, long lines would make that really difficult to read.

Moreover if you need lines longer than 80 chars you're probably doing it the wrong way: long lines are difficult to understand

Post reply on HN