An operation, function or expression is said to have a Side Effect if it modifies some state variable value(s) outside its local environment/scope, that is to say it has an observable effect besides returning a value (the main effect) to the invoker of the operation.
Example side effects include modifying a non-local variable, modifying a static local variable, modifying a mutable argument passed by reference, performing I/O or calling other side-effect functions.
In the presence of side effects, a program's behaviour my depend on the order of evaluation. Understanding and debugging a function with side effects requires knowledge about the context and its possible histories
The degree of which side effects are used depends on the programming paradigm.
-
Imperative programming is commonly used to produce side effects, to update a system's state.
-
Declarative programming is commonly used to report on the state of system, without side effects.
-
Functional programming rarely uses side effects. This makes it easier to do formal verifications of a program. Some functional languages do not restrict side effect, but it is customary for programmers to avoid them.
-
Assembly language programmers must be aware of hidden side effects (instructions that modify parts of the processor state which are not mentioned in the instruction's mnemonic). A classic example is an arithmetic instruction that implicitly modifies condition codes while it explicitly modifies a register.
Side effects caused by the time taken for an operation to execuite are usually ignored when discussing side effects and referential transparency. There are some cases, such as hardware timing or testing, where operations are inserted specifically for their temporal side effects e.g. sleep(5000). These instructions do not change state other than taking an amount of time to complete.