Love Hate

Is there a language feature you absolutely adore? For me it's closures. Blocks in Ruby make me warm and fuzzy, and anonymous functions in JavaScript make me giddy. Anonymous classes in Java make me... puke. Sorry, Java just doesn't have good closure support.

If you have a language feature you adore, chances are good that there is a language feature you loath. For me, it is the ternary operator. I don't care which language you are talking about, ternary operators cause me to run in the corner and hide, cowering, and waiting till they go away, on their merry business.

Perhaps it is a bit of an irrational loathing. I like dense code, but I want my dense code to be readable. I find nothing wrong with something like:

str = list.map { |x|
  x * x if x
}.compact.uniq.sort.join ","

But write something like:

str = value.nil? ? "null" : "'#{value}'"

And I will refactor your code. Whatever the case, a ternary operator makes me stop and think more carefully about what is going on whenever I see it. Code nirvana, to me, means code that is intuitive and self documenting. Method names like compact, uniq and sort all lend themselves to self documentation. The ternary operator, on the other hand, feels cluttered and doesn't lend itself to immediately understanding what the purpose of the code is.

I will go to great lengths to avoid a ternary operator. I prefer the more verbose if control structure. Ruby makes the deal even sweeter since an if is an expression (like everything else in the language). I will happily pay the cost of the added lines of code, though, if it means I can stay clear of any ternary code.

If you feel you must use a ternary, do me a favor and use just one per expression. Not just use one, do nothing else on that line of code, so the ternary avoids external clutter to make it even more non-obvious what is going on in the code.

Are there language features that make you cringe every time a fellow developer uses it, regardless of context?

C# Regions and Style

Often, Jeff Atwood has insightful and interesting things to say. I very often agree with his viewpoint, though every now and then it just doesn't quite sit well. That's probably important, to be sure that I am reading with a critical eye and not just taking his word on blind faith. The reason I start with this is his most recent post just didn't sit well with me.

I worked with C# at my last job. It had its perks and its problems, and it was a Microsoft product, which adds instant negative baggage (sorry Jeff, despite enjoying your writing and podcast material, I don't think I will ever understand your appreciation of Microsoft products). One thing I did like was #regions. C# is about as verbose as Java (at least it was before 3.0, which I never got to use but have heard they improved things a bit). As such, this often leads to large code files, especially in GUI code that has tons of event handlers and special setup code. I found at my last job that a small sprinkling of regions helped organize my code quite well. I could keep all methods of a particular type grouped together with the ability to toggle the code at will. Some of my favorite groupings were "Event handling", "Constructors" and "Utility methods". It just seemed cleaner to keep things together that are semantically similar. Though I prefer Java and (even more so) Ruby, Regions is one thing I wished I could take from the Microsoft world into the rest of the world.

He is completely right that it can be abused, though. I saw plenty of other code in the project that would simply have regions around every method definition, which just seemed redundant to me. I know Eclipse will allow this kind of code folding automatically, and I could swear Visual Studio did it also (but it has been long enough that I could just be thinking of Eclipse). At that point, the regions aren't grouping semantically similar concepts, and it ends up being quite a mess visually and organizationally. At least to me... I'm sure the author preferred it that way.

This leads me to conclude that the first part of his article is dead on. Despite my disagreement with the details of regions, I fully agree that a team must be aligned on code style. There is one class I missed in college that in retrospect I truly regret not taking. It was a class that everyone feared as being too hard, but everybody who took it ended up loving the professor. It was some kind of individual software project course, and the class was known for the professor enforcing a standard coding style on the students, with some rules purposefully contrary to common style guides. Thus, the student walks away learning the ability of bending one's will for the good of the team. Style is often a "religious" debate that has no answer. Both sides are valid, because it's just a matter of personal style. The style I consider beautiful is ugly to the next person, and likewise his or her style is ghastly to me.

The style I appreciate most of all though, is consistent style. If that means bending my style a little sometimes, then so be it.