И еще о поддерживаемости кода

[beldmit]

Вдогонку к этой
и немного этой записям. И еще немного к боковому хвосту у Витуса.

Один из типичных приемов собеседования с программистами - показ зубодробительной конструкции на языке, на котором собирается программировать соискатель, и вопрос, что она делает. Наиболее часто мне попадался C-шный пример, когда вместо переменной объявлялась функция.

Так вот, господа. Когда вам показывают такой пример (если он выходит за пределы разумного понимания языка и знания ключевых слов или общепринятых идиом), то скорее всего - одно из двух.

1. Собеседующий пытается срезать соискателя. То есть самоутвердиться. Вам нужен такой начальник?
2. Код реально используется в проекте? Вы действительно хотите это поддерживать?

Да, и главное, без чего пп.1-2 не действуют. Понимать, что предъявленный пример собой представляет - все-таки надо. Чтобы было ясно, что объявлена таки переменная, а не функция.

Comments

[arilou]

В общих чертах согласен (и, например, с комметом Рана о том, что этивопросы надо задавать собеседующему).
Но есть тут некоторое "но".
Токость тут в том, что твой пост, как мне кажется, предполагает, что данный программист заведомо достаточно владеет языком настолько, что его мнение о "зубодробительности" конструкций заведомо верно. Т.е. того, что кто-то данными конструкциями пользуется легко, как говорится "играючи" (т.е. получает преимущества таких конструкций, не страдая от ожидаемых тобой недостатков), и что это остижимо даже без смены прошивки собственного мозга - ты уже не допускаешь? Да, конечно, ответ типа: "Я просто не считаю для себя нужным подниматься на такой уровень виртуозности, потому что за тоже время я луше освою что-то более востребованное на рынке," -- тоже принимается (и даже, сажу честно, ожидается ;) ).

[beldmit.livejournal.com]

Нет. Я имел в виду другое: конструкции, которые не очевидны с первого и со второго взгляда - неудачные конструкции. Преимущества их мне еще надо обосновывать. Хотя выигрыш я допускаю.

Я, например, долго не любил конструкцию a?b:c; И сейчас недолюбливаю. Понимать я ее прекрасно понимаю, но эта конструкция, в отличие от честного if-а, неустойчива к малым воздействиям типа добавления отладочной печати.

[arilou]

А вот мне 5-строчный if-else кажется просто лишним нагромождением кода по сравнению с a?b:c, размытием кода лишней "водой", и всё для того, чтобы, если приспичит вставить отладочную печать, сократить несколько нажатий клавишь. Увеличение же количества строк кода, занимаемое тем же количеством логики, для меня (и, насколько я знаю, не только меня) ухудшает читаемость программы, за которую ты так ратуешь. Вместо простого, краткого и ясного указания, что мы берём то или иное значение в зависимости от условия, мне надо ещё прочитывать обе ветки if-else, чтобы понять, что разница только в том, какое берётся значение, а использование его уже одинаково. И хорошо ещё, если там было просто присвоение его како-то там переменной. А если это третий из пяти параметров вызова функции? А если у нас Perl и передача параметров хэшеобразная? И потребуется изменить этот вызов. Заводить отдельную переменную (и уже её передавать в функцию) и заставлять того, кто будет читать код, выяснять, используется ли она где-то ниже? Нет, конечно, весь этот гемор и разбузание кода стоят простоты добавления отладочной печати. ;)))

Вот тебе и пример того, что "очевидное" для разных людей тоже разное бывает.

[beldmit.livejournal.com]

Так отладочная печать - это наиболее очевидный случай. Кстати, после того, как ты ее внесешь и вынесешь, ты будешь возвращать к тернарному виду?

Менее очевидный случай - таки добавление дополнительных действий.

[arilou]

Да, буду возвращать к тренарному виду. Именно потому, что вышеописанное ухудшение читаемости болезненно будет даже мне самому, когда я через несколько месяцев полезу копаться в этом коде.

Добавление действий - это уже изменение логики. Оно может потребовать изменение конструкции. В том числе на if-else. Скажем, если из одной из ветвей захочется после дополнительной проверки швырнуть исключение - в тренарном виде это может смотреться плохо. Но тут уже не однотипные действия "взять b или взять c", а нечто сложнее. Хотя вариант (пример перловый) "a? b : с? d : die 'message'" может быть вполне преемлем.

Общий смысл: не заставлять читающего программу слишком сложно думать о простых действиях.
"Присвоить переменной A значение B или C в зависимости от условия X" - это, по-моему, куда легче и стройнее, чем "Если X истинно, то присваиваем переменной A значение B, иначе присваиваем переменной A значение X".

[beldmit.livejournal.com]

Так вот, мне в среднем удобнее конструкция if-else, особенно если стиль кодирования не требует по строчке на скобку. И даже в этом случае удобнее.

Приведенный тобой вариант удобнее, если эта конструкция с гарантией не подлежит смене. Да, бывает.

[arilou]

Ну вот мы, в итоге, сошлись на противопоставлении наших "мне удобнее". Я своё удобство, кстати, чуть подробнее объяснил (т.е. это не из разряда чисто эмоционального восприятия "на вкус и цвет"). Верю, что и у тебя есть свои объяснения.

Но это всё выводит данный пример из разряда "зубодробительного кода", пригодного лишь для конкурса obfuscater'ов.

Это я просто к тому, что не стоит смешивать понятия "мне это невкусно" и "это несъедобно и вредно". ;)

[beldmit.livejournal.com]

Да, хотя в исходном посте имел в виду именно объективно плохо поддерживаемые конструкции.

Пример такой конструкции в Perl - цепочка из 3+ map/grep.

[mikeiva.livejournal.com]

Нда, встречался мне такой код в былые времена :) Просто, кратко, изящно - основная часть могучей программы была неким титаном Возрождения лет за несколько до того записана строки в две. После чего я два дня пытаюсь эти две строчки расшифровать, найти описания недокументированных системных функций языка, на котором оно написано, и вообще бурно радуюсь жизни :)

[beldmit.livejournal.com]

Что за язык? Внутренний Cache-вый?

[mikeiva.livejournal.com]

Почти. Это я тогда еще на Mumps работал. А документация была только на родственный DIAMS, и крайне скудная :) Скажем так, ей практически не пользовались.

[arilou]

Тут не надо мешать в одну кучу разные аспекты:
1) Я вовсе не говорил, что комментировать код не нужно. Нужно.
2) При использовании чего-то недокументированного (основания для того вполне могут быть) комментировать не просто нужно, а обязательно. Желательно ещё и пояснить, почему пришлось прибегнуть к недокументированному.
3) но у нас-то была речь про выбор одной из двух штатных конструкций языка ;)