Ruby doesn't have something like PEP for Python?
The GitHub Styleguide
21–30 of 82 posts
Re: The GitHub Styleguide
#22Can someone explain the use of // instead of /* */ for CSS comments? According to what I've always known, // isn't even valid.
They are using .scss, so // is valid there.
Prefixing each commented line is more efficient in text editing than wrapping things in blocks. Editor support for mappings to comment out sections of text are more consistent in supporting prefixing each line and removing that than wrapping and unwrapping a selection with the block syntax.
Also, that way you can comment out a larger section and subsequently uncomment a part of that section with a single action instead of uncommenting the entire thing, then re-commenting the part that you still want commented out.
Re: The GitHub Styleguide
#23Can someone explain the use of // instead of /* */ for CSS comments? According to what I've always known, // isn't even valid.
They are using .scss, so // is valid there. Prefixing each commented line is more efficient in text editing than wrapping things in blocks. Editor support for mappings to comment out sections of text are more consistent in supporting prefixing each line and removing that than wrapping and unwrapping a selection with the block syntax. Also, that way you can comment out a larger section and subsequently uncomment a par…
Ah, gotcha. I read "CSS" and just, you know, assumed "CSS".
Re: The GitHub Styleguide
#24I'd recommend adding: * Alphabetize properties within each CSS rule To here: https://github.com/styleguide/css
I strongly prefer logically grouping related styles.
The only advantage from alphabetizing rules is perhaps slightly faster scanning of rules, but I don't think it is even very helpful in doing that. You generally don't have that many rules in a single style anyway so it's not a problem that needs solving.
However, by grouping related styles I think there are a some small yet worthwhile advantages. Grouped styles can reveal intention, while alphabetizing does not at all. Grouped styles can also make refactoring quicker and less tedious.
Re: The GitHub Styleguide
#25After 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 idiomatic as possible in those cases.
Re: The GitHub Styleguide
#26 # bad
email_with_name = user.name + ' '
# good
email_with_name = "#{user.name} "
# better
email_with_name = "%s " % [user.name, user.email]Re: The GitHub Styleguide
#27No mention of the maximum line length in the Ruby style guide. Sigh...
Re: The GitHub Styleguide
#28Ruby doesn't have something like PEP for Python?
Only unofficial
Re: The GitHub Styleguide
#29Earlier quoted context omitted.
Their justification attributes a blog post where the author basically says "don't use tools that will break your code if you omit these syntax features". It encourages people to write code that will break when used by others, dictating the tools they can and can't use. It's the equivalent of a child closing their eyes and sticking their fingers in their ears to magically whisk away the person standing next to them. I…
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?
Re: The GitHub Styleguide
#30Scanning 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
I'd agree with you if not for the many subtle and critical bugs I've seen introduced into our production environment due to and/or precedence problems. The increased expressiveness when used correctly is just not worth it.