Today I fell into a trap when using a function that had a side effect – it unexpectedly changed an input parameter; causing a later statement to fail. Debugging took an age!
For example, consider the following function:
string StringReplace(string haystack, string needle)
If this function is side-effect free, we can use it without fear like this:
string menagerie = "cat,dog,bee,llama"; string catFreeMenagerie = StringReplace(menagerie, "cat"); string beeFreeMengerie = StringReplace(menagerie, "eric"); Assert.AreEqual(",dog,fish,llama", catFreeMenagerie); Assert.AreEqual("cat,dog,,llama", beeFreeMengerie);
However, if StringReplace() had the side effect of also changing the passed in haystack, then the second Assert would fail, because the first StringReplace has the unexpected side effect of changing one of its arguments.
Evans in the DDD book has quite a bit to say about this; arguing that having side effect free functions goes a long way towards making a supple design
Side effect free functions also make testing & refactoring easier (less state to worry about etc)
Remember, a function that changes its parameters is rude, and should not be trusted!