Hi!

So I got ahead of myself on this one, and described ternary operators in the context of an improvement to some front-end work in the last post. That said, I’ll mention it again here, as I learned the ternary operator syntax from Coraline Ada Ehmke in our last pairing session together. This syntax provides a terse alternative to the if statement. Here’s how it looks:

Here’s an explanation in English of what’s happening in the above depicted code snippet:

.map: Create an array called @each_month. For each element in the array called @days,

Date.parse(day.to_s): parse that element to a string and,

ternary operator (the ? and : line): if it is at the beginning of the month, then inject into @each_month a string with that date (specifically just the month and year), otherwise inject into @each_month an empty string. 

ADDENDUM: Last night I was speaking to another Rubtyist mentor, and I mentioned my excitement at learning the ternary operator. A fleeting twitch of exasperation darted across my interlocutor’s face right before the response: “Yeah, the ternary operator is just jamming an if statement onto one line.”

I thought about it. That’s true, it is. Also, one could argue that the ternary operator is a step away from intuitively written code: if you had never seen the above syntax before, you’d have a snowball’s chance in…well, someplace very hot, of intuiting what it was supposed to mean. So, naturally…

TO THE INTERNET!

Naturally, there are a plethora of opinions on whether or not to use the ternary operator as opposed to an if statement. I am, as yet, too much of a fledgling user to prescribe a doctrine of my own. That said, I’ll begin by experimenting with the following rule:

1. I will use them when I will need not just if but rather if...else. This way, it’s serving the purpose of cutting down on more lines of code without becoming confusing. In the case of if alone, particularly in Ruby, I’ll stick to the (predicate) if (condition) syntax.
2. I will use them when the result would be shorter than an 80 character line. Otherwise, it’s no longer serving the purpose of shortening things.
3. I will not nest them.

Perhaps these rules are too general, and as I go along and find exceptions, I might refine them until I have explicit rules for using different pieces of syntax, Kent Beck style. If you have suggestions for refining these rules, feel free to comment (politely)!

Here’s another thing Coraline and I talked about in this pairing session: scope. 

Scope, of course, refers to the body of code to which a piece of code refers and applies. If a variable is out of a method’s scope, the method can’t use the variable. So we can have pieces of code that are inside the scope of a loop (for loop or if loop), inside the scope of a method, inside the scope of a class, or inside the scope of several classes. This is not a new concept in programming, but Coraline’s metaphor for how a computer determines scope seemed particularly apposite to me.

Picture a spring-loaded stack of cafeteria trays. 

The one on top is your most specific scope: let’s say we’re talking about the block variable inside an if loop. When the loop ends, that tray gets popped off the stack, and now we’re inside the next largest scope…the method. And so on, all the way up to a variable visible across multiple classes (picture a public or protected variable instantiated inside a superclass. This is the part where all the Java-ists yell at me. Guys, it’s just an example, jeez).

Now, what would be cool is an IDE tool that highlights the scope of a piece of code when that piece of code is hovered over. Hmmm….I might have a new project on my hands (after mapper, of course. Right now, turning mapper into a polyglot IDE tool is my epic flag-on-the-mountain project, and I don’t need two  of them to get constantly distracted from).