Skip to main content
added 46 characters in body
Source Link
Doc Brown
  • 220.6k
  • 35
  • 410
  • 625

You can have both - a function which does not check parameters, and another one which does, like this (maybe returning some information about if the call was done):

bool tryRunFunction(...)
{
    bool shouldThisRun = /* some logic*logic using data not available inside "runFunction"*/;
    if (shouldThisRun)
        runFunction();
    return shouldThisRun;
}

That way, you can avoid duplicate logic by providing a reusable tryRunFunction and still have your original (maybe pure) function which does not make the check inside.

Note that sometimes you will need a function like tryRunFunction with an integrated check exclusively, so you could integrate the check into runFunction. Or you have no need for reusing the check anywhere in your program again, in which case you can let it stay in the calling function.

However, try to make it transparent to the caller what happens by giving your functions proper names. So callers do not have to guess or look into the implementation if they have to make the checks by themselves, or if the called function already does it for them. A simple prefix like try can often be sufficient for this.

You can have both - a function which does not check parameters, and another one which does, like this (maybe returning some information about if the call was done):

bool tryRunFunction(...)
{
    bool shouldThisRun = /* some logic*/;
    if (shouldThisRun)
        runFunction();
    return shouldThisRun;
}

That way, you can avoid duplicate logic by providing a reusable tryRunFunction and still have your original (maybe pure) function which does not make the check inside.

Note that sometimes you will need a function like tryRunFunction with an integrated check exclusively, so you could integrate the check into runFunction. Or you have no need for reusing the check anywhere in your program again, in which case you can let it stay in the calling function.

However, try to make it transparent to the caller what happens by giving your functions proper names. So callers do not have to guess or look into the implementation if they have to make the checks by themselves, or if the called function already does it for them. A simple prefix like try can often be sufficient for this.

You can have both - a function which does not check parameters, and another one which does, like this (maybe returning some information about if the call was done):

bool tryRunFunction(...)
{
    bool shouldThisRun = /* some logic using data not available inside "runFunction"*/;
    if (shouldThisRun)
        runFunction();
    return shouldThisRun;
}

That way, you can avoid duplicate logic by providing a reusable tryRunFunction and still have your original (maybe pure) function which does not make the check inside.

Note that sometimes you will need a function like tryRunFunction with an integrated check exclusively, so you could integrate the check into runFunction. Or you have no need for reusing the check anywhere in your program again, in which case you can let it stay in the calling function.

However, try to make it transparent to the caller what happens by giving your functions proper names. So callers do not have to guess or look into the implementation if they have to make the checks by themselves, or if the called function already does it for them. A simple prefix like try can often be sufficient for this.

added 8 characters in body
Source Link
Doc Brown
  • 220.6k
  • 35
  • 410
  • 625

You can have both - a function which does not check parameters it does not necessarily need, and another one which does, like this (maybe returning some information about if the call was done):

bool tryRunFunction(...)
{
    bool shouldThisRun = /* some logic*/;
    if (shouldThisRun)
        runFunction();
    return shouldThisRun;
}

That way, you can avoid duplicate logic by providing a reusable tryRunFunction and still have your original (maybe pure) function which does not make the check inside.

Note that sometimes you will need a function like tryRunFunction with an integrated check exclusively, so you could integrate the check into runFunction. Or you have no need for reusing the check anywhere in your program again, in which case you can let it stay in the calling function.

However, try to make it transparent to the caller what happens by giving your functions proper names, so. So callers do not have to guess or look into the implementation if they have to make the checks by themselves, or if the called function already does it for them. A simple prefix like try can often be sufficient for this.

You can have both - a function which does not check parameters it does not necessarily need, and another one which does, like this (maybe returning some information about if the call was done):

bool tryRunFunction(...)
{
    bool shouldThisRun = /* some logic*/;
    if (shouldThisRun)
        runFunction();
    return shouldThisRun;
}

That way, you can avoid duplicate logic by providing a reusable tryRunFunction and still have your original (maybe pure) function which does not make the check inside.

Note that sometimes you will need a function like tryRunFunction with an integrated check exclusively, so you could integrate the check into runFunction. Or you have no need for reusing the check anywhere in your program again, in which case you can let it stay in the calling function.

However, try to make it transparent by giving your functions proper names, so callers do not have to look into the implementation if they have to make the checks by themselves or if the called function already does it for them. A simple prefix like try can often be sufficient for this.

You can have both - a function which does not check parameters, and another one which does, like this (maybe returning some information about if the call was done):

bool tryRunFunction(...)
{
    bool shouldThisRun = /* some logic*/;
    if (shouldThisRun)
        runFunction();
    return shouldThisRun;
}

That way, you can avoid duplicate logic by providing a reusable tryRunFunction and still have your original (maybe pure) function which does not make the check inside.

Note that sometimes you will need a function like tryRunFunction with an integrated check exclusively, so you could integrate the check into runFunction. Or you have no need for reusing the check anywhere in your program again, in which case you can let it stay in the calling function.

However, try to make it transparent to the caller what happens by giving your functions proper names. So callers do not have to guess or look into the implementation if they have to make the checks by themselves, or if the called function already does it for them. A simple prefix like try can often be sufficient for this.

added 61 characters in body
Source Link
Doc Brown
  • 220.6k
  • 35
  • 410
  • 625

You can have both - a function which does not check parameters it does not necessarily need, and another one which does, like this (maybe returning some information about if the call was done):

bool tryRunFunction(...)
{
    bool shouldThisRun = /* some logic*/;
    if (shouldThisRun)
        runFunction();
    return shouldThisRun;
}

That way, you can avoid duplicate logic by providing a reusable tryRunFunction and still have your original (maybe pure) function which does not make the check inside.

Note that sometimes you will need a function like tryRunFunction with an integrated check exclusively, so you could integrate the check into runFunction. Or you have no need for reusing the check anywhere in your program again, in which case you can let it stay in the calling function.

However, try to make it transparent by giving your functions proper names, so callers do not have to look into the implementation if they have to make the checks by themselves or if the called function already does it for them. A simple prefix like try can often be sufficient for this.

You can have both - a function which does not check parameters it does not necessarily need, and another one which does, like this (maybe returning some information about if the call was done):

bool tryRunFunction(...)
{
    bool shouldThisRun = /* some logic*/;
    if (shouldThisRun)
        runFunction();
    return shouldThisRun;
}

That way, you can avoid duplicate logic by providing a reusable tryRunFunction and still have your original (maybe pure) function which does not make the check inside.

Note that sometimes you will need a function like tryRunFunction with an integrated check exclusively, so you could integrate the check into runFunction. Or you have no need for reusing the check anywhere in your program again, in which case you can let it stay in the calling function.

However, try to make it transparent by giving your functions proper names, so callers do not have to look into the implementation if they have to make the checks by themselves or if the called function already does it for them.

You can have both - a function which does not check parameters it does not necessarily need, and another one which does, like this (maybe returning some information about if the call was done):

bool tryRunFunction(...)
{
    bool shouldThisRun = /* some logic*/;
    if (shouldThisRun)
        runFunction();
    return shouldThisRun;
}

That way, you can avoid duplicate logic by providing a reusable tryRunFunction and still have your original (maybe pure) function which does not make the check inside.

Note that sometimes you will need a function like tryRunFunction with an integrated check exclusively, so you could integrate the check into runFunction. Or you have no need for reusing the check anywhere in your program again, in which case you can let it stay in the calling function.

However, try to make it transparent by giving your functions proper names, so callers do not have to look into the implementation if they have to make the checks by themselves or if the called function already does it for them. A simple prefix like try can often be sufficient for this.

added 575 characters in body
Source Link
Doc Brown
  • 220.6k
  • 35
  • 410
  • 625
Loading
Source Link
Doc Brown
  • 220.6k
  • 35
  • 410
  • 625
Loading