Несколько мыслей о выразительности
1. Симметрия (и ритм как переносная симметрия), да и всё прямое и ровненькое, радуют глаз и восхищают во всём, кроме программного кода. Повторяемость конструкций вызывает подозрение, что какие-то из них лишние и надо использовать одну за всех.
2. Выразительность в программировании делится на "ясно, зачем это" и "ясно, как". Крайний пример второго - язык ассемблера, где каждая строчка делает понятно что, но в реальной программе теряется в дебрях структуры (а всё выглядит ровненько-ровненько, см. п.1). Крайний пример первого - почему-то тестовые библиотеки, такие, как mockito и scalatest: конструции вида when(a.isCalled()).thenReturn(whatIsNeeded) выглядят почти как связный английский текст, но поди сразу пойми, какие методы каких классов тут вызываются и какие объекты выдают. К счастью, взаимоисключение неабсолютное, языки развиваются с улучшением обеих выразительностей. Но какой код легче переиспользовать? Если первый раз видишь и нет описаний, то легче выразительный "как": очень часто бывает, что скопируешь вроде как понятный выразительный "зачем" кусок, слегка переделаешь для новой задачи и потом долго тупишь - а почему он не работает. А вообще - конечно, он лучше.
3. Комментарии нужны не столько для того, чтобы описывать код (он сам должен быть выразительным), скорее они описывают, почему с кодом чего-то не сделано по-другому.
2. Выразительность в программировании делится на "ясно, зачем это" и "ясно, как". Крайний пример второго - язык ассемблера, где каждая строчка делает понятно что, но в реальной программе теряется в дебрях структуры (а всё выглядит ровненько-ровненько, см. п.1). Крайний пример первого - почему-то тестовые библиотеки, такие, как mockito и scalatest: конструции вида when(a.isCalled()).thenReturn(whatIsNeeded) выглядят почти как связный английский текст, но поди сразу пойми, какие методы каких классов тут вызываются и какие объекты выдают. К счастью, взаимоисключение неабсолютное, языки развиваются с улучшением обеих выразительностей. Но какой код легче переиспользовать? Если первый раз видишь и нет описаний, то легче выразительный "как": очень часто бывает, что скопируешь вроде как понятный выразительный "зачем" кусок, слегка переделаешь для новой задачи и потом долго тупишь - а почему он не работает. А вообще - конечно, он лучше.
3. Комментарии нужны не столько для того, чтобы описывать код (он сам должен быть выразительным), скорее они описывают, почему с кодом чего-то не сделано по-другому.