rubygrumble.md

An Unordered and Incomplete List of Things You Should Probably Never Use/Do in Ruby

(thanks to Zach Drayer and Ben Stiglitz for their feedback)

0. Don't use the implicit $_ style parameters where any reasonably sane person might expect a parameter, like #puts.
1. Don't use the string-manipulation methods included in Kernel, like chomp, chop, sub, and gsub. Call them on String instances instead. If you use these methods in combination with $_ style parameters, you are why we can't have nice things.
2. Don't use callcc, because it's inefficient, leaks like a sieve, and isn't included in most implementations.
3. Don't call Array#pack or String#unpack to store data. YAML/Marshal are more powerful and miles saner.
4. Don't use Kernel#test. Come on, this isn't Perl. Compare the fields of File.stat instead.
5. Don't use Kernel#syscall or IO#syscall. You shouldn't even do this in C.
6. Don't use IO#fcntl and IO#ioctl. If you need this, you should be writing in C, not Ruby.
7. Don't use load or autoload. Use require, preferably with a call to File.expand_path(__FILE__) to ensure requires are not performed more than once.
8. Don't use & or | when you mean && and ||. They have subtly different behavior in that they don't short-circuit evaluation.
9. Don't use the flip-flop operator. (Bet most of you didn't know about that one).
10. Don't use the timeout() method. That is not how threads work. If you need functionality like that, use signals.
11. Don't assume that marking methods private or protected means they're any more difficult to call. It's fine to use them to indicate intent, but don't think they provide any level of safety.
12. Don't use zsuper (super invoked without any parentheses), due to unpredictable behavior when it's captured by procs or lambdas.
13. Don't use Kernel#caller, because no mortal can figure out its semantics when blocks and lambdas enter the picture.
14. Don't open up or override methods in BasicObject, Module, or Kernel. No good will come of it.
15. Don't use and or or. No, they are not aliases to && and ||. Yes, this will trip you up.
16. Do not use the casting methods - Array(), Float(), String(), etc. - present in Kernel. Idiomatic Ruby code takes advantage of duck typing to the fullest extent possible.
17. Do not be clever with regards to constant lookup in namespaces. Do not trust code that overloads Object#const_missing.
18. Do not use class variables. They do not behave like you think they do.
19. Do not use the global magic variables - $!,$@, $&, and the like. If you must refer to them, require 'English' provides you with readable names.
20. Do not omit the parentheses in method declarations. It looks hideous.

Now get the hell off my lawn.

Awesome list, I love you for that. I don't do a lot of Ruby, so I'm probably not even qualified to comment on this; but I like to use only the parentheses that are required for the parser to know what the hell I'm talking about. Just my unworthy two cents.

Array#pack and String#unpack are for speaking binary protocols, not pickling objects.
Array() is useful when the parameter can be either an array or a single value.
private and protected are for communicating intent to other programmers.

You should write a static analysis testing program to check for these things. I wonder what percentage of github would pass the test.

Addendum 19.1: Really, REALLY don't use class variables in Modules. They REALLY don't work like you think they do and will lead to exceedingly cryptic bugs! (Yes, this is experience talking here...)