Regardless of the programming language, functions possess certain fundamental properties. Knowing these properties makes it easier to predict the behavior of functions, as well as their testing and their usage. These properties include determinacy. A function is deterministic when it returns the same result for the same input parameters. For example, a function counting the number of characters is deterministic:
import { length } from 'hexlet-basics/string';
length('hexlet'); // 6
length('hexlet'); // 6
length('wow'); // 3
length('wow'); // 3
No matter how many times we call this function and pass 'hexlet', it will always return 6. In turn, a function that returns a random number is not deterministic, as the same input (even if it is empty, i.e. without parameters) will always output a different result. How it differs doesn't matter, even if at least one of a million calls returns something different, this function is deemed non-deterministic.
// A function that returns a random number
Math.random(); // 0.09856613113197676
Math.random(); // 0.8839904367241888
So what use is knowing that to us? Determinacy seriously affects many different aspects. Deterministic functions are easy to work with, easy to optimize, and easy to test. If you can make a function deterministic, it's best to make it one.
Side effects
You may have already realized (maybe subconsciously) that console.log() is a function.
It takes any data type as input and prints it.
Now, guess: What is the return value of the console.log() function? Answer: whatever value it produces, it's never used.
console.log() prints something on the screen, but it's not a return of a value, it's just some action the function performs.
The print and return of a function's value are two separate and independent activities. In theory, output to the screen is equivalent to writing to a file (a bit special, but still a file). To grasp this concept, it's vital to have a basic understanding of operating system structure, which is critical for developers.
The output to the screen is considered a "side effect" from the perspective of the application. Actions that alter the external environment (runtime) are examples of side effects. Any network requests, file system interactions (reading and writing files), showing information on the screen or printing to a printer, and so on are examples of such actions.
One of the most common causes of problems and errors in software systems is side effects. Side-effects code is difficult to test and unreliable. At the same time, programming is meaningless without side effects. It would be impossible to get the program's output without them (write it to the database, display it on the screen, send it over the network, and so on).
Understanding the fundamentals of dealing with side effects has a major impact on programming style and program quality. This topic will be covered in depth in the following Hexlet courses.
A self-test. Is it possible to tell if a function has any side effects just by looking at its return value?
