Кстати, если вам интересно, что именно reduce
делает, вы всегда можете обратиться к исходному коду , где вы можете увидеть реальный код, а также хорошее повествовательное описание вкомментарии.
Но корень вашего вопроса в том, что этот код не совсем очевиден.Я могу предположить, что если вам трудно рассуждать о фрагменте кода, вы можете заменить непрозрачные сокращенные имена аргументов $0
и $1
на значимые имена, например:
let verticalMax = pipsPerRowForRank.reduce(0) { previousMax, nextArray in
max(nextArray.count, previousMax)
}
let horizontalMax = pipsPerRowForRank.reduce(0) { previousMax, nextArray in
max(nextArray.max() ?? 0, previousMax)
}
Используя имена аргументов, которые делают функциональное намерение более ясным, часто проще понять, что делает код.ИМХО, особенно при наличии нескольких аргументов, использование явных имен аргументов может сделать это более ясным.
При этом я бы, вероятно, не использовал reduce
и вместо этого делал бы что-то вроде:
let verticalMax = pipsPerRowForRank
.lazy
.map { $0.count }
.max() ?? 0
На мой взгляд, это делает предельно ясным намерение, а именно, что мы подсчитываем, сколько элементов находится в каждом подмассиве, и возвращаем максимальное количество.
Аналогично для горизонтальногоone:
let horizontalMax = pipsPerRowForRank
.lazy
.flatMap { $0 }
.max() ?? 0
Опять же, я думаю, что ясно, что мы создаем плоский массив значений, а затем получаем максимальное значение.
И в обоих случаях мыМы используем lazy
, чтобы избежать создания временных структур (в случае, если наши массивы были очень большими), но оцениваем их по мере продвижения.Это улучшает характеристики памяти подпрограммы, и полученный код становится более эффективным.Честно говоря, с таким небольшим массивом массивов lazy
не нужен, но я включу его для справки.
В итоге, цель с функциональными шаблонами - не писать код сНаименьшее количество возможных нажатий клавиш (поскольку мы могли бы написать более сжатые исполнения), но лучше написать эффективный код, цель которого максимально ясна с наименьшим количеством ошибок.Но мы всегда должны иметь возможность взглянуть на код и быстро обдумать его.Иногда, если необходима дальнейшая оптимизация, мы принимаем сознательное решение пожертвовать удобочитаемостью из соображений производительности, но здесь это не нужно.