parallel roads

Several folks have blogged recently about the book beautiful code, some like Jeff have blogged multiple times about it.  The reactions are somewhat mixed and not really surprisingly.  I really would expect beauty, which is decidedly aesthetic to vary from person to person.

I’ll be honest and state that I haven’t read this book yet, but it is on my to read list.  Given that I can’t comment yet on the book, but I can share some traits I find beautiful in code.

Readable, it should be very clear what the code is doing from the names of the objects, their instances and any functions or methods.  This can be done with or without language support, and in a very personal sense, I will tend to avoid language features that make code unreadable.

I also really admire code that is decisive some folks like to call this declarative, but I think it can be more.  I dislike excessive branching mostly because I am very cautious and tend to get worried about testing a method with a lot of branching in it.

I admire stateless functions and objects I tend to find it fascinating when I see code that enables useful scenarios that is built out of stateless objects.  This also tends to lead to rather simple code which is also quite nice, because when I’ve long forgotten what code does if it’s readable and straightforward I can usually pick it back up again soon.

I fully expect your mileage to vary because appreciation of beauty is so personal.  I’ll also chime back in after I’ve read the book.

~Rick

In his blog, Herb Sutter recently posted notes from the latest C++ standards meeting:

For me, easily the biggest news of the meeting was that we voted lambda functions and closures into C++0x. I think this will make STL algorithms an order of magnitude more usable, and it will be a great boon to concurrent code where it’s important to be able to conveniently pass around a piece of code like an object

Introducing lambdas into C++ is extremely exciting.  Their omission has been one of the primary reasons why I’ve been finding myself using C# more and more for the little automation projects I often build to get work done.

Herb elaborates their value, I think he *almost* understates their value

C++ has always supported this via function objects, and lambdas/closures are merely syntactic sugar for writing function object

but it is quite clear from his tone that he is actually hugely excited about their inclusion.  In fact he goes on to provide a few examples, I’ll reiterate because the difference is quite dramatic and worth repeating.

 

Let’s compare using a function object to a lambda

Imagine you have a class widget that provides a weight function:

   class Widget{
   public:
       int Weight(){
           return m_weight;
       };
   };

Say you have a vector of them

   vector<Widget> w;

So far so good, right?  But here’s where it starts to get cumbersome… If now you’d like to find one of these widgets that has a weight greater than 100.  The stl has this great helper function for doing this called find_if and we’d like to use it…

So first we have to create a function object, it has to be declared outside of the scope of the function we’re using:

   class GreaterThan {
       int weight;
   public:
       GreaterThan( int weight_ )
          : weight(weight_) { }
       bool operator()(Widget& w ) {
           return w.Weight() > weight;

       }
   };

Great, now using it isn’t so bad, but unfortunately because the function object got declared out of scope an awful lot of context was lost and the code gets less readable.

   find_if( w.begin(), w.end(), GreaterThan(100) );

The lambda allows us to instead *skip* declaring the function object and just work inline:

   find_if( w.begin(), w.end(),[&]{return w.Weight() > 100;});

From a usability perspective this is a huge win. 

• We all like to write less code, as near as I can tell this removed 8 lines of code.
• We’ve also removed a level of indirection by declaring the lambda inline.

Please don’t underestimate the value of these because they are huge.  Developers are pretty darn good at keeping large numbers of concepts like this lowly function object and extra 8 lines of code in their head, but there really is no reason to do this unnecessarily.

 

And don’t forget about loops!

Using lambdas inside of loops may seem awkward at first, but it’s something that I think will grow on us:

   for_each( v.begin(), v.end(), []( Widget& w ){
       …

       //use or modify w

       …
   });

I can’t wait for C++0x!

-Rick