C Coding Styles and the use of Macros

[davej]

Hi,

I've been working on an opensource project for most of this year. The
group has adopted the use of macros in place of function calls when
wanting to simplify a function.
#define get_sensor_values(s1, s2, s3) \
do { \
if(s1>s2) { \
if(s->e != NULL { \
id = s3->id; \ OID defined\n"); \
} \
} \
..... this continues for many lines

if(error)\
return(-1);
} while(0)




int process_sensor_data(n, p, s1, s2, s3)
{
..
..
get_sensor_values(s1, s2, s3);
..
..
return(OK);
}


I consider this obfuscation. For starters the macro hides one of the
return paths from the function. Second the use of macros has become
pervasive in replacing function calls.

I'd like to hear opinions on this. Are there any web references I
can use?

Thanks Much

DaveJ

 

[Mike Wahler]

Hi,

I've been working on an opensource project for most of this year. The
group has adopted the use of macros in place of function calls when
wanting to simplify a function.
#define get_sensor_values(s1, s2, s3) \
do { \
if(s1>s2) { \
if(s->e != NULL { \
id = s3->id; \ OID defined\n"); \
} \
} \
.... this continues for many lines

if(error)\
return(-1);
} while(0)




int process_sensor_data(n, p, s1, s2, s3)
{
.
.
get_sensor_values(s1, s2, s3);
.
.
return(OK);
}


I consider this obfuscation. For starters the macro hides one of the
return paths from the function. Second the use of macros has become
pervasive in replacing function calls.

I'd like to hear opinions on this.

I prefer to default to functions, where type checking
can be done. I'd only use a macro if there were compelling
reasons (e.g. performance, which I'd first prove by profiling).

-Mike

 

[Ed Morton]

Hi,

I've been working on an opensource project for most of this year. The
group has adopted the use of macros in place of function calls when
wanting to simplify a function.
#define get_sensor_values(s1, s2, s3) \
do { \
if(s1>s2) { \

See below for macro argument feedback "a)".

if(s->e != NULL { \
id = s3->id;

See below for local variable feedback "b)". I'm assuming id is declared
within the macro and you just didn't show it - if not, that's even worse!

I consider this obfuscation. For starters the macro hides one of the
return paths from the function. Second the use of macros has become
pervasive in replacing function calls.

I'd like to hear opinions on this. Are there any web references I
can use?

Macros are fine for small, simple, often-repeated, run-to-completion
code segments. They shouldn't be longer than half a dozen or so lines
and they should never contain a return statment or otherwise directly
affect control flow of the calling function. Your group is creating a
maintenance headache with hard-to-understand and hard-to-debug code.

By the way:

a) Within a macro you should surround its arguments in "(...)" to avoid
unexpected expansions.
b) Make sure that any variables declared within a macro follow a strict
naming convention (e.g. start them with an underscore) to avoid clashes
with variables in calling functions.

Ed.

 

[Erik de Castro Lopo]

Hi,

I've been working on an opensource project for most of this year. The
group has adopted the use of macros in place of function calls when
wanting to simplify a function.
#define get_sensor_values(s1, s2, s3) \

If its an open source project there is a good chance the compiler
being used is GCC which does support inline functions.

Inline functions have the advantage of much better type checking
than macros.

Erik

--
+-----------------------------------------------------------+
Erik de Castro Lopo (e-mail address removed) (Yes it's valid)
+-----------------------------------------------------------+
"What lawyers call 'intellectual property' is -- as every Latin student
knows -- no more than theft from the public domain."
-- Andy Mueller-Maguhn, newly elected ICANN board member for Europe.

 

[Christian Bau]

Hi,

I've been working on an opensource project for most of this year. The
group has adopted the use of macros in place of function calls when
wanting to simplify a function.
#define get_sensor_values(s1, s2, s3) \
do { \
if(s1>s2) { \
if(s->e != NULL { \
id = s3->id; \ OID defined\n"); \
} \
} \
.... this continues for many lines

if(error)\
return(-1);
} while(0)




int process_sensor_data(n, p, s1, s2, s3)
{
.
.
get_sensor_values(s1, s2, s3);
.
.
return(OK);
}


I consider this obfuscation. For starters the macro hides one of the
return paths from the function. Second the use of macros has become
pervasive in replacing function calls.

I don't mind using function-like macros in a way similar to functions.
Of course, a "return" statement inside a function-like macro means it
does NOT behave similar to a function, so this should better be very
well documented both where the macro is defined and wherever it is used.

 

[CBFalconer]

I've been working on an opensource project for most of this year.
The group has adopted the use of macros in place of function calls
when wanting to simplify a function.
#define get_sensor_values(s1, s2, s3) \
do { \
if(s1>s2) { \
if(s->e != NULL { \
id = s3->id; \ OID defined\n"); \
} \
} \
.... this continues for many lines

if(error)\
return(-1);
} while(0)

int process_sensor_data(n, p, s1, s2, s3)
{
.
.
get_sensor_values(s1, s2, s3);
.
.
return(OK);
}

I consider this obfuscation. For starters the macro hides one
of the return paths from the function. Second the use of macros
has become pervasive in replacing function calls.

I'd like to hear opinions on this. Are there any web references
I can use?

I agree with you. Disassociate yourself from that bunch as
rapidly as possible.