Fog Creek Software
Discussion Board




Comments on function call style/religion in C/C++?

Yeah, I know I'm asking for trouble... but how do you folks like long function calls to be wrapped/broken up in C and C++?

In Perl, I've always done:

    $user_level = calc_user_level(
        $user_id, $days_regestered, $total_posts
    );

Or, if the function takes one "special" argument then a series of two or more non-"special" arguments, I've broken it up like this:

    $page .= sprintf("%s has been a user since: %s.\n",
        $username,
        make_timestamp($days_regestered),
    );

Or, if there are no "special" arguments, just a lot of normal arguments that can't fit on one line, then like this:

    $user->update_personal_info(
        $name,
        $age,
        $city,
        $bio,
        $aim,
        $email_address
    );

The problem is that first style kind of breaks down in C if you have a cast in front of the function call:

        current_element = (RDP_Element *) malloc(
            sizeof(RDP_Element *)
        );

The argument is far, far away from the name of the function.

I'm told the standard way of breaking up long function calls is like this:

ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR,
    r, "chunked Transfer-Encoding forbidden: %s", r->uri);

But to me, that looks kinda messy. I've read some style guides, and most either say nothing about this or offer simple, specious solutions that break down into cruft quickly in the real world.

Any feedback, especially suggestions, would be greatly appreciated.

Big Jim Tucker
Monday, April 12, 2004

"sizeof(RDP_Element *)" should be "sizeof(RDP_Element)", sorry.

Big Jim Tucker.
Monday, April 12, 2004

I typically use the "standard" way you mention, and minimize the number of lines. I found that this makes the code clearer, since more compact code is more easily understood at a glance. I used to break it up where each argument was on a separate line for long function calls, but the resulting code was too long and hard to read. (I do Win32 programming, so I had this stuff all over the code.)

I tend to navigate the code looking for bigger picture stuff than function call arguments, which is why I also document my code extensively. Sure, code should be self-explanatory if possible, but I don't want to read the actual code when I'm looking through a lot of it to find a specific location.

sid6581
Monday, April 12, 2004

Sometimes the third one is useful if some parameters need comments on their context.

Tony Chang
Monday, April 12, 2004

I do things like:
foo( bar
    , baz
    , qzxx
    , monkey );

MR
Monday, April 12, 2004

I don't break my long lines.  If a line is long, that is tough.  Fortunately the name of the function/method prefixes the line, so it is easy to follow.

And when I print text such as sourcecode, I expect my IDE to intelligently wrap it for me!  Most do.

i like i
Tuesday, April 13, 2004

I tend to agree that allowing the editor to soft wrap lines seems like the most reasonable solution in this day and age. We're not stuck on 80 character terminals anymore (in the most part), so how can you really know where a good spot to wrap is for a particular reader's font/resolution/window size?

Sum Dum Gai
Tuesday, April 13, 2004

The Linux Kernel's take on this is actually fairly simple:

Limit every line to 80 characters.

If you can't make a function call readable because of indenting, examine your nesting or your function, it's probably too complex.

The philosophy on breaking up a specific call isn't well defined, but the first rule tends to imply that if you need to break into more than 2 lines something else is probably wrong.

Also, a style like

f(x
      , y
      , z
  );

Would be rejected as ridiculous (even if x, y and z were much longer.  The comma placement would be the problem.)

The specific example from the kernel's CodingStyle document:

void fun(int a, int b, int c)
{
        if (condition)
                printk(KERN_WARNING "Warning this is a long printk with "
                                                "3 parameters a: %u b: %u "
                                                "c: %u \n", a, b, c);
        else
                next_statement;
}

(In general, anytime I have a question of style I tend to go with the Kernel's ideas, because at least they have a written justification for why they do things)

Ryan Anderson
Wednesday, April 14, 2004

*  Recent Topics

*  Fog Creek Home