Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Is there a school of thought on putting focus on using generic names for functions, opposed to naming functions based on the things they do?


Say we have a Bill / Price Sheet object, that has line items

* Shipping Charge  $5.00
* Crate Charge $6.00
* Tax Charge $8.00

Generic function names would be:

//function's code knows how to add a line item
bill->addLineItem("Shipping Charge", 5);
bill->addLineItem("Crate Charge", 6);
bill->addLineItem("Tax Charge", 8);

Specific function names would be:

//function's code reflects knowledge of this specific line item

This can be extended to any set of similar actions where something similar is being done. A more generic function takes the actual parameter, and can be deemed more flexible - any new line item can be added using the same function. A more specific function can only be used for that particular line item. Adding a new type of line item requires a new function. Something tells me that the specific way is more preferred, but I can't verbalize why, and maybe I am wrong. But perhaps it makes the code more clear as to what this line item is intended to do.

So if specific naming is superior, and I am writing code for a restaurant with 600 items on the menu (such restaurants do exist), I am not sure I want to have 600 unique functions for each menu item. But in that case maybe a different approach is warranted. So what I am asking here, is if I have a reasonable class of items (i.e. 10-20) for my specific possible line item list, would you recommend any particular approach from the ones described (specific vs general), or does it all depend on my project specifics?

share|improve this question

put on hold as primarily opinion-based by durron597, GlenH7, MichaelT, Snowman, gnat Jul 31 at 10:19

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

Why not make a function bill->addCharge(ICharge newCharge) so that you can add new charges by calling bill->addCharge(new ShippingCharge(5)) or bill->addCharge(new TaxCharge(5))? ShippingCharge and TaxCharge both implement the ICharge interface. –  valenterry May 7 '14 at 15:30
Btw, if the differend kind of charges have to be stored seperatly in the bill class because they have to be handlend different later (AFAIK PHP doesn't support pattern matching yet), then i would suggest using method overloading so that you have multiple addCharge(...) with different signatures as there is one method then for each kind of charge. –  valenterry May 7 '14 at 15:39
so you are saying use both! and yes I am using PHP, so overloading won't work directly –  Dennis May 7 '14 at 15:46
If overloading must not be used/implemented by workaround (like dinke.net/blog/en/2007/08/01/method-overloading-in-php5 or by using func_get_args()) then i guess you can't express this without violating SOLID / DRY. This means you would have to use one of the options you suggest in your question. Your feeling is correct that the specific function names are better then because it is more clear and better supported by many IDEs if you are calling a non existing method name than calling a method name with an syntactic correct but method contract violating String. –  valenterry May 7 '14 at 15:56

1 Answer 1

Yes, don’t use generic names unless this would result in ugly code, such as 600 menu item functions. In practice, it depends.

If the function really is generic - it doesn’t have any if-statements for logic that depends on the kind of menu item - then addMenuItem is a good name, because that’s what it does.

If the function contains menu item-specific logic, then depending on your language, object-oriented design gives you ways to dealing with this, without requiring ‘600 unique functions’. For example, it might make more sense to subclass MenuItem and add alternative add method implementations.

share|improve this answer
It may also happen that one approach is changed later into the other because of enhancements and/or refactoring. –  JensG Nov 17 '14 at 12:53

Not the answer you're looking for? Browse other questions tagged or ask your own question.