0

I was wondering what are the pro and cons between having one function with a if statement dictating 2 sections of code or two discreet functions that are called on separately.

In terms of pro and cons I was thinking. Computational Complexity Readability Maintenance And any other component I did not consider.

Here is a example 

//One if statement two parts of code.

Foo1(data,flag){

if (flag==True) {
      //Do Code
     }

else {
      //Do Code a little bit differently 
     }
}

//Or two discrete statements

Foo1_True(data){
//Do Code
}

Foo1_False(data){
//Do Code a little bit differently 
}

(I have a feeling the answer is going to be neither, and I have to find a more elegant way to capture both functionality.

Engineert
  • 917
  • 1
  • 5
  • 17
Drummerboy2543
  • 1
  • 2
    I know what I would do *in the general case*, but without knowing the details, that may not apply to you here. Though in the very least if you choose the route with the separate methods, please don't name them `Foo1_True` and `Foo1_False`. Determine what makes them behave differently and name them accordingly. – Neil Mar 25 '19 at 08:05

1 Answers1

0

Based on a barebones technical level, much like your example, there is no difference.

But you're sort of misrepresenting the argument of using submethods. The methods should not be named after the block that wraps around a particular call to that method. The methods should be named for what they do:

DoTheThing(data){
   //Do Code
}

DoTheOtherThing(data){
   //Do Code a little bit differently 
}

On a technical level, the name of a method doesn't matter. But when a developer uses unusual naming that could be a sign of a developer who misunderstand the purpose of a pattern and how to leverage it correctly.

Because you say "Do Code a little bit differently", that strongly suggests that the majority of their body will be the same, and thus can be abstracted:

DoTheThing(data){
   DoTheSharedThings(data);
   //Do whatever is unique to this case
}

DoTheOtherThing(data){
   DoTheSharedThings(data);
   //Do whatever is unique to this case
}

DoTheSharedThings(data) {
    //Do Code that always needs to be done
}

This is part of the reason why submethods are often advocated for. The habit of doing so leads to a better innate understanding of segregating reusable parts. That doesn't mean you should always create a submethod, but rather that you should try to favor submethods as a matter of good practice.

In terms of pro and cons I was thinking Computational Complexity, ...

Method calls have a negligible computational complexity. I'm pretty sure the compiler mostly ignored the concept of "methods" anyway. And even if it doesn't, I have never heard of an argument where performance is in any way affected by doing a few additional method calls.

..., Readability, ...

This can go both ways. Too few submethods lead to monolithic functions which are hard to read. Excessive submethods lead to excessive separation, which hinders readability when you are trying to understand a larger algorithm.

The rule of thumb I use is that submethods should be used in one of two cases:

  • It makes a subalgorithm reusable so multiple methods don't need to copy/paste this subalgorithm.
  • It hides an algorithm that is not relevant to the current code.

As an example for the latter point: in a method which imports users, I don't care how users are stored in the database, only that they are being stored. Therefore, when I see SaveUserToDatabase(user), I know everything I need to know.

This is better than having to see 10+ lines of code which deal with the actual database connection and query. Interestingly, I've spotted a pattern for most developers. When they do just use the 10+ lines of code without a submethod, they often include a comment which explains what this "chapter" does.
The developer's urge to label this "chapter" to make it understandable inherently suggests that they should have put it in a submethod, labeled it (using the method name) and then used that submethod instead of the comment + 10+ lines of code.

..., Maintenance, ...

Reusable methods inherently minimize effort needed to rework behavior. If three methods (or classes) all independently save users to the database, and we have to change the way we save users to the database, we're going to be stuck having to do it three times.

I have run into countless examples of developers forgetting to update all instances of the same copied logic, which leads to inconsistent behavior and can cost you upwards of days in lost effort due to nonsensical debugging, a lengthy bughunt, and probably end users who are dealing with unforeseen bugs due to the inconsistency (because developers more often forget to update the logic which is rarely used, as opposed to the most used logic).

... and any other component I did not consider.

It's better for readability, it enables reusability, it avoids contradictory behavior when forgetting to update copy/pasted instances of the same algorithm, ... I don't think you need any more reasons to do it?

Flater
  • 44,596
  • 8
  • 88
  • 122