Library function best practice

Why not do both?
Is it likely that the function(s) will be called with differing effects?
If so, then choosing (b) means that users have to write a lot of switch or if statements to decide which function to call. So (a) is better in this case.
On the otherhand if mostly only one of the cases is ever called from one place, then (b) creates unnecessary overhead, especially if the call requires passing different kinds of parameters for different kinds of effects.
If both cases are likely to occur, then it's best to have both in your library.

What language are you using by the way? In OOP languages, you could have different classes for different effects and the user could just pass the appropriate object to the call. That way you could easily provide useful methods for manipulating effect parameters too.

It probably depends on what direction you plan on taking the code, but I would say (a). That way your effect types aren't as hard-wired into the code, and it'll be easier to add new ones in the future.

Thanks for the replies. I was leaning towards (a) but I wanted a second opinion. FlowingOoze, this is actually a library for a Neverwinter Nights hakpak, so the language is nwscript. NWN scripting is not advanced enough to support your solution.

Heh. I immediately thought of NWN when I read the OP.

Why not?

c) one "apply effect to target" function with parameter for effect and target.

Do you really need to specify the class when calling it?

yep I need to specify the class. The function takes a library constant as its effect parameter and converts it to a corresponding row index in an NWN 2da file. The effects in the 2da file are listed consecutively but the library constants are not -- the four types of effect are grouped into four lists, each referencing the values 0 to N (I do it this way so that users can append or remove an effect to a type without having to reorder the list of constants). So each class of effect needs a separate conversion algorithm.

How wonderful.

Doing it that way. you should certainly go with (a). Hiding that kind of complexity is exactly what functions are for. Go with (b) as well, and have your (a) function call that. That should make the implementation of (a) trivial, once you've completed (b).