Instructor: Now, what about functions
that take two arguments?
For example, take this login function here.
It takes an email and a password,
and then internally it might be doing
whatever logic is required to log a user in,
to create a session for the user for example.
This again is something which makes sense
and which is expected.
Here, we have two parameters,
but the order is not surprising because in most forums,
we also have the email field first
and the password field second.
So this order of arguments makes sense.
And calling this function is very readable.
It's immediately obvious what this function does
and that we have an email address and a password
as expected parameters.
So this could be an example for a two argument function,
which is no problem at all.
And now for example would be this point clause,
which be instantiate by using the point constructor.
We take two arguments here, the X and Y coordinate.
And this again is really just common sense.
It is expected that the X argument is the first argument
and the Y value is the second parameter.
And therefore this is easy to understand,
easy to read and does nothing unexpected.
We don't need to think a lot
about calling this constructor function here
because it is very obvious what it does
and what these values will be.
So, as you can probably tell by now,
it is about minimizing the number of parameters,
but it's simply also about how readable
and how easy to understand a function is
if it's obvious which parameters it needs
and in which order these parameters need to be provided.
Like in this login or point example,
then it's absolutely fine to use two parameters.
You don't need to come up with a way of reducing
the number of parameters.
Because after all, you should always keep in mind,
that writing clean code is about writing readable
and meaningful code and about reducing the cognitive load.
So if we have no cognitive load,
because it's clear and easy to grasp what a function does
and how we should call it,
then of course there is no need to rewrite it.
And that is an important difference
between the examples I showed you thus far
and this example here.
Here, we got a log function,
which actually takes two arguments.
And if you just have a look
at the way we call this function,
it's totally not obvious how we should call it
what this second argument is about
and which order these arguments should have.
It's obvious that we have a message,
but what does false mean here?
We need help from the IDE to get some extra insight,
but ultimately, we probably need to dive into the code
to fully understand what this actually does.
And to understand that is error is an extra flag,
which controls how the message is being output.
And you wonder why such bullion flags in general.
But in addition, this is also a good example
for a two argument function,
which would better be written in a different way,
or which would better be refactored.
For example here, a better solution could be
to split this one function into two functions
where one function is dedicated to normal messages
and one function focuses on errors.
That way we have two functions with one argument each,
which then again are way easier to call and understand.
And that is what clean code is all about.
Questioning the code you have
and trying to always improve it
such that it's more readable, easier to understand
and requires less thinking and reasoning about the code.