о хитром коде (программистское)

[avva]

Интересная блог-запись, подытоживающая фиаско с ssh-ключами в Дебиан.

Кроме того, что там подробно все объясняется, есть еще список советов разработчикам. Из них самый важный, по-моему, и тот, который на практике чаще всего игнорируют --

Don't write clever code.

Год или два назад у меня была подробная запись о том, что я не вполне уверен, что сейчас я лучший программист, чем был, скажем, 10 или 13 лет назад. Не уверен в том, что вообще есть накопление программистского мастерства и умения. Но вот это правило - пример чего-то, что я не знал и не понимал как следует десять и даже пять лет назад, по-моему. Если есть что-то, что я усвоил за последние несколько лет в своей профессии и что можно назвать фундаментально важным, то это оно - последовательное и принципиальное понимание и использование этого правила.

Comments

[amigofriend.livejournal.com]

Причём на русском языке здесь наиболее уместно воспользоваться словом "хитрожопый".

[itman.livejournal.com]

Полностью согласен. Конечно, по возможности "keep it simple stupid", но простота - это тоже компонент умного кода. Правильнее было бы написать: don't write obfuscated code... Да, и тода перевод хитржопый или хитровыебанный будет вполне уместен.

[avva.livejournal.com]

clever - это более широкая, в моем понимании, категория, чем "хитрожопый".

[amigofriend.livejournal.com]

Да, но ведь здесь оно употреблено не во всём спектре своих смыслов.

[itman.livejournal.com]

Да, правильно, нужно давать рекомндации а-ля:
write stupid code

[ospf-ripe.livejournal.com]

лучше уж
code with clear logic

[cema.livejournal.com]

+1

[codedot.livejournal.com]

В первой главе книги Кернигана и Пайка "Практика программирования" авторы сравнивают хороший стиль программирования с хорошим стилем написания английских текстов:

http://www.ozon.ru/context/detail/id/1927500/

[panikowsky.livejournal.com]

Золотые слова!!!

[slobin.livejournal.com]

К сожалению, любой стандартный сегодня приём когда-то был clever code.

... Using the Internet still looked and felt a lot like work ...

[dimrub.livejournal.com]

> Don't write clever code.

And if you do - document!

[cema.livejournal.com]

And if you do - document!

Cleverly!

[lee-bey.livejournal.com]

Очень странно...ИМХО, если судить по прочитанному, то наибольшая вина обоих сторон была не сколько в том, что кто-то написал излишне хитрый код, сколько в в том, что они плохо этот код обсудили между собой.
И вот тут-то действительно "засада"...

[everkill.livejournal.com]

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

[zhenyach.livejournal.com]

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

[cema.livejournal.com]

Через год он уже не такой юный!

[(Anonymous)]

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

[soysoys.livejournal.com]

да-да, не фиг умничать при программировании

[msh.livejournal.com]

Мне непонятна в чем вина программиста OpenSSL

Есть очевидная проблема с Debian - уровень maintainers очень разный и часто, прямо скажем, весьма низкий. Ну не самое интересное занятие-то перепаковывать чужой софт, там обычно молодые сисадмины с избытком свободного времени

Maintainer полез копаться в криптографии не понимая что к чему и сломал. Никто больше этого не сделал, потому что при мало-мальски существующем контроле этот код не достался бы человеку с такой квалификацией и изменение кода "чтобы заткнуть valgrind" никогда никто бы не одобрил

В принципе, это частая проблема с open source который именно пишется толпой, а не строго контролируется, как линуксный кернел, и не пишется на самом деле какой-то конторой с существующим development process

А код нормальный, надо как раз стараться писать clever code если выходит, тупой и так есть кому написать

[avva.livejournal.com]

Его код был написан неряшливо, без какой-либо причины использовал неинициализированную память (энтропии это не добавляет, по крайней мере качественной), более важные vs менее важные источники энтропии не было документированы в коде.

[msh.livejournal.com]

Я посмотрел код - ну да, написан он малопонятно, почему буфер не инициализирован не написано (сколько это дает энтропии - я не знаю, может и не дает и смысла не имеет). Если бы дебиановец инициализировал бы этот буфер в rand_unix, то это можно было бы списать на непонятность кода, но он-то сломал RAND_add() которая не просто документирована, но даже имеет man page

[pargentum.livejournal.com]

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

[msh.livejournal.com]

Ответ "там непропорциональное количество нулей" не отвечает на вопрос "сколько там энтропии". Что энтропии там меньше чем в полностью случайной последовательности - это очевидно. И, кстати, нет, там может быть что угодно в зависимости от того как мы его получаем. Например, мы генерируем ключ всегда в одной и той же точке программы и получаем от аллокатора (или со стека) всегда один и тот же кусок только что освобожденный кем-то другим, содержащий одно и тоже.

Но это все равно moot point, потому что дебиановец не смог понять не почему данные не инициализируют, а как работает RAND_add и убрал из нее главную строчку - где энтропию в дайджест добавляют.

[pargentum.livejournal.com]

Все-таки использовать неинициализированную память как источник энтропии - ... Если бы у меня в проекте такое написали, я бы точно постарался по башке настучать. И тому, кто написал, и тому, кто закоммитил.

То есть хороши, конечно, оба - и openssl разработчик, и дебиановский майнтайнер. Но майнтайнера хотя бы можно по человечески понять - я бы тоже не ожидал обнаружить в коде уважаемой библиотеки такую фигню, а если бы обнаружил, то тоже решил бы, что это какая-то очень эзотерическая вещь для какого-нибудь очень эзотерического сочетания ОС, компилятора и требований, которую можно без большого вреда задизаблить. А со стороны OpenSSL это было чистое и ничем не оправдываемое вредительство.

[mirritil.livejournal.com]

самая главная вина в их раздолбайских ответах в списке рассылки, и одобрение изменения.

[digest.livejournal.com]

Еще через несколько лет ты поймешь, что и это правило неважно :), и это будет действительно фундаментально. На любой simple код найдется еще более глупый мэйнтейнер. "Работает, сынок? Не трогай!"(с) -- вот квинтэссенция программистского мастерства :-)

ПыСы: это ж каким смелым надо быть, чтобы лезть править что-то в коде openssl...

[stas]

У меня до сих пор где-то лежит баг в комбинации Apache+mod_ssl, который заставляет все это валиться с segfault при определенной последовательности действий. Кажется, до сих пор за три года не исправили, а я как раз не смелый :)

[a2is.livejournal.com]

> Don't write clever code.

Есть более древний принцип - KISS (Keep it simple, stupid!)
Как говорил мой бывший начальник: "Будьте проще, и люди к вам потянутся"

[rustex.livejournal.com]

Ну, я знаю нескольких человек, которые пишут именно "хитрожопый" © код. Из соображений job secure :)

[vodianoj.livejournal.com]

Судя по тому, что под словом "Clever code" ты понимаешь "плохой код", предложение становится становится тавтологией. Но я всё-таки сделаю предположение, что ты имел ввиду функции, которые легко прочитать человеку, который их захочет потом исправить или изменить их функциональность.

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

[avva.livejournal.com]

Под clever code я понимаю примерно то, что ты предполагаешь - не знаю, отчего ты решил, что я имею в виду "плохой код".

В чём проблема написать короткую "умную" изящную функцию с чётко определённым поведением? Такие функции обычно сложнее понять, зато гораздо легче доказать их правильность (соответсвие спецификации).

Доказательство правильности в реальном мире никогда не бывает полным, во всех случаях убедительным, да на самом деле его почти никогда и не бывает вообще. Как ты себе представляешь доказательство правильности функции "набрать энтропии из нескольких источников и добавить ее в общий pool"?

Кроме того, дело не только в функциях, и clever code проявляется не только на уровне функций. Я вчера просматривал код, который мне прислали на ревью, и он был clever code потому, что вводил умную, эффективную систему отношений между тремя разными классами - кто кого держит, кто кого освобождает, в некоторых случаях это закручивалось цепочкой, и возможность порочного круга элегантно разрешалась специальными умными проверками в нескольких разных методах. Эти проверки были корректными: после некоторых размышлений я убедился в том, что порочного круга или висящего указателя быть не может. Я предложил автору кода переписать всю систему отношений, сделав ее намного более простой, понятной, и традиционно-иерархичной.

[vodianoj.livejournal.com]

Может использовать обериутовский термин: заумный код?

Я на 100% согласен с приведённым тобой примером.

Я имел ввиду рекурсивные функции, для которых легко доказывается (ну или точнее показывается) их верность, зато понять их код, просто просматривая строчка за строчкой обычно менее тривиально.

[gogabr.livejournal.com]

Russ Cox вообще пишет хорошо.

о памяти и мышление в старости и юности

[lykac.livejournal.com]

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

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

В частном случае, полиглоту, который знает 15 языков, освоить 16-тый несомненно проще, чем первый.