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

The GitHub Styleguide

github.com

Post reply on HN
Print view View original

71–80 of 82 posts

Re: The GitHub Styleguide

#71

Post by gioele »

sanderjd wrote: post #56
mildavw wrote: post #26

# bad email_with_name = user.name + ' ' # good email_with_name = "#{user.name} " # better email_with_name = "%s " % [user.name, user.email]

Why is the latter better? It seems equally good, but less idiomatic and certainly less obvious to most Ruby programmers.

The structure of strings like

  email_with_name = "%s " % [user.name, user.email]
can be easily identified even when many fields are added.

On the contrary, strings like

  email_with_name = "#{user.name} "
become quite cramped as soon as you use three or more fields.

Re: The GitHub Styleguide

#72

Post by viscanti »

dos1 wrote: post #41
secoif wrote: post #33

Earlier quoted context omitted.

Dropped semicolons about 6 months ago and haven't had a problem even once. Once you get into the habit, it requires zero extra effort. You just know when to put them in, same way you just know when to use parens vs curlies. Coding with semis is like coding with parens around every expression; unnecessary and paranoid.

But why? Why drop the semicolons? What is the benefit? If the net result is exactly the same, why try and be tricky? What is the point, other than you can do it. But there are many tricky things we can do with programming languages, but very few we should

On a team of a sufficient size, dropping semicolons hurts. Someone will be running a static analysis "lint" program in their editor, and it will always flag those missing semicolons. That certainly adds additional cognitive friction to those users, who constantly see the reminder to add the missing semicolon.

I guess I've never understood the argument for omitting them. It seems like an unnecessary trick. Coding guidelines should enforce the simplest possible patterns and techniques.

Re: The GitHub Styleguide

#73

Post by 286c8cb04bda »

jeltz wrote: post #17
mutewinter wrote: post #12

Scanning through the Ruby styleguide for GitHub-specific changes I found this gem: "The and and or keywords are banned. It's just not worth it. Always use && and || instead." sad trombone

Indeed, "and" and "or" are excellent for their intended use, for control flow. Like explained by the style guide the Github one is based on. https://github.com/bbatsov/ruby-style-guide # boolean expression if some_condition && some_other_condition do_something end # control flow document.saved? or document.save!

I'm not sold on tossing "and" and "or" out the window, but wouldn't "document.saved? or document.save!" read better as "document.save! unless document.saved?"

Re: The GitHub Styleguide

#74

Post by sanderjd »

gioele wrote: post #71
sanderjd wrote: post #56

Earlier quoted context omitted.

Why is the latter better? It seems equally good, but less idiomatic and certainly less obvious to most Ruby programmers.

The structure of strings like email_with_name = "%s " % [user.name, user.email] can be easily identified even when many fields are added. On the contrary, strings like email_with_name = "#{user.name} " become quite cramped as soon as you use three or more fields.

I'm not sure what you mean by cramped, but I think that the interpolation style is, on the contrary, much easier to read when you have multiple fields:

  puts "#{num} #{vessels} of #{liquid} on the #{where}, you #{verb1} one #{adverb1}, #{verb2} it #{adverb2}, #{num - 1} #{vessels} of #{liquid} on the #{where}"
  puts "%d %s of %s on the %s, you %s one %s, %s it %s, %i %s of %s on the %s", [ num, vessels, liquid, where, verb1, adverb1, verb2, adverb2, num - 1 ]
It's an extreme example, but you just read the first, while you have to think about the second.

Re: The GitHub Styleguide

#75

Post by alttag »

54mf wrote: post #66
alttag wrote: post #39

Earlier quoted context omitted.

> Coding with semis is like coding with parens around every expression; > unnecessary and paranoid. Unless, of course, one is using Scheme or some other Lisp variant.

Good thing it's a Javascript style guide, huh? ;)

It was the "unnecessary and paranoid" bit that really turned me off. Flaming everyone who doesn't use the same style wasn't warranted, IMNSHO. I responded with snark.

I think in general the answer may be to use the style that mimics the other code in the application. Rubyists may prefer the newline endings; those using Java or PHP may find having the semi-colon more comfortable. Having less contextual switch between languages may be easier.

Such a sweeping statement seemed a bit ridiculous. Choosing to interpret it in a broader context was intended to highlight my opinion of the original statement.

EDIT: It's been fun watching the mod of the GP go up and down ... zero, back to one, then to zero ... over and over.

Re: The GitHub Styleguide

#76

Post by secoif »

viscanti wrote: post #72
dos1 wrote: post #41

Earlier quoted context omitted.

But why? Why drop the semicolons? What is the benefit? If the net result is exactly the same, why try and be tricky? What is the point, other than you can do it. But there are many tricky things we can do with programming languages, but very few we should

On a team of a sufficient size, dropping semicolons hurts. Someone will be running a static analysis "lint" program in their editor, and it will always flag those missing semicolons. That certainly adds additional cognitive friction to those users, who constantly see the reminder to add the missing semicolon. I guess I've never understood the argument for omitting them. It seems like an unnecessary trick. Coding guid…

Unlikely the default lint options are going to suit all teams anyway. JSLint/JSHint can, and should be configured for your team's style.

Re: The GitHub Styleguide

#77

Post by secoif »

dos1 wrote: post #41
secoif wrote: post #33

Earlier quoted context omitted.

Dropped semicolons about 6 months ago and haven't had a problem even once. Once you get into the habit, it requires zero extra effort. You just know when to put them in, same way you just know when to use parens vs curlies. Coding with semis is like coding with parens around every expression; unnecessary and paranoid.

But why? Why drop the semicolons? What is the benefit? If the net result is exactly the same, why try and be tricky? What is the point, other than you can do it. But there are many tricky things we can do with programming languages, but very few we should

The point is to reduce noise. JavaScript already has a lot of cruft going on with all its anonymous functions, parens and curlies… anything to reduce the signal to noise ratio is a step in the right direction.

Re: The GitHub Styleguide

#78

Post by secoif »

alttag wrote: post #75
54mf wrote: post #66

Earlier quoted context omitted.

Good thing it's a Javascript style guide, huh? ;)

It was the "unnecessary and paranoid" bit that really turned me off. Flaming everyone who doesn't use the same style wasn't warranted, IMNSHO. I responded with snark. I think in general the answer may be to use the style that mimics the other code in the application. Rubyists may prefer the newline endings; those using Java or PHP may find having the semi-colon more comfortable. Having less contextual switch between…

It's unnecessary because apps continue to work with little to no modification without semis, it's paranoid because all of the reasons people come up with for why semicolons are important (lint tools? minifiers? bugs?), are all non-problems if you spend a few minutes changing your habits.

Re: The GitHub Styleguide

#79

Post by lucisferre »

secoif wrote: post #77
dos1 wrote: post #41

Earlier quoted context omitted.

But why? Why drop the semicolons? What is the benefit? If the net result is exactly the same, why try and be tricky? What is the point, other than you can do it. But there are many tricky things we can do with programming languages, but very few we should

The point is to reduce noise. JavaScript already has a lot of cruft going on with all its anonymous functions, parens and curlies… anything to reduce the signal to noise ratio is a step in the right direction.

If you really cared about that you would use coffee script. Dropping semicolons is such a triviality.

Re: The GitHub Styleguide

#80

Post by secoif »

lucisferre wrote: post #79
secoif wrote: post #77

Earlier quoted context omitted.

The point is to reduce noise. JavaScript already has a lot of cruft going on with all its anonymous functions, parens and curlies… anything to reduce the signal to noise ratio is a step in the right direction.

If you really cared about that you would use coffee script. Dropping semicolons is such a triviality.

I do use coffeescript on appropriate projects.
Post reply on HN