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

41–50 of 82 posts

Re: The GitHub Styleguide

#41

Post by dos1 »

secoif wrote: post #33
lucisferre wrote: post #15

Earlier quoted context omitted.

Yeah, you save one character per line, and gain a lot more in cognitive friction. Words to live by: "don't make me think" even about whether or not I need a semi-colon here.

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

Re: The GitHub Styleguide

#45

Post by technomancy »

rtomayko wrote: post #29
MatthewPhillips wrote: post #5

Earlier quoted context omitted.

They actually don't provide a justification. That blog makes the argument that omitting them is harmless. Neither GitHub nor the blog make an argument for why you should omit them, however.

Do you use semicolons in Ruby, Python, shell, or other semicolon-less language where semicolons are allowed? If not, what's your justification for omitting them?

The justification is to be idiomatic and match the bulk of existing code.

Re: The GitHub Styleguide

#46

Post by martingordon » 

  Use def self.method to define singleton methods.
  ...
  # Also possible and convenient when you
  # have to define many singleton methods.
  class
I would argue against using "class especially when you have many singleton methods. If the class is large enough, it's easy to miss the "class << self" and incorrectly read a class method as an instance method.

Re: The GitHub Styleguide

#47

Post by elliottcarlson »

cocoflunchy wrote: post #44

What's the reason for recommending 2 space indents ? I find it easier to read with 4 or even more spaces indent.

I was wondering the same thing.

Recently, a coworker and myself were debating the use of tabs vs. spaces - and while I know this is a battle that has been going on for a while and won't end any time soon - one of my points against spaces was due to readability. 2 space soft-tabs seems much harder to follow - while using hard tabs for indentation, you are able to adjust your editor to visually work out what suits you best (2 spaces, 4 spaces or even 8 spaces).

Re: The GitHub Styleguide

#48

Post by true_religion »

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

He never said the net result was the same.

He said that there were no problems.

No problems doesn't imply no benefits.

Re: The GitHub Styleguide

#49

Post by tszming »

A good coding guideline should emphasize the importance of "consistency", so if you tell me that..

"..my advice is to insert them (semicolons) immediately before the opening parenthesis or square bracket in any statement that begins with one of those tokens, or any which begins with one of the arithmetic operator tokens /, +, or - if you should happen to write such a statement..." (http://mislav.uniqpath.com/2010/05/semicolons/)

Then I would say it is really not a good idea.

Re: The GitHub Styleguide

#50

Post by petercooper »

mapgrep wrote: post #10

I liked their guideline on when to use bang methods like `array.map!` in ruby: "The names of potentially 'dangerous' methods (i.e. methods that modify self or the arguments, exit!, etc.) should end with an exclamation mark. Bang methods should only exist if a non-bang method exists. " That last sentence finally made me understand why `string.gsub!` takes a bang but `FileUtils.rm_rf(dir)` does not, even though the lat…

There are lots of simpler examples too. Consider Array#push or Array#pop. Both make changes to an array in place, but are not ! suffixed due to the requirement you quoted.

You are right, though. Many Rubyists do not follow this convention and often don't even know about it. It's a key convention of the core implementation team, however.

Post reply on HN