[Закрываются] любимые (умные) лучшие практики безопасного программирования

Едва умный, но достойная практика, возможно. В C/C++:

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

int MyIntReturningFuction(char *importantPointer)
{
    int intToReturn = FAILURE;
    if (NULL == importantPointer)
    {
        return FAILURE;
    }
    // Do code that will set intToReturn to SUCCESS (or not).
    return intToReturn;
}

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

я также нашел, что наличие очень простых правил как это делает меня намного более последовательным кодером. Я никогда не нарушаю это правило, в частности, поэтому иногда я должен думать об альтернативных способах обработать вещи (такие как чистка памяти и такого). До сих пор это всегда было к лучшему.

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

, Например, у Вас есть этот вид цикла:

while(1)
{
  // some codes here

  if(keypress == escape_key || keypress == alt_f4_key 
     || keypress == ctrl_w_key || keypress == ctrl_q_key) break;

  // some codes here
}

, Если Вы хотите поместить условие в заголовок цикла, вместо того, чтобы бороться против языка за то, что он не имел до конструкция, просто копируют условие дословно и помещают восклицательный знак:

while(! (keypress == escape_key || keypress == alt_f4_key 
     || keypress == ctrl_w_key || keypress == ctrl_q_key) )
{ 
    // some codes here
}

существует не до конструкции на языках C-derived, поэтому просто сделайте вышеупомянутое, иначе сделайте это (возможный в C/C++, используйте #define ;-)

until(keypress == escape_key || keypress == alt_f4_key 
     || keypress == ctrl_w_key || keypress == ctrl_q_key)
{ 
    // some codes here
}

Всегда компилируйте с наивысшим уровнем предупреждений и обрабатывайте предупреждения как ошибки (прерыватели сборки).

Даже если код «правильный», устраните причину предупреждения, не отключая предупреждение, если все возможно. Например, ваш компилятор C ++ может выдать предупреждение о допустимом коде вроде этого:

while (ch = GetNextChar()) { ... }

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

while ((ch = GetNextChar()) != 0) { ... }

Чуть более явное выражение не только заглушает предупреждение, но также помогает следующему программисту, который должен понять код.

Если вы ДОЛЖНЫ отключите предупреждение, используйте в коде #pragma , чтобы вы могли (1) ограничить диапазон кода, для которого предупреждение отключено, и (2) использовать комментарии, чтобы объяснить, почему предупреждение должно быть отключено.

Итак, кто из нас случайно не заблокировал Visual Studio на некоторое время при написании рекурсивного метода?

  int DoSomething(int value)  // stupid example for illustrative purposes
  {
      if (value < 0)
          return value;
      value++;  // oops
      return DoSomething(value);
  }

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

  int DoSomething(int value)
  {
>>    if (new StackTrace().FrameCount > 1000)  // some appropriately large number
>>        Debug.Fail("Stack overflow headed your way.");

      if (value < 0)
          // some buggy code that never fires
      return DoSomething(value);
  }

Это может показаться медленным, но на практике проверка FrameCount выполняется довольно быстро (менее секунды на моем ПК) . Вы можете исключить этот отказоустойчивый режим (или, может быть, просто закомментировать его, но оставить для более поздней отладки) после того, как убедитесь, что метод работает правильно.

Языковая независимость: проблема: отчетность и работа с частями целого. Всякий раз, когда отображаются расчеты и проценты, я всегда сохраняю промежуточную сумму, и для последней записи ее значение вычисляется не как остальные, а вычитается из 100,00 промежуточной суммы. Таким образом, если какая-то заинтересованная сторона решит сложить все проценты компонентов, они добавят ровно к 100,00