Я часто обнаружил, что когда программист или тот, кто назначает задачу, на самом деле не понимает, как может работать решение, они вроде бы случайно добавляют материал до тех пор, пока он не будет работать.
<сильные > Примеры:
Перекрашивание окна, которое по какой-то причине не раскрашено, как хотелось бы программисту:
Invalidate();
Revalidate();
ProcessMessages();
Update();
Repaint();
Repaint();
ProcessMessages();
Repaint();
Чрезмерная настороженность:
function test1(x: boolean)
begin
select case x
true: // do something
false: // do something else
else
raise Exception.Create("Invalid value.") // just to be sure
end;
end;
function test2(x: Integer);
var
y: Integer;
begin
y = Abs(x);
if y >= 0 then
begin
// do something
end;
end;
Хотя особенно чрезмерно осторожные методы кодирования приводят к предупреждениям компилятора на большинстве языков, я действительно видел все вышеперечисленное в производственном коде!
В большинстве случаев этот вид кодирования защищается программистом и/или боссом. Причины всегда сводятся к этому ответу:
- Хорошо, это больно, если мы дважды проверяем? Лучше быть в безопасности, чем сожалеть!
- Это защитное программирование, разве они не учили этому в университете?!
К сожалению, у меня нет оснований не делать этого, хотя я по-прежнему считаю, что это действительно плохой стиль, который может иметь плохие последствия.
Есть ли серьезные факты, которые я могу представить, что этот стиль имеет плохие последствия в конце концов?
EDIT: Благодарим вас за хорошие предложения, чтобы избавиться от этого стиля. Но меня все еще интересуют причины. Я могу представить своим сотрудникам объяснение и, возможно, убедить их, , почему это плохо, и в их интересах быть параноидальным.
