Comments 8
Код должен быть выразительным.
Простой код должен выглядеть просто.
Сложный код — достаточно сложным.
Грязный хак должен выглядеть как грязный хак.
Код, который легко сломать рефакторингом, после кривого рефакторинга должен выглядеть сломанным (а в идеале — ещё выдавать ошибку при компиляции или при запуске программы).
Сложнее всего написать простой, красивый и рабочий код одновременно... К сожалению, в вузах про первые два пункта не вспоминают вообще никогда...
Мысль нужно уметь удержать в голове. Но это трудно - большинство не удержит в голове больше двух мыслей, а многие и с одной-то не справятся. Поэтому люди придумали текст. Глаза быстро перемещаются по тексту и немощные мозги тут же вспоминают давно забытую мысль.
Что это значит? Это значит, что в тексте программы мы должны видеть все относящиеся к делу мысли. Если нужно мысли там нет - всё, примитивная нейросеть страдает от невозможности понять, зачем нужен весь этот код. Поэтому обладатели слабеньких нейросетей постоянно танцуют с бубном вокруг "красоты" кода. Они не понимают, зачем нужна "красота", но на уровне инстинктов чувствуют - без неё не выходит приличный код. Поэтому они требуют от окружающих "красоты".
Но поможем немощным мозгам, дадим наконец определение этой таинственной субстанции.
Красота кода, это когда пробежав глазами ограниченную область на экране, обладатели слабых нейросетей вспомнят набор мыслей, соответствующих смыслу изучаемого кода.
Ну и далее всё очевидно - у одного обладателя нейросеть заточена исключительно под пробелы между знаком равно и остальными частями выражения, у другого - под расположение фигурной скобки на той же строке, что и определение типа блока кода. Отсюда все эти вальсы с линтерами и стилями кода, без которых, почему-то, у некоторых течёт кровь из глаз (по их собственным заверениям).
Но если же подняться чуть выше примитивизации стилей уровня "пробел не там стоит" (то есть адаптации под требования ну уж совсем примитивных нейросетей), то можно, наконец, обнаружить - нам нужен смысл кода. Да, не пробелы и скобочки, а смысл важнее всего.
Если смысл можно охватить одним взглядом - вот вам и счастье. Если охватить нельзя - это плохой код. Логично?
Как охватить одним взглядом много смысла? Есть два направления - выразительность кода и его компактность. Тема текста статьи - про второе.
Да, следует признать, что компактный код сначала нужно научиться понимать, то есть натренировать слабую нейросеть на относительно сложную для неё операцию. Это требует напряжения. Поэтому большинство обладателей сильно против. И протестуют, когда видят "мудрёный" код. А поскольку таких нейросетей большинство - код в среднем "не мудрёный", но и смысла почти не несущий. То есть ни "красоты" нет, ни мудрёности. Мне кажется, что чего-то здесь всё-таки не хватает. Но чего?
Смысла.
Думать - это работа, а работа - это энергозатраты. И нейросеть, даже "сильная", обрабатывает и выдает результат не из сферического вакуума, а задействуя процессорное время. И энергию. Человек (да и не только он, в принципе все живые существа) исторически/эволюционно заточен на экономию и своего "процессорного времени", и энергии, так как в предыдущие тысячелетия этого требовало банальное физическое выживание. И хотя в наше время свободного "процессорного времени" достаточно много, а энергия дешева и легко доступна, на уровне своей самой базовой прошивки человек стремится ни процессор свой не перегружать, ни энергию попусту не тратить. И простой и понятный код, не требующий напряжения, этому человеку легок и приятен ;)
Так то Вы, конечно, правы, но я вот не увидел в статье вашего решения с картинки, понятного без наличия в коммментариях исходного условия задачи. И не увижу. С другой стороны, как на постановку этой задачи посмотришь, так и алгоритм решения сразу становится очевидным, и даже подсказка в решении становится видна (переворот "елочки"). Единственно, что я бы написал zip(a[:-1], a[1:], b).
А в чем проблема с простым кодом? Почему было высказано мнение, что это плохо и нужна документация?
Мудреный код — пожалуй, худший выбор