is it reasonable to program an algortihm without function calls ?

Question

Hi there ... I am programming a an algorithm for a library and I didn't use function calls at all. The algorithm is about 100 lines and there is no duplicate code.or should I use inlining ?

Answer 1

Is your algorithm readable? Maybe dividing it into several functions would be beneficial for readability (and hence maintainability) even if it will not reduce duplication.

Answer 2

Inlining is a "hint" to the compiler; meaning that the compiler might or might not inline the code.

In your case, the compiler will probably ignore the inlining since it looks like a big function.

Answer 3

Your question is extremely vague and the best I can offer is "How often should you refactor?" and "How and How often do you refactor your code?".

Answer 4

That's acutally two questions:

1. Is 100 lines too long for a single function/method, does it need to be broken up into sub-functions?
2. Is it worth to think about inlining?

The answer to 1. is: it depends. In general, many people like a function to fit on a single screen, so it can be read at a glance. So 100 lines is about the limit. See e.g. http://stackoverflow.com/questions/1086851/good-practice-class-line-count for a discussion about class/method sizes.

The answer to 2. is: Don't optimize prematurely. Profile first, then optimize as needed. There are too many similar questions on SO to link to...

Answer 5

Most of the time, if my algorithms grow over 20 lines, I'm using the wrong level of abstraction. The next bugfix will add 10 lines more, the following feature will grow the function with 40 lines.

It's better to then move blocks of functionality into smaller functions, named after what they do. Better for me, since it allows me to separate the concern of e.g. the sequence of macroscopic actions from the microscopic actions. And better for maintenance, since you can get a view on the global structure of the code, and zoom in on the part of interest.

Answer 6

Functions are used for code re-usability in the first place. If you don't have any repeating code, no need to use functions, as far as performance is considered.

Still you can consider it for the sake of readability.

Answer 7

It may be reasonable. But usually it's not. If you have deep nested loops and ifs, variables used all along the method, then it is much harder to understand the flow. I would say that if you have 100 lines in a method, you didn't think well about the algorithm. Just an example: if (x > y) z = x; else z = y; is of course much better expressed with z = max(x, y); These are patterns in the algorithm that, when found and extracted, will make your method express the intent of the algorithm, rather than implementation details...

print max(x,y)

or

print (x > y ? x : y)

or

print GetPreferredValue(x, y)

where GetPreferredValue() just does max(x,y) but it tells you WHAT you're going to output.

Answer 8

The question you should ask yourself, to decide if the 100 line algorithm is fine as it is or not is:

Is the intent with all parts of my code obvious?

If you have a block of, say, 10 lines or so that does something not obvious, then putting it in a function and giving it a good name is much better than adding a comment or doing nothing at all.

"Clean code" by Robert C. Martin is a book you might want to look into if you find that you're repeatedly asking yourself questions like this.

Answer 9

Well, the bubble-sort algorithm is shorter than 100 lines and doesn't use any function calls, so why should you:)

My answer is that "yes, it's perfectly reasonable to write such an algorithm if you consider that is the best way to do it"

Answer 10

Without seeing the code it's hard to say.

A guide that may be useful is to look at your code and see if there are any obvious stages in the algorithm, especially if they have heading comments before them. If there are, I find it's usually more readable to eliminate the heading comments and split into well named functions. The only caveat is that you shouldn't be passing lots of arguments (probably no more than 3) to the functions as that will destroy any readability benefit.

This assumes the algorithm doesn't have to be as fast as possible, but even then inlining usually does the trick. In general, prefer readability and remember that functions are a very good form of abstraction.

Answer 11

In general, you won't save much by not breaking up the code into functions, as long as in doing so you don't end up doing the low-level code more times than you otherwise would. The cost of entering and exiting functions is what it is, and is usually not significant, unless you do it at such a low level that it actually dominates.

The real cost of function calls is that, like a credit card, they are so easy to call that they make it easy to spend more cycles than necessary, especially if they occur over multiple layers of abstraction.