If functions need to be specific or universal

Question

Possible duplicate:
Concrete functions against many arguments and context dependent

So, I’ve been developing for 3-4 years, I know a wide range of languages, I know some impressive ones (for those who have little understanding: P).

But I always wondered; when I make a function, if it will be for a specific purpose, or should it be molded for reuse, even if I do not need to do this?

eg:

//JS, but could be any language really //specific function HAL(){ alert("I'm afraid I can't let you do that, " + document.getElementById("Name").value + "."); } //generic function HAL(nme){ alert("I'm afraid I can't let you do that, " + nme + "."); } //more generic function HAL(msg, nme){ alert(msg + " " + nme + "."); } 

Yes, a very simple example, but conveys the point I want to make. If we take this example, would I use it outside the first? Probably not, so I would have a desire to do it this way, but then common sense (now) will convince me to do it second, but I don’t see any benefit from this path if I know it will not be used in any other way , i.e. it will always use the input value (yes, I would put this in a global variable as usual).

Is this just a case of what, in my opinion, was of the greatest importance at that time, or should I follow the 2nd pattern as best as possible?

Answer 1

A function must not be just a series of statements in order to call them in some other context. It must be a unit of functionality that you want to abstract. Creating a function for a particular one is good, but making it context sensitive is bad. What you have to do is use the general (last) way presented in your message, but provide the messages as constants. The language you use has some way of declaring constants right?

Answer 2

In this particular case, I would now write the first function ( YAGNI , right?) And probably never need to change it. Then, if it turned out, I needed to support alternative names, I would make the current default behavior, but allow optional parameter specify the name. Similar to post.

 # In Ruby, but like you say, could be in anything: // specific def hal() puts "I'm afraid I can't let you do that, #{fetch_name}." end // genericized refactoring def hal( name = fetch_name ) puts "I'm afraid I can't let you do that, #{name}." end 

As a rule, this approach, which I prefer to do: create functions of any degree of convenience of a degree of specificity for my current needs, but leave the door open for a more generalized approach later.

It helps me use languages ​​like Ruby that make it easier, but you can use the same approach to some extent even in Java or C. For example, in Java you can make a specific method without parameters first, and then later refactor to more A generic method with the name parameter and a shell without parameters that populates the default name.

Answer 3

The rule of thumb is that a function should have minimal side effects.

So really, it would look something like this:

 //By the way - don't call functions nouns. functions are verbs. data are nouns void HAL(string s) { voicetype_t vt = voice.type(); voice.type(VOICE_OF_DOOM); voice.say(s); voice.type(vt); } 

Answer 4

In your example, I would not become generic. If functionality can be used in many cases, make it common so that you can use it all the time without “copying, pasting, making minor changes, redoing”. But, telling the user, he cannot do this and referring to him, because [the contents of a specific input field] is useful only for one case. In addition, the last shot is meaningless.

However, I usually prefer my code to be as general as possible. Well, as long as there is a chance, I will need it one day ... let's not violate YANGI too much. But if it can be shared without hassle, why not?

Answer 5

In my opinion, functions should be generalized only to the extent that their goals should be. In other words, you must concede to the fact that, although we want to think differently, not everything can be reused, and therefore you must not go out of the way to realize everything in order to be that way. Programmers must be aware of the scale (and possibly future development) of the product, so ultimately you should use your intuition about how far you can use generalizations of functions.

As for your examples, No. 3 is completely useless, since it just sticks the space between two lines and adds a period at the end - why does someone do this with a special function? I know this is just an example, but if we talk about how far the method can be generalized, something like this, making it too far - almost to the extent that it just disappears LOC, and it never sacrifices for the sake of generalizations.

Answer 6

First, HAL() is a terrible name for a function, regardless of what it does. If this is "HAL.say (); or HAL.respond ()", you may have something. But if you call such functions as their common type is the least of your worries.

A rule is a code if it is loosely coupled and very coherent.