Философия и практика безопасного программирования?

Question

[kk86]

Здравствуйте!


Хочу поднять качество своего кода на уровень повыше. Сейчас качество своего кода пытаюсь обеспечивать в основном с помощью TDD и включив опцию «warnings as errors» в IDE. Хочу разобраться с двумя механизмами, которых я пока не применяю.


Первый — утверждения (asserts/assertions). Они мне никогда не давались. Как только я начинал применять assert'ы, мой код становился многословным и нечитаемым, а я убеждён, что нечитаемый код нельзя считать качественным и безопасным. Про assert'ы читал в Code complete, немножко в Pragmatic programmer и по блогам нескольким. Как-то не помогло, честно говоря.


Второй механизм — code contracts. С ними история почти та же, что и с assert'ами.


По сему имею несколько вопросов:

1. Как применять все эти практики совместно, чтобы повысить качество кода, а не понизить его неумелым применением практик? (Иными словами, интересует ваше мнение.)

2. Есть ли какие-то статьи именно на тему совместного применения практик? (Т.е. интересует мнение признанных авторитетов.)

3. Есть ли какая-то специфика применения практик, если они используются при разработке библиотек классов, а не приложения?

Comments

[kk86]

Спасибо всем, кто уже ответил на вопрос. Судя по тому, какие разные суждения выражены, я понимаю, что тема, действительно, поднята не очень простая. В связи с этим перечитаю, что говорится в code complete, а также буду рад узнать ещё какие-либо авторитетные источники.

Answer 1

[Анатолий]

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

Comments

[kk86]

Да, Вы говорите именно о тех assert'ах. В .NET'ах это Debug.Assert() или Trace.Assert(). В C++, кажется, просто функция assert из assert.h.

Я просто не понимаю, когда их использовать. Как только пробую их применять, это сводится к втыканию их всюду. Код становится кашей. Кроме того, я полагаю, что ряд assert'ов можно описать как контракт. Ну и так далее. Хотел бы услышать что-то развёрнутое. Так как нет у меня гуру/наставника в прямом доступе, а проблему я ощущаю не первый день…

[Анатолий]

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

[kk86]

Ну, Debug.Assert() вообще автомагически отключается в дотнетах:

By default, the Debug.Assert method works only in debug builds. Use the Trace.Assert method if you want to do assertions in release builds.

Так что я особо насчёт этого не переживаю.

Пугает каша в коде. Наверняка я просто неправильно использую. В общем, ожидаю ещё комментариев. В идеале увидеть код из какого-нибудь не очень маленького проекта, где assert'ы гармонично вписаны.

[MikhailEdoshin]

Насчет посмотреть — в коде питона используются assert'ы. В целом там довольно неплохой код (на C).

Answer 2

[Stac]

2х23 + кронштейн от Ergotron или другого производителя, который решит задачу взаимного расположения мониторов.

Comments

[Stac]

Извиняйте, не туда запостил комментарий.

[kk86]

Всё ок, я даже понял, куда Вы постили. :)

Answer 3

[Stac]

Если не ошибаюсь, assert'ы как-то обсуждали в Радио-Т (вместе с «эксепшнами» или отдельно).

Допустим, что именно так и было… :) Потому что мне запомнилось, что это зло.

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

Comments

[Анатолий]

Ассерты — не отлов ошибки, ассерты — проверка на «правильность», и они отнюдь не зло, потому как Вы наверняка не можете знать правильно ли работает программа, а ассерты как раз и наверняка это покажут без лишних телодвижений и лишних проблем.

Answer 4

[Владимир Дубровин]

assert'ы следует использовать в следующем случае:
Есть некий (громоздкий) кусок кода, у которого есть ожидаемое поведение, но ввиду каких-то обстоятельств (недостаточно документации, запутанность, недостаток опыта, недостаточное тестирование и т.п.) Вы можете быть в нем уверены только на 99.99%. Это зло, но иногда так бывает, особенно в начале разработки. Есть критическая операция, перед которой используется этот код и для которой надо быть уверенным на 100,01% что код сработал так, как ожидается, а если он сработал не так — то лучше остановить приложение, т.к. неправильное срабатывание может означать, например, что где-то повреждена память. Есть способ проверить, что код сработал так, как надо. Вот в той ситуации, когда уровень доверия к коду ниже требуемого для критической операции — перед критической операцией ставится ассерт на результат срабатывания кода. Если вам приходится ставить слишком много ассертов — то это значит, что Вы пишете заведомо плохой код.

Answer 5

[gribozavr]

assert'ом проверяются те утверждения, которые должны всегда выполняться. Если они не выполняются, то у вас в коде баг. В этом их отличие от, например, исключений. Если у вас функция возведения в квадрат вернула отрицательное число, какое исключение бросить? BadSquareImplementationException? глупость. А вот проверять что open() не вернул отрицательный файловый дескриптор нельзя, так как это вполне нормальная ситуация и бага в коде нигде нет (даже если вы в предыдущей строке этот файл создали, его кто-то мог уже успеть удалить).

Comments

[Владимир Дубровин]

assert(seteuid(getuid( )) == 0);

[gribozavr]

Нельзя так. assert в случае NDEBUG компилируется в пустой оператор и код не выполняется. Правильно:
int ret = seteuid(getuid());
assert(ret == 0);

[Владимир Дубровин]

ОК, да, но речь немного не об этом.

Это классический пример, когда assert(), традиционно используемый для перестраховки, реально сработал. Довольно долго было принято считать что seteuid(getuid( )) работает всегда, а потому ситуацию обычно не обрабатывали никак. Но таки «перестраховщики» вставляли под это дело assert() и в учебниках обычно рекомендовали. В результате, когда вылезла вполне практичная атака, при которой исчерпавались ulimit'ы юзера, а потом вызывалось suid-приложение, в результате seteuid не срабатывал из-за превышения ulimit'ов — перестраховщики оказались в плюсе. А сейчас уже — да, ситуацию принято отдельно обрабатывать, т.к. она документирована и использование в ней assert() это уже дурной тон.

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

[Владимир Дубровин]

А, кстати, «Если у вас функция возведения в квадрат вернула отрицательное число, какое исключение бросить» — ArgumentValueTooLarge я полагаю :)

[gribozavr]

Согласен, ваш пример намного более реалистичен, чем мой.