with the help perhaps of a piece of paper and pencil to draw diagrams,
to design what the function will do.
Here, we are really interested in what the function does.
We are interested in the "what" and for the moment, we do not concern
ourselves with the "how", that is, how the function will be implemented.
And this is the stage where it is important to watch out for what
we have seen in a previous episode on prototypes, the so-called
"side effects".
In other words, the function
must do exactly what it was designed to do, no more, no less.
If, for example, you have designed a <i>sqrt</i> function whose
goal is to calculate the square root of a <i>double</i>,
for example <i>x</i> here,
and whose call would correspond to something like <i>z=sqrt(x)</i>,
then the <i>sqrt</i> function here must only calculate the square root of <i>x</i>
and return it to z.
It must not pollute the output in the terminal
with displayed messages.
It must only calculate, without displaying anything at all, the value of the square root of <i>x</i>.