tags:

views:

273

answers:

9

I'm working with some C code that does not contain function prototypes for a certain class of functions. Are there any advantages to not using function prototypes? The functions never call each other and have no parameters. The code changes a lot, so maybe it's just one less line to edit?

A: 

the only benefit I see is that you don't have to update the function prototypes each time you change the functions themselves.

cd1
That's only laziness.
akappa
+1  A: 

"so maybe it's just one less line to edit?"

That's the only possible "benefit" in this case, plain laziness.

tekBlues
+1  A: 

Less code to change is the only 'advantage' I can think of. Typically this is just 'lazy'

In any event, the disadvantages are more significant: you've gotta have the functions all in one source file; order of functions in the source file now matters, etc. Also, other people will be confused looking at/for the header file...best practice is to .c and .h it.

DarkSquid
+4  A: 

No.

And I don't know if it is even legal in strict ansi c.

akappa
A: 

The code changes a lot, so maybe it's just one less line to edit?

I'd guess that's the reason. I can't think of any other reason - neither does the compilation speed change (practically), nor the execution time, merely the time for updating the code.

soulmerge
+3  A: 

Function prototypes are for external functions. My rule is that every non-static function gets a prototype, except main(). I use the '-Wmissing-prototypes' GCC option. Usually what it catches is when I forget to declare a function static.

Also, declare functions in C this way:

void function(void);

And not this way:

void function();

Because the second way means that the function takes an unspecified number of parameters, which isn't what you want (it's for compatibility with pre-ANSI C).

Dietrich Epp
I also use prototypes for static funcitons, at the beginning of the .c file. No reason not to, that way you don't have to worry about the order in which they are implemented.
gnud
I used to use prototypes for static functions, but have since been convinced not to most of the time. If you have a prototype, then you are repeating information in two places. For an interface it's necessary, but why do that with static functions?
Chris Arguin
@Chris: because some compilers will make unsafe assumptions about parameters if there's no prototype in scope.
Steve Melnikoff
+2  A: 

"Code changes a lot" when applied to function prototypes is also a bad code smell. If the interface (function signature) changes a lot, the responsibilities of a function are probabaly not very clear. First work to figure out how to divide the problem to subresponsibilities and only after that start to write code.

laalto
A: 

The only advantage I can think of is that it saves you having to copy and paste the first line of the function into the prototypes section of your .c or .h file.

For functions which are referenced in other files, you have no choice but to have a prototype.

For functions with file scope (i.e. static functions), it's useful to have all the prototypes in a block at the top of the file. That way, any static function can be called by another from anywhere in that file. Without prototypes, function A() can only call function B() if B() is declared above it in the code.

Also, some compilers will make unsafe assumptions about parameters if there's no prototype in scope.

In addition, if you write code which has to conform to MISRA-C, it's a requirement that all functions have a prototype in scope.

I'd also advocate ensuring that the prototype contains the parameter names, not just their types (which is legal), as it clarifies the purpose of the parameters just by looking at the prototype.

Steve Melnikoff
A: 

It's less typing, so maybe that reduces your risk for RSI.

Crashworks