How to name a method which may or may not perform an action depending on a condition?

You're trapped in a structural way of thinking. A name should abstract away implementation details. It shouldn't become a short hand for them.

 IfBirthdayBuyCake(); 

is a terrible name. It exposes implementation details as badly as if you wrote them here naked.

I would reach for a better name and a better abstraction.

celebrateHoliday(); 

Somewhere in it you'll likely find something like this

if ( birthday() ) { buyCake(); } 

and maybe some other holidays. When you call it, it may do nothing at all. Which means when you call it you don't have to know if today is a holiday. That not-knowing frees you from that detail. That's what a good name should do.

If you'll forgive a longer name:

celebrateTodaysHoliday() 

makes it a little clearer that if today has no holiday then this does nothing. This makes the scope of discussion explicit.

I would advise against putting conditionals in your method names. If you want the calling code to read like a conditional, use a conditional:

if (cakeIsNeeded) buyCake(); 

Or, if ternary operators or short-circuits are your thing:

cake = cake == null ? buyCake() : cake; cake = cake || buyCake(); 

Otherwise, you can either silently ignore repeat calls, use memoization, or throw exceptions in the method to deal with repeat calls — whatever feels most appropriate and least surprising for the particular method.

If you have a method name that feels like repeat calls would re-perform their action(s) but won't, one way to beat the "surprise" is to add an optional force, skipCache, or similar boolean parameter. (The name of the flag should be relevant to the method name and/or skip-logic.)

All that said, I'd tend to look for a verb that implies what the caller needs, rather than what the method does. In the example of cake, the caller wants the cake and doesn't care much where it comes from. It sounds to me like you just want to getCake() or findCake().

Both of those names communicate that Cake will be returned. They don't reveal to the caller how that Cake will be located. It could be purchased, taken from the counter, or made by magical elves. Those are implementation details.

One important caveat to all of this: These naming patterns tend to be highly idiomized. Refer to your language's internal libraries for examples of how they handle this. And talk to your team to decide on your own internal idioms.

Reasonably common is "performActionIfNeeded" (a method that will cleverly figure out whether an action is needed and only perform it in that case) vs. "performActionIfWanted" (a method that will cleverly figure out that you want to perform an action and only perform it in that case).

If there is a better alternative that still prevents double code execution, feel free to let me know :)

If preparatory calculations is really expensive and calculating it twice would really hurt the performance (so it is not a case of premature optimisation) I would still seperate condition and action into two methods because reading

if (shouldPerform()) doPerformAction() 

is much more intituitive. To cope with the state calculation you can enclose the preparatory calculations into class state like this:

public class MyClass { private CalculationResult preparatoryCalculationResult = null; public boolean shouldPerform() { initIfNeccessary(); return preparatoryCalculationResult.shouldPerform(); } public void doPerformAction() { initIfNeccessary(); preparatoryCalculationResult.doPerformAction(); } private void initIfNeccessary() { if (preparatoryCalculationResult == null) { preparatoryCalculationResult = 42; // very expensive calculation ;-) } } } 

Going on:

To clarify, it is important to the caller that the action may sometimes not be executed, otherwise it seems logical to me to use performAction().

It seems that the caller has some knowledge of what is going to happen. I think it is therefore warranted that the caller can decide whether or not the action should be performed.

An example:

A function should delete all files that match a pattern, but only if their total size exceeds some value. The scanning is expensive, but must be done in order to check the condition. The delete action requires knowledge of the scan in order to prevent scanning twice.

I would simply split this in two methods:

// Returns a ScanResult containing files matching a pattern ScanResult performScan(Pattern pat); // Deletes a list of files void delete(List<File> files); 

The condition can now easily be externalized:

ScanResult result = obj.performScan(...) if(result.totalSize() > 100 * 1024) { obj.delete(result.getFiles()); } 

Part of the problem is the void return type of the original method. It would be better to return some kind of result struct object to the caller to indicate differing degrees of success. This gives the caller the information about what did or didn't happen, in case it needs to know to pass the message back to the UI or something similiar. It also quickly/clearly signals to the next coder to touch the code that the method called might not perform heavy operations with every call.

public class OperationResult { public OperationState State { get; set; } public string OperationMessage { get; set; } // result codes, etc public enum OperationState { NoOperationPeformed, OperationSuccessful } // can have more if needed } 

You might return the whole class above, if you need the OperationMessage (or other data about the call), or just the enum OperationState if you just want to signal that the 'real' work of the function was skipped.

Its possible a fellow coder might assume from that void return that the method always does the same thing. Returning the above could help indicate through IDE intellisense that there's some other possibilities.