2

Is there a name that is commonly used for functions that are only called in one other function?

(I'm not asking whether it's a good practice; I believe it can improve readability in some cases.)

Right now I'm commenting them as "local shorthand functions", but I'd like a more standardized name, if available.

Example:

function foo(){
  bar(x)
  bar(y)
  bar(z)
}

function bar(){
  ... // bar definition
}

bar() only being used, one to N times, in another single function foo().

  • 1
    If your language supports nested functions, you would call it an inner function. Otherwise I think "helper function" more or less covers it, but there is no guarantee it is only called from a single function. – JacquesB Jan 25 '17 at 11:08
  • 2
    I assume by "function" you mean either any subroutine (function or procedure), because you use a procedure in your example...? You've tagged this question with "functional programming" but I'm not sure that has anything to do with what you're asking. – Trixie Wolf Jan 25 '17 at 12:15
  • You're right Trixie; the question itself doesn't have much to do with functional programming, but I was implying that these kind of functions are more closely associated with functional programming than with OOP. Ironically I'm working with OOP, and the tag might have been misleading; I removed it now. – JoseHdez_2 Jan 25 '17 at 13:03
3

I would call it one of the following:

  • Helper Function
    • if it was some sort of small detail, like formatting a string correctly
  • The "bulk functionality"
    • if it was the bigger detail, like a search algorithm
  • Inner Function
    • If the definition was inside the other
  • Another function
    • Because that's what it is

I know some people who may say you are "delegating", but that can cause ambiguity due to the word already being used, as in the case of C# delegates. I'd personally stick with helper function.

That being said, this is essentially just an ordinary method, so do you really need to make the distinction? There's absolutely nothing wrong with abstracting out a method for a single use, in fact it's a good idea as you said! Just keep in mind you can't truly guarantee that a function will only ever be called in one place. One day that may not be true, code changes.

6

You're asking the wrong question.

Just as touching the ball only once when passing is the high art of soccer, storing each bit of information exactly once is the basic principle of good data representation... and performing every task only in one place is the high art of maintainable software. This means that writing a method that is called only in one other place should be the normal case.

To be sure, there is a place for methods that are called all over the place. For instance, a string-trimming method has many uses, and it makes sense to define it once and call it often. They're called utility methods.

But that is a special kind of method. The majority of methods should be dedicated one-purpose methods, and they shouldn't have a special name, because they're the normal kind of methods.

  • 2
    I didn't get the soccer reference, but everything else is spot on. :) – Chris Wohlert Jan 25 '17 at 12:02
  • But while in soccer everyone without the ball runs the most, the only part of your program that runs at any given time is the one with the ball. :-P – simbabque Jan 25 '17 at 13:15
  • 1
    I disagree a bit: I want my functions to be callable from more than one place in general. That's the principle of code reuse. If every function is only called just once, it's just chopped spaghetti code. – cmaster Jan 25 '17 at 14:02
  • I'm with cmaster on this one; I think I didn't clarify that I'm writing OOP and not functional programming: the tag I had added to this question was misleading. – JoseHdez_2 Jan 26 '17 at 12:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.