Example #1 is actually a bad thing to do. This creates a new array every time you want to do the comparison. I've fixed multiple open-source libraries who abuse

Example #1 is actually a bad thing to do. This creates a new array every time you want to do the comparison. I've fixed multiple open-source libraries who abused this exact method, refactored them into the chained "and" statements, and seen a hefty performance increase as a result (MongoMapper and Haml come to mind) Example #3 suffers from unbalanced returns and is less clear in its intent than the original (albeit difficult to read) example. Instead, I'd propose: def my_method @blah == foo && :foo_matches || :no_match end This eliminates the visual problem of adjacent semicolons, while still being clear and concise. I'd argue that Example #4 is bad because it hides the expectation that nil should be returned in the negative case.