Are tricks good? Sometimes, yeah. Are tricks bad? Sometimes, yeah. So when are they good and when are they bad? Totally depends on the coder, the context, and the trick. Take this one from last weeks Portland Ruby Brigade:
while gets
prints if ($_~/^Igal:$/)..($_=n/^$/)
end
What do you see there? If you didn’t shrug then you’re either a) the guy who wrote it or b) a genius. What’s in there is not the range operator but the little known flip flop operator. Check it out;
irb(main):010:0> items = [3, 9, 5, 2, 2, 8, 5, 9, 2, 2]
=> [3, 9, 5, 2, 2, 8, 5, 9, 2, 2]
irb(main):011:0> puts items.collect {|item| item if (item < 4)..(item > 4)}
3
9
2
2
8
2
2
Those blank spots are where the flipflop operator has been set to false. Still, I’m not a huge fan of that for readability reasons. It’s kind of like someone going Iron Chef at breakfast. Sometimes I just want toast, you know? Anyways, back to Peter Cooper and his bag o Ruby tricks. Some of them are pretty good. I like this:
# [*items] converts a single object into an array with that single object
# of converts an array back into, well, an array again
[*items].each do |item|
# ...
end
Didn’t know that. Actually, that’s only the one I like most because I like a lot of them. 16 is good, 12, most of them. #8 though, that one gives me the heebie-jeebies.
does = is = { true => 'Yes', false => 'No' }
does[10 == 50] # => "No"
is[10 > 5] # => "Yes"
He admits it’s not the best example, but still, I’d hate to come across that. The nested ternary stuff freaks me out a tiny bit as well. So that brings me to another thing: I spend a lot of time reading code and writing code, but more reading it than writing it and more time using it than reading it. That gives me an order of preference: if you really are doing it for performance (note the quick discuss of the !! operator in the comments of Peters blog post, or some crazy ass inline ASM blitting code or whatever) then by all means have at it, homes. I will assume that you know your stuff backwards and forwards and that if I want to dig into what you’re doing I’ll be rewarded with sweet sweet nectar of performance gains. If you’re not getting a performance gain, because reading is #2 on my list of things, I’m inclined to say that maybe you should make it easier for me to read and understand. Not just me in particular, but me as in anybody else. Everybody has to know lots of programming languages today and it’s nice to speak in a way that everyone can understand given the multiple things they have to have floating around in their heads. Let’s try a not-entirely-accurate metaphor: everyone (pretty much) has to know English to do science. Now, I know English really well, does that mean I should go to the conference and start speaking to everyone in Joycean type punnery just because I can? Nah, probably won’t make many friends doing that. I should go and assume that it’s better to say: “Would you like to go for a walk around the campus after lunch?” than “Fancy a campus circumnavigation post-prandially?” or “Walkabout post-nosh?”. See, one’s more letters and words, but isn’t difficult for those who aren’t in my particular little group, my group being either people who know that I like to say things like “walkabout” for “walk around wherever we happen to be” and so on, or people who know I like fancy Latinate words (I actually don’t). That’s actually part of the sociological function of slangs and specialized languages: to tell you who’s in and who’s out. Back to programming languages, I’m not in on the Ruby world, and I’m definitely not in on the Perl world, so lots of the super-idiomatic things that can be done to condense without performance gain strike me as a bit funny, the same way parlor tricks strike me as funny: funny in the parlor, not in the not-parlor.
