blah = blah blah blah blah blah blah blah blah +
blah blah blah blblah blah blah blah +
blah blah blah bla blah blah blahh blablah +
sdfgdfgdfhfgh
is a good practice? With the operators hidden all the way to the right, each at a different column, forcing you to scan for the end of the lines to find out where does the statement end? Well, up to you. I find this incredibly ugly.
Ad 2) Sorry, no that's not true. All Ruby does is it makes the warnings turned on by use warnings 'uninitialized'; fatal. It has no way whatsoever to catch even something as simple as
result = foo(...)
do something with result
...
resutl = bar(...)
do something with result
There is no way to specify that one assignment is supposed to be "initialization" and another not. Which means that some operations on variables are kinda guarded, others are not. Because they are undistinguishable from intended initializations.
Another problem is that you CAN'T declare a variable as being private for a block. You can only hope you do not stomp on an outer variable accidentaly. Or create an outer variable later and break stuff. At least the block parameters will always be local to the block starting with 1.9, but I still will not be able to start using a variable within a block without having to look elsewhere to make sure it really is a new variable. And no, all methods cannot be those advertised 5 lives long, if only because of data literals.
| 