Jun 15, 2010
PPL: Day 2 – Functions
This is part of the Peer Pressure Learning 30 series. Take a gander at my introduction to the experiment.
Today began with the first portion of Chapter 3: Functions from Clean Code. I stopped just before getting into function arguments.
Today’s reading: pg 31 – pg 40
The first section followed a consistent theme, pounding away at making your functions short, focused, and one-dimensional. My key takeaways were:
- Keep ‘em REALLY short – This usually isn’t much of a problem for me, right up until it is. At times, I get lazy (usually when not doing TDD) and let a function get out of hand. It’s crazy, as a longer function is a pain in the ass to test, and confuses the hell out of your future self. While the authors don’t give a hard and fast rule (which would be stupid), it appears that anything over 5-10 lines is likely a code smell.
- Do only one thing – Again, I feel like I generally do well with this, perhaps erring on the side of creating too many functions. I’m consistently challenged for creating too many rabbit-holes to dig through. I need to really keep any eye on this and put in the rabbit-holes where needed.
- Only one level of abstraction per function – I’m really excited about this one. While I’ve read Clean Code several times, this hasn’t sunk in until now. The idea is not to do string manipulation in the same function that’s doing SQL calls and building an HTML template string. It’s a somewhat nebulous concept for me to explain, but the book did a good job. I think it’s something you’ll recognize when you see it.
Tomorrow, more functions! It goes into argument counts and structure. Woot!
UPDATE: I got a bit too rowdy posting source code from a private project, so I pulled the exercise code. Definitely my bad. I may come back and do another exercise to post from one of my public repositories. More than likely, I’ll forget tomorrow. 
Nice work, sir!
If it were me, my goal would be to remove the comment “# Determine how many columns the table will have” by naming the “total_compare_table_columns” something that makes that intent clear. Would you agree? Does that jive with what you know from Clean Code?
The code is a bit out of context, so it’s hard for me to say what exactly fits in, but would it be confusing to just call the method “number_of_columns” or “number_of_comparison_columns”? It seems to me that using method names that sound like they could be variable names is almost a Ruby idiom, but perhaps I’m exposing my ignorance, and it’s actually a bad practice. What do you think?
Ripping the comment out makes sense. Our projects require a lot of commenting as we want to keep the code base understandable, even for our team members (and future team members) who aren’t super-familiar with Rails or the concepts used.
I’m with you, naming a method the same way you would name a variable makes a TON of sense. That way, it can be either a variable or a method. The person doesn’t need to know unless they need to know. Even if a method is only called from one place, I think it’s always good to pull out 3-5 lines from a larger method, using a good name to clarify the intent of that section of code. While it does make the rabbit hole deeper, it helps explain the concepts and keep the levels of abstraction right.