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

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

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

Ответ 15

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