Does function size matter?

I just finished the 3rd chapter of Clean Code by Robert C. Martin and I feel like my brain has exploded.

I couldn't resist writing a post about what I've read so far, to see what others thought about it. Even though I'm only at the very beginning of this book, I can tell I'm going to like it.

• The first chapter talks about what makes code "clean" (according to the author and a number of developers that are considered industry leaders).
• The second chapter talks about meaningful names, what makes them important, along with some examples. Interesting, but nothing super exciting.
• The third chapter is all about functions. This is where I had a mini freak out in my head.

The author believes functions should:

• use descriptive names
• be small - about 2 or 3 lines each
• do one thing and do it well
• only have 1 or 2 arguments passed to them, preferably none
• have one level of abstraction

This ends up resulting in a LOT of functions. The author argues that if you do this, your code becomes very easy to understand and reads from top to bottom, like a story.

I've never given much thought to the size of my functions before, but 2 or 3 lines seems exceedingly small. I tend to write functions that are 6 - 10 lines.

I've never given ANY thought to the levels of abstraction in my code, in fact, I didn't even know what that was before I read about it. In case anybody else has never heard of this term, the idea behind it is that everything in the function should be at the same level of granularity. Here is a nice definition from Wikipedia and a post on stackoverflow with a good example.

The author argues that it can be confusing if you don't follow this principle because you aren't able to tell whether an expression is an important concept or a detail. Mixing the two in a function is just as bad as falling to be weary of the broken window theory.

If having code that is easy to read and maintain isn't compelling enough for you, and you are programming against the .Net framework, you might be interested to know that Jeffrey Richter, in CLR via C#, points out that code converted to IL is evaluated on a method by method basis. This means that a method isn't evaluated until it is actually needed - this makes your code run faster. Additionally the CLR optimizes the code by "enregistering " variables in the method, but only if it is small enough. Unfortunately Jeffrey doesn't specify what a "small" method actually is.

Are comments always necessary?

I was reminded of a conversation Marshall and I had about comments when I read this post by Jesse Liberty.

The post gives an example of the reason your comments should explain why you're doing something, rather than how you're doing it.

At the end, Jesse argues that if your reader knows the language, your comments will be reduntant if you use descritptive names for methods and variables.

Lately I've been thingking a lot about how much I should be commenting. And whether or not I'm just stating the obvious.

Take this method for example.

public string GetRunTimeForAllCars()
{
  IEnumerable<Car> listOfCars = listOfVehicles.FindAll(c => c is Car).Cast<Car>();
  double totalRunTime = listOfCars.Select(t => t.RunTime).Sum();
  return totalRunTime.ToString("f2");
}


I experimented with a few ways or writing the method out before I decided on this one.
I think it's pretty clear and doesn't need any comments to tell you what's going on.

What do you guys think?
Are comments always neccessary?
If somebody doesn't know linq, can they still understand what that code is doing?

Being a better developer

Scott Hanselman lists some things to "sharpen the saw" on his website.

I listened to the podcast he links on his page, he mentions several things I found interesting.

Reading books is a great way to learn, but Scott warns about becoming "too academic". A great way to improve your own code is to read other's code. Of course, you want to make sure the code you're reading is "good code". One way to do this is to read code from successful open source projects.

Scott mentions several by name:
CastleProject, Microsoft's Patterns & Practices, SubText and he puts in a plug for dasBlog as well.

Other things he talks about doing are:
Talking with other developers about how they do things.
Teaching a class on a topic and joining a developer's users group.

I'm guilty of being too academic. I do a lot of reading, mostly books.
Since March I've read: Programming Entity Frameworks, Refactoring to Patterns, Pragmatic Testing in C# with nUnit, C# in depth, and I'm halfway through CLR via C#. These are on my list for the next 6 - 12 months: The Pragmatic Programmer, Clean Code and Code Complete 2, they've arrived at my house and I'm really excited to read them!

I also listen to podcasts, mostly Scott Hanselman's, and I read blogs from the same, as well as, Scott Guthrie, Jeffrey Palermo, Eric Lippert, Julie Lerman and John Papa.

I've watched quite a few videos on SilverlightTV and Channel9.
There are some really great videos on that site.

I really like watching the videos and downloading the code from the show, it's really great to be able to go through the code to see how they've done what they're talking about on the show.
That makes me think that checking out code from some of those open source projects is going to be really good for me.

Scott briefly mentions that learning a new language to get out of your comfort zone is a good idea.
I've heard this idea on other podcasts and read about it as well. The idea being that if you're a Windows guy working in .Net you should try running Linux and play around with Python, Perl, Ruby on Rails, etc. To that end, I set up my home computer to dual boot Windows and Ubuntu. I installed MonoDevelop and eventually plan on learning IronPython (since it works with .Net in Visual Studio) and F#. I'm also considering eventually taking a look at Ruby on Rails, Lisp and Smalltalk.

I'm going to start by downloading and reading code from one of those projects, it sounds like that's where it's at.

What do you guys think?

Good Taste

In episode #222 "Art is Shipping", Scott Hanselman interviews Jin Yang, the lead designer for StackOverflow.
In this podcast Jin Yang mentions a couple things that I found really interesting:
The first was that a well designed site should evoke a feeling from it's users.
I had never considered this, but it makes a lot of sense. Imagine you have a site where you want your users to donate money for some worthy cause, you might design the site to evoke a feeling of compassion so that your visitors will be inclined to donate more.
The second was that good taste can be developed.
This got me to thinking "what is good taste?".  According to Immanuel Kant, it comes down to a judgement based on a subjective feeling. Well, if that's the case, how do you get better at it?

Scott links a number of design blogs in the notes for the show, perhaps the anwer is to check out the blogs, see what others are doing, and take from that the things that appeal to you.
I've found that I'm a big fan of minimalist art, a style that Apple has been really good at.

What do you guys think? What is good taste and how do you recognize it?

A friend at work is always saying how important it is to unit test. His main argument is that unit testing makes refactoring easier. This is something I've heard before but never really thought about. I have refactored lots of code and written lots of unit tests, but I've never really thought deeply about their relationship with each other. Today I decided it was time to consider this issue. So I did some Googleing. I found the following link which is a short blog post where someone discusses the relationship. This solidified my understanding. So, if you want to start thinking about the link between unit testing and refactoring have a look:

Refactoring and Unit Tests @ artima.com

-Marshall