Do vs. Run vs. Execute vs. Perform verbs

Question

• What list of verbs are you using for method names? What's your personal or team standard?
• I debate whether to use Do vs. Run vs. Execute vs. Perform and am wondering if any of these are no longer recommended or some that people just don't really use and I should just scratch them. Basically any one of those verbs mean the same thing...to invoke some process (method call). This is outside of CRUDs. For example:

ExecutePayPalWorkflow();

that could be also any one of these names instead:

DoPayPalWorkflow();
RunPayPalWorkflow();
PerformPayPalWorkflow();

or does it not really matter...because any of those verbs pretty much are understandable as to "what" shows your intent by the other words that follow it "PayPalWorkflow"

Naming is something I take very seriously and really think about a lot while coding as:

• it makes code readable to other devs
• it makes my code readable to myself weeks later when I can't remember what I coded

This discussion can go for any language. I just put the two main tags C# and Java here which is good enough for me to get some solid answers or experiences.

Answer 1

I say none of the above. Varying prefixes hurt IntelliSense.

Answer 2

payPalWorkflow.execute()
payPalWorkflow.run()
payPalWorkflow.perform()

It seems your naming convention suffers from lack of abstraction. If something is "executable" then it's method should be "execute()" and you should use the class name to indicate what implements the "executable" behavior.

Whether you use "execute", "run", or "perform" is entirely dependent on the context of the system. If you view these as jobs that need to be run, don't use "perform". If they are tasks that need executed, "run" is likewise a bad choice. The important thing is that all of these methods should be consistent (which is what the interface declaration will enforce).

Answer 3

Shouldn't your method names usually be verbs to start with? Like your example, you could just use the verb Pay instead of Perform + Payment.

Edit:

As for how you might use any of the verbs you list (Execute, Do, Run, Perform), I don't think they are necessary at all. They do not convey any additional information. The fact that you are calling (or executing or doing or running or performing) a method is implied by your syntax.

If you'd like to indicate to the caller that your method may return before the action has completed, there is a convention for that in .NET: Begin* and End*.

The only exception I can think of is if you have an abstraction for any general process. In that case, you'll be forced to use a verb such as Execute or Run, since what you're actually doing isn't yet defined.

Answer 4

Sometimes the language you used before c# / java affects the term you will use. For instance there's a lot of Delphi developers out there who will prefer

PerformSomeTask()

Conversely, I've seen a lot of VB (I guess?) influence, with a tendency to prefix methods as

RunSomething()

I personally avoid any kind of convention like that, because your code will start to look similar. In a recommendation I received from a work colleague on LinkedIn, he mentioned that one project I maintained had 2,000,000+ lines of code. I didn't realize the project was that big, but one thing I learned from that project was that you don't want your code to look like this:

PerformTransaction()    
PerformSubtransaction()
PerformDatabaseConnection()
PerformValidation()
PerformAuthorization()
PeformReportGeneration()
PerformReportGenerationPostTasks()
PerformUserLogOutFinalizationTasks()
PerformDataExport()
PerformDataImport()
// .... and on and on and on...

It just makes everything so anti-readable. Naming conventions should be taken with a large dose of reality salt.

I think the name of the method should simply reflect what it does. One day it might be PerformSomeTask, another day it might be DoImportantThing. But having 20+ Perform[YourMethodNameHere] is not very intuitive.

Answer 5

I find abstraction the better form of self-explanatory code, than long method-names.

May be it's better for you to have something like this:

PaymentMethod payPal = new PaymentMethod("paypal");
payPal.pay();

What is this PayPalWorkflow anyway? It doesn't mean anything to me at the moment... May be you want to payPal.startPaymenetProcess(); with this or

you want to initiate and finish it with 1 method call ?

You have to describe and abstract your system better and then the simple names will follow.

---

Let's forget your example...

and here's my thoughts regarding do/perform/run/execute

run - this is about continuous process. Something that will last. Can be configured while running etc...

do - I won't use the do word because in Java (my working language) it's a command defined by the language

perform - ...a task. Something that is short and executed fast and repeatedly

execute - the final step of something complex with a lot of preparations necessary before that

Answer 6

Semantics aside, in Java, public void run() is almost always correct. This is because of the Runnable, RunnableFuture, and RunnableScheduledFuture interfaces, which are used when you want something to run on a Thread or schedule it for later execution on an Executor.

Answer 7

Ya keep it simple. First of all the function names should be lowercased. Then, nstead of something like PeformReportGeneration, you want generateReport. It conveys the same message more succinctly.

In your case it's harder since Workflow isn't really a verb... how about instead of PerformPayPalWorkflow you just do run, e.g.:

PayPalWorkflow workflow = ...;
workflow.run()

If all you have is a PayPal object that does more than just workflow, though... I'm not sure. I'd need more info about how the code is set up, what a workflow actually is in this case, etc.