"Trans" <transfire / gmail.com> wrote in message news:2d146480-3006-421a-9204-153fce5cf3c8 / e23g2000prf.googlegroups.com... > > > On Dec 8, 7:55 pm, "Just Another Victim of the Ambient Morality" > <ihates... / hotmail.com> wrote: >> So, I had a conversation with a colleague of mine and he brought up a >> feature request for another language that is a lot like Ruby but is not >> Ruby. It was an interesting request and, after I had thought about it a >> bit, I discovered that I would like this feature, too! >> >> The two most popular sources of bugs for me when programming in Ruby >> are: >> >> 1) Passing the wrong object as a parameter to a method. > > def some_method(a,b,c) > contract_for_some_method(a,b,c) if $DEBUG > ... > end > > def contract_for_some_method(a,b,c) > raise ArgumentError unless a.is_a?(Foo) > raise ArgumentError unless b.is_a?(Bar) > raise ArgumentError unless c.is_a?(Baz) > # or whatever > end This is interesting but kind of overkill. Checking for a contract is a non-trivial, especially if you want to keep duck-typing. This would increase programmer effort so much that it would become comparable to programming in C, I think... >> 2) Accidentally creating a new variable. >> >> Unfortunately for me, very little can be done about my first point. >> I >> understand and enjoy the power of duck-typing, which specifically allows >> me >> to exercise this bug. >> However, something can be done about the second point. Let me >> exemplify >> the problem: >> >> list = create_useful_list >> >> if should_modify_list(list) >> # I meant to modify the variable "list" here... >> liist = modify_list(list) >> end >> >> use_list(list) >> >> ...obviously, this is a seriously contrived example but it should >> clarify my point. I so amazingly meant to assign to the pre-existing >> variable "list" but I accidentally created a new variable. It's not even >> typos with me. I often thought I named a variable something descriptive >> when I actually named it something else equally descriptive. This can be >> a >> surprisingly annoying bug to track... >> A solution to my problem would be to require variable declarations. >> Something like the "my" keyword of a strict PERL script. Ruby would >> probably not use "my," despite its PERL roots. Maybe "var?" >> >> var list = create_useful_list >> >> if should_modify_list(list) >> # A compile time error will occur here... >> # ...after 1.9 is released... >> liist = modify_list(list) >> end >> >> use_list(list) >> >> What do you all think? >> Thank you... > > Why do you have troubles like this? How big are your methods? Keep > them small and this, I think, would be very rare. They're not that big. Having said that, it's often hard to keep a method definition too small 'cause, well, sometimes there's a lot to do! Sometimes there's a lot to do that's inherently related and splitting that up would serve no logical purpose other than to keep the method definition small. Finally, I've actually worked with entire programs where no function body was more than six lines of code. It wasn't understandable nor easy to work with. It was extremely difficult to tell what any function did and it was difficult to modify code to do something else. I don't think artificially keeping method definitions small necessarily solves anything... > The most annoying bug I ever have is tracking an errant "end". I've had this problem, before, but luckily it's quite rare for me. Perhaps it's because I've gotten into the habit of typing out my loop bounds before filling in the loop body. I've always considered this a bad habit of mine but perhaps it's not so bad...