As a Ruby programmer did you feel any time about any feature which is a bit risky to use, may be because of it's strange behaviour? It might be well documented but hard to find while debugging or counterintuitive to remember?
I generally try to stay away from String#gsub!. The doc says "Performs the substitutions of String#gsub in place, returning str, or nil if no substitutions were performed." So if there's nothing to substitute then it'll return nil. Practically I didn't see any use case where this comes handy.
SO, with your experience, is there anything else you'd like to add?
Using return in a lambda, Proc or block. The semantics are well defined, but you will get it wrong, and you will get a LocalJumpError.
The meta programming features of Ruby can be used in very dangerous ways. I've seen code that attempts to runtime-redefine common methods on code classes like String, or Array, and while I can see this being MAYBE acceptable for a tiny temporary script, I don't think it is remotely a good idea in a complex application with many dependancies, or many maintainers.
Well, the most widely abused dangerous feature of Ruby is certainly evaling strings. In vast majority of cases (if not all) it can be avoided using other methods, usually define_method, const_get, const_set etc.
throw/catch (not the same as begin/rescue!) is basically GOTO, and that could be considered to be a risky feature to use in any language.
Related
For example, is it theoretically safe to modify Object#object_id since there's always Object#__id__ if you really need to know what an object's id is?
Background: Curiosity piqued by What's another name for object_id?
In an ideal system where everything is perfectly documented and all people working with the code are aware of what's been re-defined and patched - then yes, maybe.
But as we all know, such situations rarely exist. Personally, I feel that patching anything already defined in Kernel, Class, Module or Object is a no-no (unless you're doing it at a framework level.)
Ultimately, I believe that Principle of Least Surprise should permeate coding decisions at all levels.
is it theoretically safe to modify Object#object_id
Well, I think we are probably more concerned with reality than theory here. The fact is, people aren't going to use the __X__ version until they realize that you have overriden and completely jacked up the default behavior. With power comes responsibility; use monkey-patching carefully and never introduce unexpected behavior. Better just to add a new method to the class instead.
Ruby's duck-typing is great, but this is the one way that it bites me in the ass. I'll have some long running text-processing script or something running, and after several hours, some unexpected set of circumstances ends up causing the script to exit with at NoMethodError due to a variable becoming nil.
Now, once it happens, it's usually an easy fix, but it would be nicer if I could predict these better, or at least handle these types of errors more gracefully. Sorry for the vagueness of the question, but this type of error just happens too often to me and I wonder if there's a good way to avoid it.
Is there some best practice related to these kinds of "type errors" for Ruby?
Look up Design by Contract. It's useful in many programming paradigms, but it's particularly useful when you don't have a compiler to help you catch these sort of errors, of forbidding particular sorts of values for a parameter.
In essence, DbC allows you to make an assumption about a parameter. It allows you (in all but one place) to skip the mundane checks that guarantee this assumption to hold.
What about Object.nil?
It seems to me like Ruby has a lot of syntactic flexibility, and many things may be written in several ways.
Are there any language features/syntactic sugar/coding conventions that you avoid as a Ruby programmer for clarity? I am asking about things that you choose not to use on purpose, not stuff you still have to learn.
If your answer is, "I use everything!," do you ever comment code that would be otherwise obvious if the reader knows the relevant Ruby syntax?
[I'm particularly interested in Ruby in a RoR context, but everything is welcome.]
The whole range of "$" globals (see Pickaxe2 pp333-336) mostly inherited from Perl, are pretty ghastly, although I have on occasion found myself using $: instead of $LOAD_PATH.
I generally refrain from going overboard with monkey patching because it could lead to some maintainability and readability issues. It's a great feature if used correctly, but it's easy to get carried away.
The for ... in ... loop. It directly compiles to obj.each (and throws a strange error message accordingly) and is totally unnecessary. I don't even see where it improves readability - if you've been around ruby for more than a week, #each should be natural.
This might be obvious but I generally avoid using eval if there's any alternative.
First off: I'll break many of these rules if it's for a short one-off script, or a one-liner on the command line, or in irb. But most of my time is spent in medium sized or larger scripts or applications. So:
Avoid:
using class << self code block for class methods. It's a cute trick, but no better than def self.foo, and less readable (especially after the first page).
for i in collection: Use collection.each instead.
proc {...}: usually lambda {...} is better.
class variables (e.g. ##foo). They are problematic and can usually be replaced with class-level instance variables without much effort.
Anything that causes a warning, and preferably anything that causes a warning when run via the more strict ruby -w. This is especially important if you are writing a gem to be used by others.
'else' on a 'begin ... rescue ... end' block. Personal preference: It's too much of an edge case and so few people even know it exists or how it works to be worth it.
ObjectSpace and GC. You probably don't need to go there. You definitely don't want to go there.
=begin and =end multi-line comments. Personal preference for line-wise comments. These just annoy the hell out of me.
Use it, but sparingly or as a last resort (and comment it appropriately):
eval (or class_eval, etc) when passing in a string. There are some metaprogramming tricks you just can't do without passing in a string. And occasionally, the string version performs dramatically better (and sometimes that matters). Otherwise, I prefer to send in blocks of actual ruby code for my metaprogramming. eval can be avoided entirely for many metaprogramming tasks.
Adding or redefining methods on classes which were not created by me and may be used by code outside my control; a.k.a. monkey-patching. This rule is mostly for larger codebases and libraries; I'll gladly and quickly make an exception for small one-off scripts. I'll also make an exception for fixing buggy third-party libraries (although you may shoot yourself in the foot when you upgrade!). Selector namespaces (or something similar) would go a long way to make ruby nice in this regard. That said, sometimes it is worth the trouble. ;-)
Global variables (except for classes). I'll even pass in $stdout as a parameter to my objects or methods, rather than use them directly. It makes re-use of the code much easier and safer. Sometimes you can't avoid it (e.g. $0, $:, $$ and other environmental variables, but even then you can limit your usage).
speaking of which, I prefer to limit my usage of the perlish symbol globals entirely, but if they need to be used more than a little bit, then require "English".
break, redo, next, try: Often they make a block, loop, or method much more elegant than it otherwise could be. Usually they just make you scratch your head for a few minutes when you haven't seen that code for a while.
__END__ for a data-block. Excellent for a small one-file script. Unhelpful for a multi-file app.
Don't use it, but don't really avoid it either:
try/catch
continuations
Things I use often, that others might not care for, or I don't see often:
'and' and 'or' keywords: they have different precedence from && and ||, so you need to be careful with them. I find their different precedence to be very useful.
regex black magic (provided I've got some examples in unit tests for it)
HEREDOC strings
One thing I really loathe is "improper" use of {} and do ... end for blocks. I can't seem to find exactly where I learnt the practice myself but it is generally accepted to do {} for single line blocks and do ... end for multiline blocks.
Proper use:
[1, 2, 3, 4].map {|n| n * n }.inject(1) { |n,product| n * product }
or
[1, 2, 3, 4].inject do |n,product|
n = n * n
product = n * product
end
Improper use:
[1,2,3,4].map do |n| n * n end.inject(1) do |n,product| n * product end
or
[1, 2, 3, 4].inject { |n,product|
n = n * n
product = n * product
}
All of which, of course, will execute giving 576
Avoid chaining too many method calls together. It is very common in Ruby to chain methods together.
user.friends.each {|friend| friend.invite_to_party}
This may seem ok, but breaks Law of Demeter:
More formally, the Law of Demeter for functions requires that a method M of an object O may only invoke the methods of the following kinds of objects:
O itself
M's parameters
any objects created/instantiated
within M
O's direct component objects
The example above isn't perfect and a better solution would be something like this:
user.invite_friends_to_party
The example's problem isn't Ruby's fault but it is very easy to produce code that breaks Law of Demeter and makes code unreadable.
In short, avoid features that decreases code readability. It is a very important that the code you produce is easy to read.
begin nil+234 rescue '' end
above syntax is valid, but you should never use it.
What are the things you wish Ruby (and more generally the Ruby community) would improve?
I read somewhere that Ruby is the love-child of Smalltalk and LISP, with Miss Perl as the Nanny.
I have a lot of respect for Ruby's parents, but I'm not sure I like the influence Miss Perl had on the child. Specifically, I don't like the predefined variables: I need a cheat sheet to know what they mean. You could say "just don't use them". Well, I don't... but other people do. And when I download a plugin on the Web, I have no choice but to fetch my cheat-sheet if I ever need to go and touch the source code. I just wish they would remove those from the language itself.
Also, I think that Ruby is too much of a moving target. My code breaks on every new Ruby upgrade, even on minor releases. This is true also of Ruby on Rails and most Rails plugins I have worked with: they just change all the time, and nobody seems to care whether the changes break everything or not. IMHO, although I love a lot of things in Ruby, this lack of stability is almost a show-stopper.
I wish people would consider backward compatibility between minor releases as an unbreakable rule when releasing a new language (or library or framework) version.
I wish that some of the lesser used modules of the standard library were documented.
Make require-ing files less painful. Don't ask me how, but maybe have one file dedicated to knowing the paths involved and just get rid of the relative path crud from everything else.
Getting rid of the artificial distinction between Modules and Classes would be nice.
Both Modules and Classes are Namespaces. Modules are also Mixins, while Classes aren't. Classes can also be instantiated while Modules can't. This distinction is unnecessary. Just get rid of Modules and allow Classes to be used as Mixins.
An example of a language where this works is Newspeak.
I'd appreciate being able to install ruby 1.9 as an RPM rather than having to use the source.
Make Ruby completely Message Sending based, get rid of everything that is not a message send: local variables, global variables, instance variables, class hierarchy variables, constants, magic globals, magic constants, builtin operators, builtin keywords, even literals. See Self, Ioke or Newspeak for the incredible power and elegance this gains.
I wish they would get rid of the predefined variables: $!, $&, $+, etc.
I would like to have support for static compile-time metaprogramming. The Converge Programming Language might be a good starting point.
Replace the Mixin system with a Traits system.
Replace Exceptions with a Common Lisp style Conditions system.
I'm learning Ruby in my spare time, and I have a question about language constructs for constants. Does Ruby have an equivalent of the C++ const keyword to keep variables from being modified? Here's some example code:
first_line = f.gets().chomp()
column_count = first_line.split( %r{\s+} ).size()
print column_count, "\n"
I'd like to declare column_count to be const, because I use it below in my program and I really don't want to modify it by mistake. Does Ruby provide a language construct for doing this, or should I just suck it up and realize that my variables are always mutable?
Response to comments:
'The most likely cause of "accidental" overwriting of variables is, I'd guess, long blocks of code.' I agree with the spirit of your point, but disagree with the letter. Your point about avoiding long blocks of code and unnecessary state is a good one, but for constants can also be useful in describing the design of code inside of the implementation. A large part of the value of const in my code comes from annotating which variables I SHOULD change and which I shouldn't, so that I'm not tempted to change them if I come back to my code next year. This is the same sentiment that suggests that code that uses short comments because of good variable names and clear indentation is better than awkwardly written code explained by detailed comments.
Another option appears to be Ruby's #freeze method, which I like the look of as well. Thanks for the responses everyone.
Ruby variables in general are, well, variable.
Beyond Jeremy's answer, while entirely accurate, doesn't lead you to a Ruby style that's very "mainstream" or idiomatically sound and I wouldn't recommend it for adoption. Ruby doesn't work like C++ and generally isn't very appropriate for things that C++ is best used for. Operating systems, word processors, that kind of thing.
The most likely cause of "accidental" overwriting of variables is, I'd guess, long blocks of code. After all, if you change the value of a variable in a five-line method, it's going to be fairly apparent! If you're habitually writing blocks of code longer than, say, 10 lines, then those chunks are probably doing too many things and I strongly advise that you make efforts to break them up (increase cohesion). Localise variables as much as possible to minimise the chance of unexpected side-effects (reduce coupling).
By convention, constants in ruby are generally written in all caps such as COLUMN_COUNT. But as it was pointed out, all variables that start with a capital letter are Constants.
Variables that start with a capital letter are constants in Ruby. So you could change your code to this:
first_line = f.gets().chomp()
Column_count = first_line.split( %r{\s+} ).size()
print Column_count, "\n"
Now you'll get a warning if you try to modify Column_count.