[taeric]

The problem with self documenting code is that it doesn't help justify all of the parts into the whole. This is particularly troublesome in code where a refactor effectively isolated entire sections of the code, but the person that did the refactor didn't realize it, and now you have code that exists only for the sake of existing tests.

[t0suj4]

I interpret self documenting as writing the what in the code and writing comments about the why. While minimizing the places where you need to explain your code.

My role of thumb is that if it's not obvious why that particular line is there and removing it would break functionality, add a comment.

[taeric]

I typically see "self documenting code" refer to code where function and variable names indicate the code without added comments.

Think:

    function square(x) ...

Versus

    function f(a) ...

Often includes all functions as named things, with little to no lambda usage, since names are seen as for the programmer, not for the computer.

[t0suj4]

Pushing for an extreme can be counterproductive. For example completely avoiding lambda may bring the equivalent of constant abuse.

Compare

  list.map(v => v+2)

To

  list.map(add2)

In addition to other problems with functions, you now have a potential for combinatorial explosion doing it this way.

[taeric]

Completely agreed. Though, I suspect cases like that are less common. Small adjustments by constants aren't something I do often, at least. (That is, this is a bit of a straw man.)