Thread: Reasons for keeping functions small

As long as readibility is not affected then there's no need to split up a function like that. If it gets to be 2000 or so lines then it might make sense.

If you have 350 conditional statements in a function, the data structures and algorthms you're using probably could use some changing.

Originally Posted by cwr

If you have 350 conditional statements in a function, the data structures and algorthms you're using probably could use some changing.

its not 350 conditional statements, just lines, and this is a hypothetical example, to try and see what you would do in extreme cases. I guess the overhead of allocating a function on the stack isnt that big of a factor in overall performance is it?

Usually you should go by "one job per function". And this is really because it makes the function easier to understand what it's doing at a later time, than say, having n+ jobs. Do not worry about speed, though, it's really irrelevant (especially since C is pretty low level).

im doing it in Java, but thought it might be generalizable from C to Java, and languages in general.

It's not the size of a function (in terms of number of lines of code) that increases the overhead of a function call. The more usual overhead is related to number and size of arguments being passed. For example, passing large data structures by value will typically involve more overhead than passing a pointer to those structures.

Compilers can shift the balance a bit through techniques like inlining (eg placing the actual body of a function in place instead of calling it). That involves a trade-off of executable file size and performance. The trade-off isn't always obvious, for example if it is necessary to swap some code out of memory so other code can run.