Ruby doesn't have something like PEP for Python?
It did several years ago but it went by the by. I'm struggling to remember what it was called.. Now, features are raised on the MRI Redmine, such as: https://bugs.ruby-lang.org/issues/6242
The GitHub Styleguide
51–60 of 82 posts
Re: The GitHub Styleguide
#52What's the reason for recommending 2 space indents ? I find it easier to read with 4 or even more spaces indent.
It's the least amount that's least like to be accidental while still visually significant. The emphasis on the least amount is to maintain good line lengths, which can be an issue with the way many Rubyists namespace their code or pull off method chains.
Re: The GitHub Styleguide
#53Here's a more accurate tl;dr of their JavaScript style guide:
$ curl -I https://github.com/styleguide/javascript
HTTP/1.1 301 Moved Permanently
Location: https://github.com/styleguide/coffeescriptRe: The GitHub Styleguide
#54After reading this, I just want to say that I do not think semicolon-less javascript is, in general, a good idea. Development projects are almost always team efforts. And, unfortunately, there's almost always one or two team members who aren't very good. Some of you folks that only work on startups with brilliant people might disagree, but in my experience most development teams have some bad apples who have let thei…
And even if your team is superstars now it doesn't mean it always will be. What happens a few years down the road when you now have a team 5 or 10 times the size with people of varying skillsets and areas of expertise. Now that guy with mostly Python or Ruby experience needs to make some changes to your JavaScript code with what little knowledge of the language they have. It's helpful to write things to be as idiomat…
Well, the same thing could be said about "that guy with mostly C, PHP or Java experience".
Re: The GitHub Styleguide
#55Earlier quoted context omitted.
Their style guide disagrees with mine! KILL THEM ALL!!! Did you read the article they linked to? I did. I still disagree with the style rule, but I don't feel like I'd win an argument with them about it.
dailyjs did a nice writeup recently http://dailyjs.com/2012/01/19/semicolons/ and isaac (npm guy) wrote a really good piece on it that I like better then mislavs http://blog.izs.me/post/2353458699/an-open-letter-to-javascr... . I don't even have a problem with people who want to put semi-colons all over the place, I am just tired of having to defend myself on why I choose not to. And it feels kind of odd that I have…
The reason you have to defend yourself is that your style is currently less idiomatic than their style. The caveat of non-idiomatic choices is that you have to defend them either indefinitely or until the idioms change, whichever comes first. What I find odd is when people make a non-mainstream choice and aren't willing to put in the effort to back it up - swimming against the stream is great, but you have to be able to explain to people why you're doing it or be tough enough to ignore them when they ask.
Re: The GitHub Styleguide
#56# 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.
Re: The GitHub Styleguide
#57[deleted]
Re: The GitHub Styleguide
#58I don't get why people are using RGB hex values. I guess all of us find it much easier to read and understand rgb(230, 30, 30) than #e61e1e. And if we don't have to support IE8, I think hsl(0, 80%, 51%) is even better.
Re: The GitHub Styleguide
#59They should have an HTML guide which should say: don't write tags which set an image's size to 4x less than its original size, it will look pixelated.
Re: The GitHub Styleguide
#60Can someone explain the use of // instead of /* */ for CSS comments? According to what I've always known, // isn't even valid.
Although any compressor or minifier will strip out comments, '//' comments in SCSS will be ignored even if you choose not to compress.
It's a really insignificant detail in and of itself, and zefhous' comment provides a far more substantial rationale.