Instructor: Now, the number of parameters matter
but in addition, it's also the kind of parameters.
And there's one specific kind of parameter,
which you absolutely wanna avoid
and that would be the output parameter.
Now, you should try to avoid output parameters
or output arguments, especially if they are unexpected.
And I have this second part here
because in some cases, especially when working
with certain third-party libraries or frameworks,
you can't avoid them.
But they should never be unexpected.
Take this as an example.
We have a function, which we call,
which is named createId
and which takes a user.
Now, let's assume that this function internally
then adds an ID field
to that user object which it receives as an input.
And that would be not great
because then the user, which is passed into the function,
gets modified by the function.
So the function doesn't return the ID
for the user, which was passed in.
Instead, it manipulates the user object,
which it received.
Here's the full example in code.
It's a createId function
and internally, it manipulates the value
which it receives and adds an id field with a certain value.
So if you pass user to createId,
it simply will have that id thereafter
and this is not necessarily obvious.
We might not expect the user to be edited.
We might have expected that we can simply call createId
and get back an id which we store in a constant
but that's not what this function is doing
and therefore, this is not really clean code.
It has a output parameter
because it actually outputs the results of its work,
in this case, generating the id
as part of the parameter which it received.
It manipulates the parameter
instead of returning a new value.
You generally wanna avoid this
and you especially wanna avoid having functions,
which don't sound like they're doing what they are doing.
It might be better if your function would be named addId
instead of createId.
So let's say it still does what it does internally
but now, the name addId makes it more obvious
that it adds an ID to the user, which we pass in.
It doesn't just create an ID
where we then could reasonably expect
that the ID's returned but instead,
addId makes it very obvious
that the user is likely to be edited.
Hence here, we still have an output parameter
but at least it's more expected.
So it would be okay.
It still might be even cleaner
to not use output parameters in the first place
but if you can't do it any other way,
then at least make it obvious
that you do have an output parameter.
Now, an even cleaner solution, by the way,
might be to use an object-oriented approach
where you have a user object
on which you call addId without any arguments.
Then this would be very obvious
that this probably edits the existing user
and here, it would therefore not be unexpected.
After all, here we don't even have a parameter,
so we definitely also don't have an output parameter
in here because there is no parameter at all.
So this function is totally understandable
and doesn't do anything strange things.
Here's a full pseudo example in code.
We have the User class with the addId method
and here, we don't have any unexpected behavior.
Instead here, it's pretty clear
what this method does to the customer object here.
And therefore, long story short,
the best case is to avoid output arguments, if possible.
But if you need them,
do it as we showed it here in the middle
with a clearly named function
and avoid having function names
which don't make it clear what you're doing
inside of the function
because output parameters can be super confusing
and lead to bugs.
I mean, after all, you are editing a value
which was passed into a function
and that's generally not something you expect
from a function.