Is it smart to program the algorithm without function calls?

I am programming an algorithm for a library and I have not used function calls at all. The algorithm is about 100 lines long and there is no duplicate code. Or should I use inlining?

+2


source to share


11 replies


Is your algorithm readable? Perhaps splitting it up into multiple functions would be beneficial for readability (and therefore maintainability), even if it doesn't reduce duplication.



+11


source


These are thoroughly two questions:

  • Too many lines for one function / method, should it be split into sub-functions?
  • Should you think about inlining?


The answer to 1. is: it depends. In general, many people like the function that is suitable for one screen, so it can be read immediately. So 100 lines is the limit. See Best Practice Class String Table for a discussion of class / method sizes.

Answer to 2: Don't optimize prematurely. Profile first, then optimize as needed. Too many similar questions on SO to link to ...

+6


source


Most of the time, if my algorithms grow more than 20 lines, I am using the wrong abstraction level. The next fix will add 10 more lines, the next function will increase the function with 40 lines.

It is better to then move the blocks of functionality into smaller functions named after what they do. Better for me as it allows me to separate a concern, for example. sequence of macroscopic actions from microscopic actions. And better for maintenance, as you can gain insight into the global structure of the code and zoom in on the interest.

+5


source


The question you have to ask yourself is to decide whether the 100 lines algorithm is accurate as it is or not:

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 including 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 K. Martin is a book you might want to study if you find yourself asking yourself these questions repeatedly.

+2


source


Your question is very vague and the best I can suggest is How often should you refactor? and How and how often do you refactor your code? ...

+1


source


This might be reasonable. But this is usually not the case. If you have deeply nested loops and ifs variables are used throughout the method, then the flow is much more difficult to understand. I would say that if you have 100 lines in a method, you don't think about this algorithm. Just an example: if (x> y) z = x; more z = y; of course much better expressed with z = max (x, y); These are patterns in the algorithm that, when discovered and retrieved, will force your method to express the intent of the algorithm, not the 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 the WHAT you are going to output.

+1


source


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

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

0


source


Functions are used to reuse code in the first place. Unless you have any kind of repetitive code, there is no need to use functions in terms of performance.

However, you can consider this for the sake of readability.

0


source


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

My answer: "Yes, it makes perfect sense to write such an algorithm if you think this is the best way to do it."

0


source


I don't see any code that's hard to tell.

A guide that might be helpful is to look at your code and see if there are any obvious steps in the algorithm, especially if they have comments on them before them. If there is, I find it usually more readable to exclude header comments and split into well-named functions. The only caveat is that you should not pass many arguments (possibly no more than 3) to a function, as this will ruin any readability.

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

0


source


In general, you won't save a lot by not parsing your code into functions, since you don't do low-level code more times than you would otherwise. The cost of input and output functions is what it is and usually doesn't matter unless you are doing 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 name that they make it easy to loop more than necessary, especially if they occur at multiple levels of abstraction.

0


source







All Articles