When you are defining a function/variable/etc and are not sure what to name it, what do you name it? How do you come up with a name?

If you use a temporary name as a place-card until you give it it's real name, what temporary name do you use?


I have been using things like WILL_NAME_LATER, NEEDS_NAME, or TO_BE_NAMED. I was hoping there was an adopted convention, I was actually hoping that if I used this adopted convention my IDE would highlight the name until I changed it.

  • Be careful about using all caps for variable names. By popular convention, it means a global variable.
    – spong
    Commented Sep 30, 2010 at 20:34
  • @sunpech, I know, I use that naming convention for constants too. But I think the capitalization makes it stand out so I don't forget to rename it. I don't leave it named like that for long.
    – JD Isaacks
    Commented Sep 30, 2010 at 20:41
  • 3
    For all you people who are saying, you should never have a problem coming up with a name... Even Jon Skeet sometimes can't: stackoverflow.com/questions/521893/…
    – JD Isaacks
    Commented Oct 1, 2010 at 14:25
  • @JohnIsaacks I think you should bold temporary. Too many people are reading this question and making code into something holy. Honestly, yes, you can write sloppy code ESPECIALLY when you're trying to push through to something more important. We're not etching code into stone here.
    – spong
    Commented Oct 1, 2010 at 14:49
  • 1
    I guess the convention for something like this would be to add a TODO in the code, with the explanation of why you need to update it. Many tools can parse those TODOs and show a list of all things left to be done. Commented Oct 1, 2010 at 15:00

18 Answers 18


It's nearly impossible to not be able to think of a name for an artifact you want to design. You may not like what name you come up with because it isn't concise or sexy, but if you think too hard, you'll end up with a poorly named artifact.

Let's say you have something that helps you construct objects, but you don't know this is typically called a factory. Just call it ObjectCreator. It sounds obtuse, but at least it's clear.

Let's say you have a dictionary that converts hostnames to IP addresses. Just go ahead and call it HostnamesToIpAddresses. Sure it's long, but it says exactly what it does.

The inability to come up with a name for something means you don't know what it is doing, which also means you have a greater problem before you.

  • 8
    I always want to slap people who complain about identifiers being too long (when they're only three or four words). We should not be limited by our typing speed, and if we are, we should go look at ABCD and learn to type! Commented Sep 30, 2010 at 21:20
  • 1
    +1 because of "The inability to come up with a name for something means you don't know what it is doing". I think this really is an important point. Realizing this helps you find ambiguities and unclarity in code.
    – BiAiB
    Commented Jan 15, 2013 at 17:53

I always try to give my variables and functions great names.

If I can't think of a great name, I'll settle for a good name.

If I can't come up with a good name, I'll use an okay name.

I have never, in 15 years of professional programming, been unable to come up with a decent name.

  • 6
    +1 for being, like, poetic.
    – spong
    Commented Sep 30, 2010 at 20:44
  • 1
    ...however, 15 years and 6 months ago, Microsoft Bob was born. Commented Oct 1, 2010 at 2:20

If you can't think of a good name on a variable or function, you either don't understand what you're doing or you got a poor design. Either way, slapping some arbitrary name like "x" (unless you're dealing with coordinates) won't solve your dilemma; it will only make it worse and the pain to maintain greater.

  • 8
    I disagree. Developers won't always have a full understanding of the business's terminology. Heck, even the client may not be able to convey the terminology during requirements gathering-- let alone at times even understand their own business! But this doesn't stop software from being produced. It doesn't stop prototypes from being created. Or even code being out right thrown out because of a lack of understanding. But code in these situations still need to be produced and delivered.
    – spong
    Commented Sep 30, 2010 at 20:58
  • 3
    @sunpech Excuse me, but this is a little scary. Are you trying to tell us that it's common to write random code not knowing what it actually does? If you don't know something, put some effort to find out and you'll avoid problems in the future. Commented Sep 30, 2010 at 22:28
  • @AdamByrtek No, I don't mean that. What I'm saying is that it's not always up to the developer and team to have the best understanding of what a client wants. Some clients have a hard time explaining what it is they want, or don't know what it is they want. Bad code does happen. Problems happen in projects from bad requirements to unrealistic deadlines. That's reality. There is no perfect world where a developer will have all unknowns resolved, where clients are perfect, and deadlines are accurate. Code generated for prototypes are meant to be thrown out. But coding still needs to happen.
    – spong
    Commented Sep 30, 2010 at 22:52
  • continued... We're not talking about making production code or the final code just before a check-in. We're talking about how to name something that we don't have the fullest understanding of just yet-- to get started initially on something that is unclear for possibly a good reason (example: nobody on the team understands it yet, maybe not even the client). But things need to move forward still based on what is known.
    – spong
    Commented Sep 30, 2010 at 23:00
  • 1
    @sunpech: The only place I've actually seen foo and bar be used in code is in small snippets of code used to show a concept. Sure, I stumble too when think up names, but I have never ended up in such bad position where foo has been the only reasonable option. If that were to happen, then I really don't know what the hell I'm doing and need to go back to the drawing board and pseudo-code instead till I know what to do.
    – gablin
    Commented Oct 2, 2010 at 18:41

This question and especially its answers scare me senseless. Somebody's going to have to maintain that code in which you just named a variable "Cup", you know. If you're not lucky, that somebody will be you!

You've got a variable. It's a thing. It represents a thing, anyway. And things have names. That's how you know they're things! Are you really telling me you have to name a thing after another thing because you can't come up with the name of the actual thing?

Iterators should be called i. Nested iterators are likely a mistake, but if you need them, then make your way through the rest of the vowels, in order (a, e, o, u, and god help me, yes, sometimes y).

Apart from that, just call the thing what it is and be done with it!

  • 9
    I must protest! Clearly the inner iterator should be called j and the one inside that k. Long-standing mathematical tradition is looking over your shoulder! Commented Oct 1, 2010 at 6:26
  • Huh. I've never done j and k. I see that it's sensible, though.
    – Dan Ray
    Commented Oct 1, 2010 at 11:56
  • 8
    One reason Dijkstra was such a natural fit for computer science was that his name included the three commonest iterator variables in the right order.
    – glenatron
    Commented Oct 1, 2010 at 12:57
  • 3
    @glenatron: Finally, a way to remember how to spell that name! Commented Oct 2, 2010 at 0:07

If I can't come up with a great name right away, I use an "okay" name temporarily, then keep coding. At least it'll be something that adequately describes the item, even it's not perfect. Almost always, by the time I'm done writing the first draft of that particular chunk of code, a more perfect name will have occurred to me. Through the process of coding, my intentions with that particular variable become more clear. (On the other hand, sometimes it occurs to me that the variable to was ill-conceived to begin with and I delete it in favor of something else.)


I name it what I think the function should do -- something that more or less conveys the intent. Once the body of the function is written, I find it obvious what to call it and go back and rename it if needed.

  • 1
    This doesn't always work, especially when the developer may not be familiar with the terminology or even intent of the business/industry. Something more generic and obvious should be used to convey that it needs to be defined and changed later on. The OP seems to be asking when the intent is unknown, and what should initially be used. If the naming is something that more or less conveys intent, then a good name is already not far off.
    – spong
    Commented Sep 30, 2010 at 20:30
  • 1
    @sunpech Seriously, even when first starting out in a job with a fairly specific domain, I haven't had trouble coming up with a function name. Maybe I just need to write more functions. :)
    – Adam Lear
    Commented Sep 30, 2010 at 20:50
  • 1
    @sunpech: How can you write a function without knowing what it does? Commented Sep 30, 2010 at 22:51
  • 4
    @sunpech: I didn't say that. I just said you can't possibly write a function without knowing what it's doing. It's not possible. I've never seen it happen, and I don't see how it could possibly happen. Maybe I'm being daft, but when you name a function DoFoo(), what in the hell do you put inside it?? Commented Oct 1, 2010 at 1:19
  • 2
    @sunpech: I never said names have to be 'good' from the start. I just fail to see how you would come into a situation where you want to create a function but you don't know what it's going to do. Commented Oct 2, 2010 at 0:06

foo and bar. Since there's no meaning behind naming functions/variables just yet, I use some combination of Foo and/or Bar with whatever I'm trying to define.

It makes it easy to search/find later on when I do have a better understanding of what it should be named.

Also see Foobar on wikipedia.

The terms foobar, foo, bar, and baz are sometimes used as placeholder names (also referred to as metasyntactic variables) in computer programming or computer-related documentation. They have been used to name entities such as variables, functions, and commands whose purpose is unimportant and serve only to demonstrate a concept. The words themselves have no meaning in this usage. Foobar is sometimes used alone; foo, bar, and baz are sometimes used in that order, when multiple entities are needed.


Prefix your function with something and give it a best-shot name for now. For example, a function that saves-all-products-for-the-selected-user-to-the-database could be RENAME_SaveAllProductsForTheSelectedUserToTheDatabase()

  • Of course, in this case, you should just name the function SaveAllProductsForTheSelectedUserToTheDatabase() Commented Sep 30, 2010 at 22:54

Whatever I call these hard to name variables I make a //TODO find a better name comment so I can go back later to rename it

Usually, when I start to use the variable/function/class I find a better name for them.


It is best to put a good name in soon while you have the code in mind, than to wait until later when you'll be wishing you had named it well!


I almost never have a problem finding good, descriptive names.. but sometimes the naming becomes quite redundant, in that the class and variable names ar very similar. WebClient webclient = new Webclient (uri ); ...and the like.


Sometimes I use zzzz temporarily.

A good rule to help you is this:

  • Does it return a boolean and have no side effects: Then use an adjective (start with is, was) but never future tense.
  • Does it return a different type and have no side effects: Then use a noun.
  • Does it return nothing but do something: Then use a verb.
  • Is it a class: Then use a noun.

In the past I used bob a lot, but this would be the only not-properly-named variable in the function/script because otherwise the code quickly gets unreadable.

(bob is a hangover from uni days - getting away with calling variables bob and fred)

I'm happy to use i for a counter.

Better to use meaningful names, even if they're not short and snappy.

  • I've worked with a guy who used names like that for his applications and classes within his applications. Perhaps needless to say, his code was generally very poor. Commented Sep 30, 2010 at 21:21
  • 2
    @dash-tom-band: I'd think his code was generally very bob. Commented Sep 30, 2010 at 22:53
  • If I can work my name into some hungarian notation for an enumeration I usually do it, even if it's a bit of a stretch. TPropertyEnhancmentTypeEditor = (PETEObtuse, PETEAwful, PETEDispicable); Commented Oct 5, 2010 at 19:22

If I absolutely have no idea what to name the variable, which hasn't happened in over twenty years...names of old girlfriends, or women I wish had been girlfriends. The last code with those identifiers was removed from production quite a few years ago.


WorkMagic or Abracadabra.


blah, but only temporarily. I always go back and rename them to good variable names.

  • 1
    Never use this. No. Bad.
    – Dynamic
    Commented May 12, 2012 at 18:59

Doit(), a(), b(c) xxxx()....

Of course they get refactored away ....usually


I tend to use stuff on my desk.

  • Cup
  • Alt
  • Foo
  • b / a / c (single letter junk)
  • alk (pronounceable multi-letter junk)

I also lean towards generic names (for functions at least):

  • swap
  • process
  • reviseVar
  • tinker

This is for temporary stuff though. I swear nothing makes it into the repository, much less production.


  • I always feel dirty, but sometimes the most apparent name for a method is "Go" or "DoIt". Whenever I can come up with a better name I do, but sometimes it really is "do the work that the name of the program implies is about to occur." That, however, is too long to use for a function name. :) Commented Sep 30, 2010 at 21:18
  • @dash-tom-bang: For some reason, run looks much better than go. Maybe it's because we'd all like our programs to be faster. Commented Sep 30, 2010 at 22:54

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