The code under Set default objects with Object.assign also break the rule that Avoid Side Effects (part 2) establish.

@johachi You're correct that the code under the Good section of Set default objects with Object.assign does mutate an object, but because it mutates an object created within the function, there's no possibility that any other part of the program could be holding a reference to it. Thus, it doesn't break the rule that Avoid Side Effects (part 2) establishes.

@noelzubin It sounds like your are using "side effect" to mean the opposite of something like "main effect" - i.e. the stated purpose of a function. A function that doesn't do what it says it does has a Bad Name and one that does more than it says it does doesn't Do Only One Thing. Both are bad, but neither is what I understand Avoid Side Effects (part 2) to be about.

Here Ryan is using the concept of side effects as used in functional programming to mean something like affecting anything outside the scope of a function or taking in data from a source other than the function parameters. Common examples are I/O operations like displaying things to a screen, sending data over a network, accessing a database, reading keyboard or mouse input, etc. Modifying the properties of an object that was passed as a parameter to a function would be another example. (That change would be visible outside the scope of the function.)

In general, modern software wisdom seems to be that side effects should be avoided - as stated in Avoid Side Effects (part 2) - but you're also right that sometimes they're necessary or expedient. What program doesn't accept input from the user and display it in some way?

I don't have Clean Code nor do I have a perfect memory (I read it a while ago) so I can't comment on how close to it this idea is. However, I'm guessing Bob would approve of the concept even if some of the examples in his book don't follow it themselves.