Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

When you have a function that wraps another one in Scala. What do you call the nested function?

I found this :

def factorial(i: Int): Int = {

  def fact(i: Int, accumulator: Int): Int = {
     if (i <= 1)
        fact(i - 1, i * accumulator)

  fact(i, 1)


I usually use just do because it is shorter, generic, and explicit. But is there a better way or a naming convention for nested functions?

def myFunction() = {

  def do(i: Int) = {

share|improve this question
What I'll sometimes do is have the nested function called the same as the outer function with "Inner" added. I'll only ever do that though if Inner is called recursively, otherwise it's simply called something appropriate to what it does. –  Neil Sep 10 '13 at 16:32

3 Answers 3

up vote 0 down vote accepted

There is no need for a convention. Local functions are not exposed to the rest of the code, so nothing anybody else writes will care about it. I say choose something that makes sense in context, rather than worry about a convention which may work well in one place, not in another.

Here is a tail-recursive fibonacci implementation:

def fib (n: Long): Long = {
  def loop(current: Long, next: => Long, iteration: Long): Long = {
    if (n == iteration) 
      loop(next, current + next, iteration + 1)
  loop(0, 1, 0)

I could have called it fibloop, but I don't really think that adds anything. It's not accessible anywhere else, so why bother "namespacing" it? Perhaps calling it forwardloop might be clearer, but not fibloop. If anything, calling it loop emphasises that it is local.

If your methods/functions are so long that you've forgotten where a helper/local function was defined by the time you see it again, I could see the need for a naming convention (although if the function is named so as to make its purpose clear, how often will it matter?). Personally, I try to avoid writing anything that verbose, but if you do, then I suggest you save special conventions for those methods where this actually becomes a problem. Even then, I bet a well chosen name will be more helpful than any number of underscores.

If a method is succinct enough, (and the local function also simple) I confess I sometimes use a function literal just to avoid having to worry about the name.

Now, you might counter that prefixing local functions with an underscore definitively avoids the possibility of shadowing an external function. To which I would respond by asking what happens if you have a local function inside another local function? Use two underscores? If you re-organise your code, how much search-and-replace are you prepared to do, to chase after this problem you created for yourself?

share|improve this answer

Whatever you call it, it should clearly describe its purpose, otherwise you or somebody else will have to go through the function trying to understand what it does. I don't think that 'do' is a reasonable name for any function.

share|improve this answer
I agree but the fact is that it is way more concise than myFunctionImplementation and more generic than _myImplementation. Should I prefer readability over conciseness and genericity ? –  user34903 Sep 10 '13 at 15:08
The purpose is pretty obvious by the fact that it is nested. This is a common pattern: a small wrapper function which just kicks off the tail-recursive worker function. It's similar to new: you know that new constructs a new Car, even though it isn't called newCar simply by virtue of the fact that it is nested inside the Car class. –  Jörg W Mittag Sep 10 '13 at 16:10

A convention I've seen in some other languages is to use a leading or trailing underscore for a private, temporary named function that exists purely as an implementation detail:

def factorial(i : Int): Int = {
  def _factorial(i : Int, acc : Int): Int = {

I don't believe there's an official standard in this case. Just calling it fact or factorialImplementation or something should be fine.

Speaking of factorial, I assume this is being done for the sake of learning right? Because there are a number of shorter and potentially easier-to-maintain ways to get the same results. I like the implementation that uses reduceLeft (or foldl1 if you come from Haskell-land):

share|improve this answer
The inner factorial method using an accumulator is a tail recursive form that is likely just as performat as the reduce. –  MichaelT Sep 10 '13 at 14:26
@MichaelT Fair enough. Maybe I shouldn't have said performance wise. The fold is cheaper to read, though (at least in my opinion) :p –  KChaloux Sep 10 '13 at 14:28

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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