tag:blogger.com,1999:blog-1502761093196431512.post7216824340116149086..comments2024-01-06T14:58:41.477+11:00Comments on Ruby-coloured glasses: acts_as_good_styleTaryn Easthttp://www.blogger.com/profile/00647732421144825421noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-1502761093196431512.post-31264118053455786712011-03-06T23:43:41.985+11:002011-03-06T23:43:41.985+11:00Great article! ThanksGreat article! ThanksAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-1502761093196431512.post-16135208299115984442010-12-03T04:43:32.128+11:002010-12-03T04:43:32.128+11:00I have been writing shoulda tests recently, I ofte...I have been writing shoulda tests recently, I often end up writing lines like:<br><br /><i>should "blah" { assert something }</i><br /><br />This doesn't work, because Ruby can't figure out that the block should be passed to the <i>should</i> method.<br /><br />Instead, you have to put the argument in parentheses:<br><br /><i>should("blah") { assert something }</i><br><br />or you can use the do ... end instead:<br><br /><i>should "blah" do<br /> assert something<br />end</i>Jonathan O'Connornoreply@blogger.comtag:blogger.com,1999:blog-1502761093196431512.post-41197039243892850312009-11-30T22:35:52.569+11:002009-11-30T22:35:52.569+11:00@GS - bracing styles are nearly almost completely ...@GS - bracing styles are nearly almost completely aesthetic. You have great reasons for using your style. I have great reasons for using mine... if either one insists - it tends to descend into holy war ... so the best policy tends to be: whomever came first won already - from then on, follow the same convention.Taryn Easthttps://www.blogger.com/profile/00647732421144825421noreply@blogger.comtag:blogger.com,1999:blog-1502761093196431512.post-23279848368500050832009-11-30T22:34:03.677+11:002009-11-30T22:34:03.677+11:00@Andrew yep - I agree. I've had similar issues...@Andrew yep - I agree. I've had similar issues, but I've started to use 'if foo.present?' just to turn it into a positive statement. Purely for aesthetic reasons. :)Taryn Easthttps://www.blogger.com/profile/00647732421144825421noreply@blogger.comtag:blogger.com,1999:blog-1502761093196431512.post-45127968281219973602009-11-29T22:18:06.529+11:002009-11-29T22:18:06.529+11:00Nice work. My dissenting comments:
1. and/or vs ...Nice work. My dissenting comments:<br /><br /><b>1. and/or vs &&/||</b><br /><br />It's worth knowing the difference and using them accordingly. Use the words "and" and "or" for boolean expressions (i.e. where you are testing whether some compound thing is true or false, like "if a == 4 and c.nil?"). Use the symbols "&&" and "||" when you want an actual value, like "a = foo() || 5".<br /><br />Code is clearer when the right tool is used for the job, IMO.<br /><br /><b>2. do/end vs {}</b><br /><br />For me, it doesn't matter whether the block is one line or many. "do" sounds like a command, so I use do/end when I'm <i>doing</i> something (i.e. I don't care about the return value).<br /><br />{} is when I am using a block to generate a value.<br /><br />Examples (both one-liners):<br /><br />words.each do |e| puts e.upcase end<br /><br />words = words.map { |e| e.upcase }<br /><br />This may be a minority approach, but there's a lot of sense in it. It's worth at least considering this style rather than defaulting to the wisdom of the crowd.GShttps://www.blogger.com/profile/01653295877269914726noreply@blogger.comtag:blogger.com,1999:blog-1502761093196431512.post-10866173601023102052009-11-28T10:40:53.170+11:002009-11-28T10:40:53.170+11:00I tend to prefer "unless foo.nil?" rathe...I tend to prefer "unless foo.nil?" rather than "if foo", as I worry that the latter may be an incomplete statement.Andrew Grimmhttps://www.blogger.com/profile/10437460347464001759noreply@blogger.comtag:blogger.com,1999:blog-1502761093196431512.post-89148392128136199272008-04-01T12:39:00.000+11:002008-04-01T12:39:00.000+11:00I originally pulblished this in August last year. ...I originally pulblished this in August last year. Since then I've continually added to it - but it's kinda dropped below the radar in my "archives" section.<BR/><BR/>So I've done a quick overhaul and added a few more things, and now I'm dragging it back into the sunshine again.Taryn Easthttps://www.blogger.com/profile/00647732421144825421noreply@blogger.comtag:blogger.com,1999:blog-1502761093196431512.post-91894087709157817822007-09-08T11:50:00.000+10:002007-09-08T11:50:00.000+10:00Thanks. :)On a previous project we got caught by v...Thanks. :)<BR/>On a previous project we got caught by validations we thought were happening - but weren't... so it just makes sense to test for it now.<BR/><BR/>One of our developers was grumbling aout "doubling up" on the work (doing validation testing in both unit and functional), which is why I explained the reasoning here. But he's never experienced the problems that can happen if you don't do it, so he's still only partially convinced. If we had the time to spare I'd let it slip and let him see what can go wrong, but no real project has that sort of time to spare.Taryn Easthttps://www.blogger.com/profile/00647732421144825421noreply@blogger.comtag:blogger.com,1999:blog-1502761093196431512.post-59671255096844118902007-09-07T00:32:00.000+10:002007-09-07T00:32:00.000+10:00Taryn, I'd like to thank you for the great post. I...Taryn, I'd like to thank you for the great post. I've seen the same styles over and over but had never seem them summarized the way you did.<BR/>The tip about "test your validations" is really nice. I've been doing the same thing with my models, using RSpec.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1502761093196431512.post-47674461353611871752007-08-24T22:44:00.000+10:002007-08-24T22:44:00.000+10:00Thanks! I've been building it up as I've been teac...Thanks! I've been building it up as I've been teaching the other developers about Rails. It's much easier to point them at that to give them an overview of the style we use (and why).<BR/>After all, everyone says "well, I've started reading the agile book, but now I'm so busy working on the release..." :)Taryn Easthttps://www.blogger.com/profile/00647732421144825421noreply@blogger.comtag:blogger.com,1999:blog-1502761093196431512.post-11890550675245560012007-08-24T09:39:00.000+10:002007-08-24T09:39:00.000+10:00Taryn, that's excellent post. I haven't seen such ...Taryn, that's excellent post. I haven't seen such a concise and thorough list of ruby programming idioms published anywhere, including in the relevant books on the subject.Anonymousnoreply@blogger.com