It reduces productivity by making Microsoft think it's okay to design functions to take 10 or 12 parameters, so virtually nobody ever can or will even come close to learning how to use them without the assistance of (something like) Intellisense.
Edit: Okay, let's take a look at the CreateAnimatedSprite
example. First, a function name with two verbs is a nearly-certain sign of poor separation of concerns -- i.e., you have a single function that's really doing two things. Our first step is to fix that so we get a CreateSprite
(or, since it's apparently being loaded from a file, it should probably be LoadSprite
), and an AnimateSprite
. For the moment, let's even assume @Mason is wrong, and you really do need all those parameters -- but when we've separate concerns decently, we're apparently left with something like:
sprite LoadSprite(std::string filename, int imageHeight, int imageWidth);
void AnimageSprite(sprite s, int frameWidth, int frameHeight, int numColumns, bool isLooped);
By my count, we now have the parameter count down to a maximum of 5 -- half the number I'd mentioned as being excessive.
I'd consider this well short of ideal though. First of all, I'd advise against using a bool
as a function parameter in most cases. Just glancing at a call to the function, it's not immediately obvious what true
or false
would refer to. It would be better to have something like:
enum {LOOP, NOLOOP};
When somebody's reading a call to the function, LOOP
is much more meaningful than true
. Depending on the situation, there are a couple of other possibilities to consider. One would be using object-orientation, so we'd get:
class Sprite {
public:
enum looping { LOOP, NOLOOP };
load(std::string filename, int imageWidth, int imageHeight);
animate(int frameWidth, int frameHeight, int numColumns, looping doLoop);
};
That gets us down to only four parameters for a function, still providing the data you thought was necessary.
In reality, we can probably do better still. First of all, the file from which we load our sprite can store the size of the image(s) it holds, so we may not need to supply that (it's primarily useful if we're selecting one sprite from a file that may hold several). Second, as @Mason pointed out, we probably don't need to supply a frameWidth/frameHeight or numColumns either. In addition, single-pass animation and looped animation are enough different that it's frequently more sensible to supply those as two separate functions. Finally, it might well make sense to just pass the file name from which we're going to read the sprite as a parameter to the ctor. Incorporating all those, we get:
class Sprite {
public:
Sprite(std::string const &filename);
animate(page const &target);
loop(page const &target);
};
So to load an animate a sprite, we now need something like:
Sprite x("somefile.spr");
x.loop(animPage);
Keep in mind that peoples' short-term memory ranges from about 4 items for a person of average intelligence to about 8 for the top geniuses.
That means 10 parameters is nearly always unreasonable. 7 parameters puts it within reach of a few, but honestly only a few. 4 puts it within reach of almost any programmer, and 1 (or even 3, if you really do need to specify resolution) puts it into the dead simple catgory.