Защитные методы кодирования

С тех пор как я впервые написал

if ($a = 5) {
   #  do something with $a, e.g.
   print "$a";
}

и прошел обычную загадочную сессию

почему результат всегда истинен
почему $a всегда 5

пока я не понял, я назначил от 5 до $a вместо сравнения.

Итак, я решил написать такое условие выше, как

 if (5 == $a)

Другими словами:

всегда располагайте постоянное значение в левой части оператора сравнения, что приводит к ошибке компиляции, если вы забудете добавить второй знак "=".

Я обычно называю это защитным кодированием и склонен считать его двоюродным братом в защитном программировании, но не в алгоритмическом масштабе, а ключевое слово по ключевому слову.

Какие защитные методы кодирования вы разработали?

Одна неделя спустя:

Большое "спасибо" всем, кто ответил или может добавить еще один ответ в будущем.

К сожалению (вернее, к счастью!) нет единого правильного ответа. Для этого мой вопрос заключался в широком вопросе, который больше интересовался мнениями или опытом, а не фактами.

Ответ 1

Всегда используйте фигурные скобки:

if(boolean)
    oneliner();
nextLineOfCode();

- это не то же самое, что:

if(boolean)
{
    oneliner();
}
nextLineOfCode();

Если oneliner() является #defined функцией, и она не определена, то ваша следующая строка кода внезапно становится объектом if(). То же самое относится к циклам и т.д. С помощью фигурных скобок следующий фрагмент кода никогда не будет непреднамеренно становиться зависимым от if/для и т.д.

Ответ 2

В первую тройку защитных методов кодирования я использую

модульное тестирование
модульное тестирование
модульное тестирование

Нет лучшей защиты качества вашего кода, чем хороший unit test, чтобы поддержать вас.

Ответ 3

Это простой и очевидный, но я НИКОГДА НИКОГДА НИКОГДА не повторяю одну и ту же строчную константу дважды в своем коде, потому что я ЗНАЮ, что если я это сделаю, я буду неправильно называть одного из них:) Используйте константы, люди!

Ответ 4

Всегда помещайте фигурные скобки после if/for/while... даже если после этого есть только один оператор. BTW D. Crockford тоже думает: Необходимые блоки

Ответ 5

При сравнении строки с константой напишите

if ("blah".equals(value)){}

вместо

if (value.equals("blah")){}

чтобы предотвратить исключение NullPointerException. Но это единственный раз, когда я использую предложенный стиль кодирования (причина "if (a = 1)..." невозможна в Java).

Ответ 6

Одна из вещей, которые я всегда стараюсь запомнить, когда я нахожусь в мире Javascript, - всегда начинать возвращаемое значение функции в той же строке, что и ключевое слово возврата.

function one(){
    return {
        result:"result"
    };
}

function two(){
    return 
    {
        result:"result"
    };
}

Эти 2 функции не возвратят одно и то же значение. Первая функция вернет объект с результатом свойства, установленным в "результат". Вторая функция вернет undefined. Это действительно простая ошибка, и это происходит из-за чрезмерной усердной стратегии вставки Semi-Colon Javascript. Полуколоны полуфабрикаты в Javascript, и из-за этого механизм Javascript добавит полукруг, где он думает, что это должно быть. Поскольку return на самом деле является допустимым оператором, то после оператора return будет вставлена точка с запятой, а остальная часть функции будет по существу игнорироваться.

Ответ 7

Всегда инициализировать переменные
Используйте const везде, где я могу (без использования mutable)
Избегать простого динамического распределения памяти или других ресурсов.
Всегда используйте фигурные скобки
Кодовые примеры использования и тесты для любого класса перед реализацией кодирования
Включите как можно больше полезных предупреждений (-Wall -Wextra -ansi -pedantic -Werror как минимум)
Используйте простейший инструмент, который решает проблему (в моей текущей среде, bash → grep → awk → Python → С++).

Ответ 8

Лично мне не нравится этот защитный стиль, он делает код жестким для чтения.

Уровень предупреждения компилятора VC 4 обнаружит эту (возможную) ошибку.
"предупреждение C4706: назначение в условном выражении"

Вы можете включить только это конкретное предупреждение компилятора на любом уровне:

#pragma warning(3,4706)

Ответ 9

Из моего блога:

Подумайте положительно и верните ранний плюс избегайте глубокого гнездования. Вместо

if (значение!= null) { ... сделать что-то ценное... } вернуться

записи

if (value == null) { вернуть } ... сделать что-то со значением...
Избегайте "строковых констант" (т.е. один и тот же текст в кавычках в нескольких местах). Всегда определяйте реальную константу (с именем и необязательным комментарием, что это значит) и используйте это.

Ответ 10

Я прекратил использовать языки, где вы можете делать

if a = 5: print a

Это спасло мне массу головных болей =).

В более серьезной ноте... Я теперь всегда пишу фигурные скобки сразу после того, как пишу петли if и for, а затем их заполняю потом. Это гарантирует, что мои скобки всегда выровнены.

Ответ 11

Возврат копии изменяемого объекта, то есть копии массива, а не самого изменяемого объекта.

Ответ 12

Избегайте ненужного теста. Пример

if (bool = true)
Указатель проверяет, есть ли (указатель)

EDIT: if (pointer) не читается, поэтому в настоящее время я предпочитаю, чтобы (NULL!= указатель)

Ответ 13

Пара вещей:

Да, 1-строчные блоки. Используйте брекеты... черт, самая хорошая IDE сделает их для вас.
Прокомментируйте свой код после его написания или перечитайте свои комментарии, если вы это сделали раньше времени. Убедитесь, что ваш код по-прежнему делает то, что говорят комментарии.
Тестирование модулей - отличный резерв для повторного чтения вашего кода.
Всегда регистрируйте исключение... или НИКОГДА не забудьте исключение, не сказав об этом, по крайней мере, в отладке.

Ответ 14

Несколько предложений для встроенного программирования C в статье Правила для Оборонительного программирования C от embedded.com.

Ответ 15

Установленный Resharper;) Тогда мне не нужно писать "5 == a", чтобы получить предупреждение, если я сделал что-то не так:)