The GitHub Styleguide
github.com
The GitHub Styleguide
1–10 of 82 posts
Re: The GitHub Styleguide
#2Re: The GitHub Styleguide
#3No semicolons in javascript! This is subversive and should be suppressed.
Re: The GitHub Styleguide
#4No semicolons in javascript! This is subversive and should be suppressed.
It's pretty disappointing to see GitHub, a company that a lot of developers (including myself) look up to and will follow, espousing something like this.
Re: The GitHub Styleguide
#5No semicolons in javascript! This is subversive and should be suppressed.
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…
Re: The GitHub Styleguide
#6No semicolons in javascript! This is subversive and should be suppressed.
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.
Re: The GitHub Styleguide
#7Earlier 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.
Re: The GitHub Styleguide
#8No semicolons in javascript! This is subversive and should be suppressed.
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…
If you are still using something like packer, that bit of advice will take about 5 minutes of work, and give you significant decreasing of file size.
Semi-colons need to be in 1 place, the beginning of a line that starts with a (, since that is the one place that automatic semicolon insertion will really screw you. If it makes you feel good to write a semi colon at the end of every line I don't think anyone is stopping you, but it isn't the language or tools that require it. You can also feel free to explicitly wrap every statement in parens (because it is necessary in a few cases), or end each line with a // after your semi-colon, all these are freedoms the language gives you, but are as necessary as semi-colons.
I haven't been using unnecessary semi-colons in js for years, and have yet to run into a problem.
Re: The GitHub Styleguide
#9No semicolons in javascript! This is subversive and should be suppressed.
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.
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 to, because I am not the one adding redundant characters everywhere
Re: The GitHub Styleguide
#10"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 latter is far more dangerous (in the generic case). It's not just about the danger level of the method but about the existence of a non-dangerous alternative. Now I've started noticing that some gems do not follow this guideline.