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.
The GitHub Styleguide
61–70 of 82 posts
Re: The GitHub Styleguide
#62What'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…
I can't for the life of me figure out how to replicate the effect in vim to be able to read his files logically, and he can't tell me because he's an emacs user.
Re: The GitHub Styleguide
#63I 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…
Re: The GitHub Styleguide
#64I'd recommend adding: * Alphabetize properties within each CSS rule To here: https://github.com/styleguide/css
Re: The GitHub Styleguide
#65Earlier quoted context omitted.
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…
My coworker does some funky blend of spaces and tabs. His tab key inserts 4 spaces, but if he tabs twice (8 characters), it becomes the tab character. He says it works better when printing. I can't for the life of me figure out how to replicate the effect in vim to be able to read his files logically, and he can't tell me because he's an emacs user.
set ts=8 sw=4 et sta
(tabstops to 8 (the default), shift width to 4, expand tabs, smart tabs)
Re: The GitHub Styleguide
#66Earlier 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.
> 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.
Re: The GitHub Styleguide
#67Here'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/coffeescript
This isn't a debate as to whether or not CoffeeScript is better, easier, cleaner, etc. It's a simple A does not equal B statement, and it's starting to remind me of the way my boss says I'm "good at Java".
Re: The GitHub Styleguide
#68What's the reason for recommending 2 space indents ? I find it easier to read with 4 or even more spaces indent.
I enjoy 8-space indents, fellow programmers prefer 4-space indents, some others 2-space indents. With hard-tabs each of us is able to use their preferred settings without messing with the commits (setting the tab-to-space ratio in text editor).
Re: The GitHub Styleguide
#69I 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…
first time i heard that was from greg browns Ruby Best Practices book (was probably the best thing I took away from it). At this point (unfortunately) bang means almost nothing, since the reason to use bang seems to be different for every rubyist
The only example I know of is DataMapper that uses bang methods such as `save!` for the methods that change data bypassing the validation mechanism. But I would argue that this use fits the original definition quite nicely.
Re: The GitHub Styleguide
#70I 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…
Compare `some` and `every?` in Clojure:
http://clojure.github.com/clojure/clojure.core-api.html#cloj...
http://clojure.github.com/clojure/clojure.core-api.html#cloj...
And in Scheme `member` doesn't have a question mark for this reason, it returns the cdr of the list starting with the item if it's found.
It's a subtle point, and probably trips up newcomers, but I think it's useful, especially since the types of methods and functions in these languages are not as well broadcast as in statically typed languages.