Question

Possible Duplicate:
How many lines of code should a function/procedure/method have?

Out team has a project of not well structured ansi-c code. I would like to use some CC techniques to tidy up the code base.

As for C code, we have a lot of pointers and a lot of NULL-pointer pitfalls to catch. Therefore there are lot of fragments which look alike. It’s like

if (pointer == NULL)
{
  function1();
  function2();
}

all over the place. Then there are an awful lot of functions that will be called after each other in the same fashion only with a few variations, like

function1();
function2a();
function3();

and

function1();
function2b();
function3();

all over the place.

I would like to extract those blocks as a single function to reduce LOC and copy-pasting. But that will create not only a (somewhat) orthogonal layer but also a handfull of function doing more or less the same, except for some details. And even worse, it will create functions that do a lot of things at once.

So, what’s a good strategy? What’s more important, lean code on high level, lean functions on low level or lean architecture? Which principle trumps the other? Seperation of concern or DRY?

I would like to refactor that beast but don’t know where to start.

To exploid the example below and put same names in. Lets assume we have

morningBath();
drinkCoffee();
if (checkMail())
{
  answerMail();
}

and put that into morningRoutine(). Now we have

drinkTea();
morningBath();
if (checkMail())
{
  answerMail();
}

and call it sundayMorningRoutine(). But then there is duplicated code. Or expand morningRoutine(day) as

if (day == sunday){
  drinkTea();
  morningBath();
} else {
  morningBath();
  drinkCoffee();
}    
if (checkMail())
{
  answerMail();
}

or maybe

if (day == sunday){
  drink(Tea);
  morningBath();
} else {
  morningBath();
  drink(Coffee);
}    
if (checkMail())
{
  answerMail();
}

I wonder if that is good style.. maybe.. Thanks for that hint!

Answer 1

Regarding C code, it’s perfectly normal to frequently encounter NULL pointer checks, especially when it comes to function arguments. Personally, I prefer to let the caller resolve the situation, as in:

if (p == NULL) {
    /* maybe do some cleanup and then: */
    return errcode;
}

Public functions, i.e. functions that are part of the API, should always check for NULL pointers. Functions that are designated static may IMO drop those checks. And finally, there’s always assert(). Those checks can be suppressed by the compiler flag -NDEBUG. I use assert() in static functions instead of if-statements and in “public” functions for tests that reveal that the caller didn’t actually understand the API as a whole, e.g. in a linked list lib:

void list_print(list **l)
{
    assert(l != NULL);    /* no valid list passed by reference can ever be NULL */

    if (*l == NULL)       /* but it can be empty */
        return;

    /* print list */
}

As for your second concern, I can see three options:

1) leave everything as it is – after all, it’s working.

2) introduce new functions:

int function_1_2a_3();
int function_1_2b_3();

3) introduce new parametrized functions:

int function_1_2_3(int type);

Personally, I prefer the latter approach, but that is really just a matter of style.