What to sacrifice, DRY or self-documenting code?

Question

PHP

Goodnight.
There is an application, recently finished refactoring. There are many classes, namespaces and even more functions, including single-line ones. I tried to make the code self-documenting, so you can often see functions like:

private function is_map_have_passed_param($map, $param) {
    return is_array($map) && isset($map[$param]);
}

private function get_array_of_default_values_from($string) {
    return explode('-', $string);
}

The problem is that such atomic functions have proliferated across all classes, and in some places violate DRY - there are even almost identical functions, but named differently for the sake of self-documentation. You can't just take and replace the same get_array_of_default_values_from back - it will not be clear what happens from splitting the string. A commentary is required, and, as you know, the best commentary is the one that we managed to do without.
That's why I came up with the idea of ​​using traits and putting all atomic functions into a trait. It will be 100% DRY, but self-documentation will most likely suffer: I will have to combine several functions that do the same thing, but have different names, into one universal one.
What is the best way to donate? Is it possible to sit on two chairs at once?

Answer 1

For this, comments have always been used . Until one day someone created a sect of self-documenters who worship the god of self-documentation and sacrifice everything to him, down to the fundamental principles of programming (DRY).

$x = is_array($map) && isset($map[$param]) /* is map have passed param */
$y = explode('-', $defaults) /* get defaults int range */

Speaking function names are definitely a good thing.
But wrapping lines in functions instead of simply signing comments to them - this already borders on fanaticism.

Answer 2

if (!empty($map[$param])) { // здесь комментарий для тех, кто не знает что такое empty()
}

$default_values = explode('-', $string);(There is no need for a comment here, this line is already well "documented" thanks to the variable name.)
In general, it is better to write comments according to business logic, such as
/**
* this method paints kittens pink
*/
boo-boo-boo
boo-boo boo
...
10 lines of code
And introducing single-line functions for the sake of a comment is a strange idea.