Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Imagine you have such routines

/*just do X. Fail if any precondition is not met*/

/*take care of preconditions and then do X*/

A little bit more concrete example:

/*create directory. Most probably fail with error if any precondition is not met (folder already exists, parent does not exists)*/

/*take care of preconditions (creates full path till folder if needed, checks if not exists yet) and then creates the directory*/

How do you name such routines, so it would be clear what does what?

I have come to some my own "convetion" like:

naiveCreateDirectory, ForceDirectoryExists, ...

But I imagine this is very standard situation.

Maybe there already exists some norms/convetions for this?

share|improve this question
Usually, when you're asking yourself this question, it's because one method is doing too much. What's wrong with having three methods (leading to if (!DirectoryExists(path_name)) { CreateMissingDirectoriesInPath(path_name); CreateDirectory(path_name); } (actually, in this example, I'd probably try to use recursion to solve the problem, but I don't think that helps you in a more general case.) – pdr Nov 22 '12 at 14:01
@pdr If your comment were an answer it would take first spot. The advantage of writing very decsriptive function names is easily being able to tell when things are getting out of control. If doEverythingIncludingThatOtherThing() looks ridiculous, it means 'the system' is working! – MrFox Nov 22 '12 at 20:52
@pdr if same 3 commands are repeated over and over (in exactly same maner), then I assume it is a good thing to move that into separate routine.. Isn't it? – dnsmkl Nov 24 '12 at 13:23
@dnsmkl: In that case, I'd move it to another class, the class name would specify the technique. Taking the previous example, I'd have an IDirectoryCreator (or DirectoryCreator in Java) interface with a Create(path) method. Then I'd implement that on a MultiLevelDirectoryCreator class. The calling code doesn't need to know about implementation details, it only needs to know that it can create a directory and it has a DirectoryCreator to help it do that, so you can inject the MultiLevelDirectorCreator object via the constructor or fetch it from an IoC Container. – pdr Nov 24 '12 at 14:55
up vote 2 down vote accepted

There are many possible conventions - I often have to have routines that do something, and other routines that check things and then, eventually, either do it or not. I invariably call these frobWidgets() and maybeFrobWidgets(). There are other prefixes that would fit, e.g. ensure is often used for code that initializes something lazily, but there isn't a universal convention. It's not necessary, though. Far more important than perceived consistency with the "state of the art" is actual consistency within your code base. So go ahead with checkAndFrob() vs. frob() if you've already started doing that.

share|improve this answer
Forth I want to clarify my self. I'm not trying to find latest buzz, just some pre-existing knowledge. Something as design patterns in OO world (e.g. Abstract Factory etc.) – dnsmkl Nov 24 '12 at 13:38

If I have a function that may fail - such as creating a directory, writing to a file, etc. - I use the following signature:

bool TryDoSomething(string someParam)

So the method will do something with someParam. If successful, return true; likewise, if unsuccessful, return false.

Method parameters are obviously not always necessary. There is another advantage to this method signature in that you don't have to throw exceptions above this method unless deemed fatal. Note this method can be used to return out values as well. Reference the C# dictionary TryGetValue(...) method.

I also name functions that validate data as SomeParamIsValid(string SomeParam). In this way, I can write something like:

if (SomeParamIsValid(someParam) {
   if(!TryDoSomething(someParam, out SomeObject someObj) {
      // handle failed operation

   return someObj;

This makes for some very readable and easily maintained code, in my opinion.

share|improve this answer

Usually function names should be longer when the functions' scope is shorter (ie. private methods) and shorter the name when the functions are public with a longer scope.

In your case, I usually do something like this: createDir($path) and fail with ugly error; or tryCreatingDir($path) and catch the error and continue with an internal decision like throw a nice error message or if the directory already exists suppress all errors and get out as normal.

This does not pollute the naming but does a differentiation. Also the explicit nice user friendly exception message is enough for all the exceptional cases.

Sometimes I invert this and use createDir() to check for stuff and than the second method would be doCreateDir() and I would call it ONLY if all conditions are met to create the directory.

share|improve this answer

I'ld go with:


If these are ambiguous ie if there were two different types of directories I'd split the object in two which would both implement an interface called something like DirectoryHandler.

share|improve this answer

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.