Have Geek Brain

When should you change a function versus just writing a new one ...?

/ - n00b

Through the gift of lore and knowledge coded here, I make every effort to avoid n00b errors as I learn programming basics.

I use functions when I (think I) can in PHP, and keep them sort of in different flavors.

The n00b problem I'm running into is situations where maybe 4/5 of an existing feature is relevant to a new need. Maybe there is a slightly different set of inputs, or an additional calculation or two in the series, or a different format / structure is needed for the output ... but the core of the function is still applicable.

Is there a correct rule of thumb for when to attach shit to the original function, and when to (literally) copy and paste most of it into a new function and tweak it according to the situation?

On the one hand, I feel bad code to cheat, on the other hand, I feel bad about cluttering an existing function with things that are not always needed ...

+2


a source to share


5 answers


A good rule of thumb is never copy and paste.

If 4 / 5s of functions A and B are identical, separate them. Have both of them call a new C function that implements the common part.



If you show the code in which you have this problem, we can suggest how best to split it.

+5


a source


I agree with @Thomas's stipulation that you need to do an impact analysis before splitting the shared bits into a new function that your new function and the changed old one call.

The project manager, development team, and client will not thank you if your goal of rather complex code arises from significant regression testing of areas of the application that were previously unavailable.

In cases where time / money doesn't exist to encode properly, I reluctantly copy and paste or write a new function that uses the old one and makes up for an extra 1/5 of the required and surround that with a comment



>>>>>HACKCIDENT ZONE, 
>>>>>NEXT TIME THIS CODE IS CHANGED THE OPPORTUNITY SHOULD BE TAKEN TO CORRECT THIS HORROR
.....
.....
<<<<END OF HACKCIDENT ZONE - move on nothing more to see here

It's not perfect, but it makes me feel a little better about myself ...

0


a source


Why do you find that your functions are doing 4/5 of the same job? It is clear that you do not have good abstraction and responsibility.

A function should always do one thing, do it right, and do it well. Take an example of the Average function that calculates the average of an array of integers. A naive implementation will sum all the elements and then divide them by the number of elements. This division has a problem even though it knows how to sum an array of integers. This violates the above limitation. A better implementation would split the Sum () function from Average () and have Average () using Sum () to get the sum of an array of integers. The chorus phrase "a function should only do one thing" is "a function should only know how to do one thing." For everything else, it can rely on other abstractions (like functions). "

What can you gain from clear abstraction and segregation of responsibility?

  • Better layout of your code, easier to write new functions
  • There is no folder copying and coding propagating potentially buggy code across your entire codebase.
  • Better readability, the reader is not distracted by implementation details for things that are not directly related to what the function should do.
  • Provides transparent performance optimization.
0


a source


Think DRY or DIE - don't repeat yourself, but duplicate evil!

Divide your functions. If you copy 4/5 functions to 5 different functions in 5 different files and find an error in one of them, you will most likely forget to update at least one of them.

0


a source


It's not that kind of a question of which code in a function is the same, but what is the purpose of the function, and whether it matches the purpose of the function you are creating.

Consider if you have a function that takes widgets into account:

function count_widgets($widgets)
{
    // Counting functionality
}

and you need a new feature that takes whatsits into account but separates it. You can create a function that takes widgets or whatsits into account:

function count_widgets_or_whatsits($thing)
{
   if( $thing instanceof Whatsit )
   {
     // Special whatsit stuff
   }
   // Counting functionality
}

But that would violate the contract of function. Instead, you create a new function and retrieve the common functions:

function count_widgets($widgets)
{
    return count_things($widgets);
}

function count whatsits($whatsits)
{
    // Special whatsit stuff
    return count_things($widgets);
}

function count_things($things)
{
   // Counting functionality
}

This will:

  • Make the code easier to understand for someone else. (Someone might easily assume that they count_whatsits()

    would count watsits)
  • Provides a solid contract between what's called and what's going on. If the Whatsit counting process changes, you can simply change the functionality count_whatsits()

    without affecting how the widgets are counted.
  • Save your maintenance problems when you change something that affects something else.
0


a source






More articles:


All Articles