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

Subject: Re: [boost] New libraries implementing C++11 features in C++03
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-11-24 10:05:58

On Fri, Nov 25, 2011 at 1:36 AM, Gregory Crosswhite
<gcrosswhite_at_[hidden]> wrote:
>
> 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.
>

What are you talking about?

There's *exactly* the same number of lines in a local function as
there is with a class/namespace function. What am I missing?

> 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. Â :-)
>

Sorry, but this sounds like you're not using C++ -- it sounds like
you're using a different programming language that encourages this
kind of programming, i.e. scripting or (worse) spaghetti code. A
reasonably modern C++ approach is to define algorithms and data
structures of your solution and use the control flow and concurrency
mechanisms afforded by well-written libraries to achieve any sort of
useful work. In the course of writing these programs typically you
find concepts that arise that encourage generic programming, and
dynamic structures that lend itself to good object oriented
programming. You will also find that C++ already has a lot of
pre-defined algorithms in the STL and in libraries like Boost where
you mix and match and compose and eventually you have a solution from
common /generic/ building blocks.

C++ programmers have been programming without local functions since
the beginning of C++, I don't see why (especially now) that we
suddenly need local functions and (worse) implement it using macros.

I think I'm still missing not entirely obvious to me here.

Cheers

-- 
Dean Michael Berris
http://goo.gl/CKCJX