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.


function foo(){

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
    Commented Jan 25, 2017 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. Commented Jan 25, 2017 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
    Commented Jan 25, 2017 at 13:03

2 Answers 2


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.


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. :) Commented Jan 25, 2017 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
    Commented Jan 25, 2017 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. Commented Jan 25, 2017 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
    Commented Jan 26, 2017 at 12:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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