No, V̆ajt-smytsovi ne zahaljnougyvani, tomu novatckam zhode sja i zvytcajni.

Які наслідки з цього випливають ? Мені цікаво, бо сам користую K&R стиль і ноги ще цілі.

Наприклад, те, що блок коду складніше охопити поглядом, ніж вираз. Якщо вираз уміщається в одному рядку, то блок розтягується і вертикально, і горизонтально. Якщо ми хочемо полегшити візуальний контроль парності дужок, то їх слід розмістити на якомога меншій відстані одна від одної — тобто, на одній вертикалі. Крім того, що розміщення відкриваючої дужки в значно правішій позиції збільшує цю відстань, воно ще й змушує робити горизонтальний рух очима, що збиває, коли ви пробігаєтесь уздовж лівого краю, щоб перевірити цілісність структури програми. Закономірний наслідок цього — необхідність розставляти дужки навколо блоків з одного оператора, хоча синтаксис цього не вимагає — просто інакше K&R та інші стилі з такою вадою стануть остаточно непридатними для читання. Тобто, економлячи рядок на відкриваючій дужці, ми все одно перевитрачаємось на закриваючій дужці там, де ці дужки зайві. Отже, економити такою ціною сенсу нема. Можна піти алманівським-вайтсмітсівським-ГНУшним шляхом і просто не економити. Або ще можна економити по-горстманівськи, розмістивши відкриваючу дужку в першому рядку блоку — цього разу, ціною економії буде ускладнення редагування. Тобто, краще, все ж, не економити.

Далі, чому я фанатію від вайтсміта, а не, скажімо, алмана чи горстмана — про рівень відступу дужок відносно блоку. Як і більшість тих, хто програмував на паскалі, початково я звик до чогось такого:

begin
    if ... then
        begin
            ...;
            ...;
        end;
end.

У перекладі на сішний синтаксис, це виглядатиме як стиль ГНУ. Який сам по собі надлишковий — якийсь із відступів зайвий, було б добре його позбутись — вирівнявши begin та end або до заголовку, або до підлеглого блоку. Ну і відводити цілий рядок на begin теж незовсім економно — можна причепити його до попереднього рядка (не побачити п'ять літер важче, тому тут це годиться). А ще є конструкції repeat...until, case...end, зрештою, begin...end тіла програми — на все це добре лягає логіка відступів K&R. Проте, що добре для паскалю, не дуже добре для Сі: якщо end складається з трьох літер, які разом формують масивний східець, що практично торкається до попереднього відступу, то кінцева фігурна дужка тоненька — вона просто висне в повітрі (особливо якщо після неї йде не наступний оператор у цьому блоці, а наступна закриваюча дужка). Тоді як вирівнявши дужки не до рівня заголовку, а до рівня підлеглого їм блоку, в більшості випадків отримуємо візуально цілісну конструкцію.

Ну, і вирази в круглих дужках, які прекрасно виглядають одним рядком я не розношу на багаторядковий блок, зазвичай.

Чому б це? Лямбди в пайтоні одновиразні тому, що ван Россум вважає багаторядкові лямбди поганим стилем (плутатина, що в що вкладене). Але немає жодних синтаксичних причин не компілювати щось таке:

[1,3,15].sort(key=lambda x:
    s = str(x)
    if len(s)>2:
        s = '_'+s
    return s
)

Нерозв'язних двозначностей тут немає, навіть можна не змінювати ключове слово і символ ':' - якщо після нього новий рядок, то це багаторядкова лямбда, якщо вираз - вираз.

Ще раз: ЧИННИЙ синтаксис просто забороняє багаторядкові лямбди. Якщо говорити про ТЕОРЕТИЧНІ ЗМІНИ, то доповнити правило про перенесення в дужках лямбдами не зробить суперечностей.

Приклад:

f=(lambda a:
    sorted(a)[-1])

Оброблена за сучасними правилами, така лямбда даватиме такий же результат, як і функція:

def f(a):
    return sorted(a)[-1]

Проте, якщо ми вводимо правило, що перенос рядка всередині лямбди є сигналом, щоб обробляти її вміст не як вираз, а як блок тіла функції, ця лямбда повертатиме не останній елемент відсортованого списку, а None, оскільки стане еквівалентною функції, яка нічого не повертає:

def f(a):
    sorted(a)[-1]