views:

150

answers:

8

Possible Duplicate:
Anyone else find naming classes and methods one of the most difficult part in programming?

Sometimes it seems i cant really find any name for a function i am writing, can this be because the function is not cohesive enough?

What do you do when no good name for a function comes to mind?

+1  A: 

Give it your best-shot and re-factor later if it still doesn't fit.

cristobalito
A: 

Go to www.thesaurus.com and try to find a better suited name though synonyms.

Sergej Andrejev
It also comes with experience. There is many magic words in programming like: handler, repeater, builder, utils, convertor, manager and so on. When you read a lot of code and books about programming you bit by bit find out these words and situations when they can be used
Sergej Andrejev
Usually when something is best-named "Manager" you've got a problem.
Rex M
I disagree. In .Net you have lot of managers. I wouldn't say they are badly named or .Net have problems in these particular parts. Manager is just a name as any other. Check out: CommandManager, ApplicationManager, ResourceManager, PropertyManager, SecurityManager... I could name at least 100 managers in .Net framework.
Sergej Andrejev
+2  A: 

Sometimes it could be that your function is too large and therefore doing too many things. Try splitting up your function into other functions and it might be clearer what to call each individual function.

Don't worry about naming things with one or two words. Sometimes if functions do something that can be explained in a mini-sentence of sorts, go ahead and name the function a little longer if it'll help other developers understand what is going on.

Another suggestion is to get feedback from others. Often others who come from another perspective and seeing the function for the first time will have a better idea on what to call the function.

digiarnie
A: 

Almost as important as the function name is that you are consistent with comments. Many IDEs will user your properly formatted comments not only to provide context sensitive help for a function you might be using, but they can be used to generate documentation. This is invaluable when returning to a project after a long period or when working with other developers.

In academic settings, they provide an appreciated demonstration of your intentions.

A good rule of thumb is [verb]returnDescription. This is easy with GetName() type functions and can't be applied universally. It's tough to find a balance between unobtrusive and descriptive code.

Here's a .Net convention guide, but it is applicable to most languages.

Laramie
I wholeheartedly disagree. I frequently find that the best commented code is the hardest to read, and usually also the most error-prone. At uni teachers would tell us that commenting code was the cat's pj's, but years of experience has taught me otherwise. Good code truly is code that requires no inline comments, because the functions are in par with the systemes architechture. "Make sense - not comments" is what I always say.
Banang
@Banang I appreciate the perspective. Comment clutter is a problem and shouldnt be used in place of'good design. Like you said http://stackoverflow.com/questions/184618/what-is-the-best-comment-in-source-code-you-have-ever-encountered/694644#694644
Laramie
A: 

I find it easier to name functions when I don't have to cut back on the words. As long as your not doing javascript for the google start page you can do longer names.

For example you have the method dequeueReusableCellWithIdentifierandmergeChangesFromContextDidSaveNotification in apples cocoa framework.

As long as it's clear what the function is doing you can name it whatever you want and refactor it later.

Patrik Björklund
+7  A: 

For naming functions, just avoid having simply nouns and rather name them after verbs. Some pointers:

  1. Have function names that are unique visibly, e.g. don't have validateInput() and validateUserInput() since it's hard to say what one does over another. Also, avoid having characters that look very similar, e.g. the number 1 and lowercase 'l'. Sometimes it makes a difference.
  2. Are you working on a project with multiple people? You should spend some time going over naming conventions as well, such as if the function name should have underscores, should be camelCase, etc.
  3. Hungarian notation is a bad idea; avoid doing it.
  4. Think about what the function is doing. The cohesion that you mentioned in your question comes to mind. Generally, functions should do just one thing, so don't name it constructCarAndRunCar() but rather have one function that constructs and another that runs it. If your functions are between, say 20 and 40 lines, you're good.
  5. Sometimes, and this depends on the project, you might also want to prefix your function names with the class if the class is purely procedural (only composed of functions). So if you have a class that takes care of running a simulation, name your functions sim_pauseSimulation() and sim_restartSimulation(). If your class is OOP-based, this isn't an issue as much.
  6. Don't use the underlying data structures in the functions themselves; these should be abstracted away. Rather than having functions like addToVector() or addToArray(), have them be addToList() instead. This is especially true if these are prototypes or the data structures might change later.
  7. Finally, be consistent in your naming conventions. Once you come up with a convention after some thinking, stick to it. PHP comes to mind when thinking of inconsistent function names.

Happy coding! :)

SHC
Wow, nice list, The Hungarian notation is some of the worst things MS propagated, even MS have problems to get rid of the released demon...
jdehaan
Tell me about it :)I worked at MS last summer and Hungarian notation was terrible. Imagine having a long pointer to a WCHAR string: `LPWSTR *`.
SHC
I don't personally use Hungarian notation and never have - but what about it makes it so terrible?
Jamie Wong
Adding the type was unnecessary for me because as a programmer and developer, I felt that I should know the function and data types that I'm dealing with.As I said before, this is especially bad if you're refactoring code. Instead of having a linked list called clientList, you'd have LLClientList with HN. If you decide an array is better, you also need to change all of the other instances of the variable and you're forced to think of type when using variables with HN, not use as it should be.
SHC
@Jamie It shows a predominant focus on types. Programming has evolved nowadays to where usage and interfaces are more important than the actual types we use. Also as SHC pointed out, if a type ever changes, it requires changing the name of every single instance where the type is used in the client code even if the interface and usage remains exactly the same. Finally it burdens the users with implementation details that they may not even have to know. A lot of windows API classes and structures, for instance, might as well be opaque to the user: they just pass them around in API functions.
[...] The information is irrelevant, so to speak. Finally, if one writes code in a way where one needs to know the exact type of an object and it's not obvious, then the code probably needs to be organized better. Hungarian notation is not an excuse to wrote 2000 line functions or a class/struct with 500 members.
@stinky472 Good explanation - thanks
Jamie Wong
+1  A: 

I follow following rule: Name according to the purpose (Why? - design decision) and not to the contents (What, How? - can be seen in the code).

For functions it is almost always an action (verb) followed by the noun of parameters and (or results. (Off-topic but for variables do not use "arrayOfNames" or "listOfNames", these are type information but simply "names"). This will also avoid inconsistencies if you refactor the code partly.

For given patterns like object creation, be consistent and always use the same naming like "Create..." (and not sometimes "Allocate..." or "Build..." otherwise you or your collegues will end up in scratching their head wound)

jdehaan
A: 

As a practical rule of my own, if a function name is too long, it should be atomized in a new object. Yet, i agree with all posts above. btw, nice noob question

fabjoa