Re: [boost] New libraries implementing C++11 features in C++03

Subject: Re: [boost] New libraries implementing C++11 features in C++03
From: Gregory Crosswhite (gcrosswhite_at_[hidden])
Date: 2011-11-24 09:36:48

On Nov 24, 2011, at 10:57 PM, Dean Michael Berris wrote:

> I think you're missing the forest for the trees here.
> 
> What I'm saying is: If I had a choice between one function that
> contains another function that has N+M lines of code total versus two
> functions where one has N and the other has M lines of code, I'd say
> functions with less code is better -- or mathematically:
> 
>  For any (N,M) where N > 0 and M > 0, N < N+M and M < N+M.
> 
> If we agree that having functions that have less lines of code is
> better than a function that has more lines of code for readability and
> maintainability, then there's no logical reason to prefer one function
> having more lines of code _when it itself contains another function
> that can otherwise stand alone_.

The flaw in your argument is that merely splitting a function in two doesn't automatically decrease the total amount of code that needs to be read;  if anything, it *adds* to the total number of lines of code that have to be read because of the additional declarations that were introduced.

Now, often when a function becomes long what you discover is that many of the parts make sense on their own and in that case it can improve clarity to split them off.  However, when this doesn't come naturally there is no point in forcing it.

There is another perfectly good way to break a long list of lines of codes into more comprehensible part:  by taking each logical step in your function and inserting a few lines of code explaining what is about to happen and why, i.e. "Step 1:  First, we do ...", "Step 2:  Having done Step 1, we have X but now we need Y, so now we do ...".  This both breaks up the long string of codes into smaller parts *and* provides a clear narrative of what is going on, without artificially introducing the additional unnecessary complexity of function barriers between the parts of the code.

Along these lines, my favorite coding tool in the world is Leo:

        http://webpages.charter.net/edreamleo/front.html

What makes Leo interesting is that it lets you structure *all* of your codebase as a tree with --- and this is the key point that makes it special among editors --- *arbitrary* granularity.  So my personal solution for functions that are getting too long but for which it doesn't make sense to split the parts into separate functions is to structure the function as a tree with the parts being placed in named subnodes, ideally with a running commentary at the beginning of each subnode.

Anyway, so in short I agree that it can often be useful to break large functions up into smaller functions, but I think that there is no point in being dogmatic about this.  Break functions into smaller functions when it makes sense to do so, and when it doesn't just use comments to break up the code --- heck, if anything I figure that readers of your code are *more* likely to have code be broken up by a series of insightful comments forming a narrative than merely having it be split into smaller functions.  :-)

Cheers,
Greg