Naming function with "proceed"

Question

I am wondering if it is good practice to name function which does the main logic "proceed" + "functionName".

I would use that name if there are some checks(if-s, try-catches, etc.) in the beginning of the function and I would like to separate main logic into separate function.

Example:

private void function() {

    if(someCondition1) {
        throw Error1;
    }
    if(someCondition2) {
        throw Error2;
    }
    
    try {
        proceedFunction(); // <-- Name of the function here
    } catch(Exception e) {
         // Error handling
    }
}

private void proceedFunction() {
    // Main logic
}

Answer 1

The content of your alleged proceedFunction is, in fact, described by function. What you're doing outside of the proceedFunction (but still in function) are some preliminary validations.

Currently, you're thinking of it like this:

myFunction = method body + [proceedMyFunction]

I suggest reframing your mindset, so the that name ("function") more closely describes the actual function being done, i.e.:

myFunction = [validateMyFunction] + method body

In other words, your code would be something like this:

private void Foo()
{
    ValidateFoo();

    // do the Foo work here
}

private void ValidateFoo()
{
    if (x == 5)
        throw new Exception("x is 5!");
}

Now, both Foo and ValidateFoo aptly describe what's happening inside their method bodies.

---

Do you need to separate the validation from the actual work? That's contextual.

If both parts are trivial and short, it may not be necessary to actually split them.
If either part is less than trivial, splitting them may significantly improve readability. It obviously also increases reusability when needed.

Answer 2

While this is relatively subjective and opinionated and might be closed as such, I'll try to answer, not with a direct yes or no but with a more general criterion.

When you find yourself debating naming conventions, the first question you need to ask is "who is going to be reading this code". Try to think beyond who ia currently reading the code and about who might need to understand it down the line.

• Arw you working as part of a team? In a company that develops software? Talk to your team and check existing style guides, naming guides and the existing codebase for similar patterns. Following local conventions helps your teammates, other employees and future maintainers understand your code better.

• You are probably not the first person to be using the programming language, framework or libraries you are using. Find a universal style guide for the language, like PEP for python or the Microsoft naming guide for C# and see if it answers your question. Find other projects using your language or framework and see how they name their functions and patterns. Adhering to that means that other developers coming into your code - either new hires, open source contributors or even just people you ask for help on SO - can easily understand you.

• Is your app on a specific domain? Like finance, cyber security, crypto currency, or whatever? Check out projects on this domain to see if there are common cross language naming conventions. For the same reasons as above: you want your code to be as readable as possible to the right people.

---

As for your specific question - I'm not familiar with the style of having method pairs named DoX and ProceedDoX, and their meanings will not be intuitive to me from my experience, but specific languages or domains might be using it.

I can't offhand think of specific naming patterns for this, but I've seen pairs where DoX was matched with DoXNoChecks, DoXInternal or DoXImpl, each with their own advantages and disadvantages.

Answer 3

As a reader of your code, I expect a function with a specific name, to do the thing the name suggests. I would be surprised to find that the function only validates whether the actual function can be called.

It is also rather error prone, because the actual function that does the work, can be called from elsewhere and no validation will be performed.

Cleaning up large functions by breaking them up is good practice, but break up sections that make sense on their own. In your example the check for someCondition1 and someCondition2 are better candidates to extract into separate functions.

private void doWork() {

    checkCondition1(...);
    checkCondition2(...);
    
    try {
        // handle actual doWork logic
    } catch(Exception e) {
         // Error handling
    }
}

private void checkCondition1(...) {
    // perform checks
}

private void checkCondition2(...) {
    // perform checks
}