Jun 21, 2010
PPL: Day 8 – Horizontal formatting
This is part of the Peer Pressure Learning 30 series. Go read my introduction to the experiment Miles and I embarked on.
Monday morning and I’m back on track. It’s barely 8:00am and I have my reading done.
Today’s reading: pg 85 – pg 92
This section on horizontal formatting really challenged some of my thoughts on code. As I said before, I’m a bit of a geek for formatting code a certain way. Uncle Bob (the author) isn’t as infatuated with the little “beauty” details as I sometimes am. I routinely line up assignment operators, hashrockets, or any other element that’s repeated on multiple lines. He points out some reasons not to do that, despite the visual appeal.
An example of my hyperactive horizontal alignment from the filtering Twitter Proxy I wrote:
A couple differences in his coding style that I want to ponder further:
- You probably shouldn’t break indentation – When a block can be done on one line or indented over several, the author explains that he almost always (he of course, used Java) went back to the indented multi-line version. In the example below. the “return true” is the critical element, the thing that actually executes. That shouldn’t be hidden in the middle of the line. Rather, it’s indented and it’s scope is clearly shown. (Note: I did use the more Ruby-ish inline if statement. I felt that to be a reasonable breakage of standard indenting…but maybe it isn’t!)
- Don’t necessarily line up similar elements – I find that I almost always line up like elements in named_scopes, routes, associations, etc. The author makes an interesting point that while you may be making the code more aesthetically pleasing, you can obscure relevant differences. The code becomes too easy to scan, allowing someone to miss critical elements of the code. The example below may be as stretch, but I could see someone missing the difference between the TRUE and FALSE. I guess one must weigh the value of showing how similar the two statements are with making their difference clear.
I’m interested to talk with my team about implementing some basic style guidelines. The text talks about a situation the author was in where they spend just 10 minutes making some decisions that affected the whole project. That tells me that it doesn’t have to be a long, drawn out affair.
What will get interesting for a web app project is that we have to integrate several different languages. I’m already finding that I have to tone down the amount of Ruby-specific stuff as we have to shift from Ruby to JS to HTML and each has its own common idioms. That’s what makes this fun!
Hey, we made it through the weekend! Just three more of those to go. :-/
As to the subject at hand, I will admit that, for some unknown reason, the “lined up” method annoys me as I’m writing code. I think perhaps it’s the extra work that it takes to get it just right. I’ve reached the point where even reading “lined up” code bugs me a bit. Weird, huh? However, sometimes I find myself using the “lined up” method, especially if a fellow programmer used it in the same project. I guess I’m a conformist.
I’m interested in reading more of this chapter, such that I’ll be able to defend my tendency to avoid lining things up!
I had another developer voice the same frustration (time required) about six months ago. Since I’m into that sort of thing generally, I’ve discovered and frequently use the Textmate shortcuts. The RubyAMP Bundle adds a custome alignment command that lets you key in the delimiter to align on, so it can be commas, hashrockets, equals, pipe, etc. It’s pretty great.
I’ll certainly give the whole thing a lot more thought. Whereas before, I’d automatically line up a set of 5-6 assignment statements, I’ll now give thought to whether they’re all logically related and whether I’m obscuring anything.