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

[beldmit]

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

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

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

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

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

Comments

[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.