Я часто обнаруживал, что, когда программист или тот, кто назначает задачу, не понимает, как может работать решение, они как бы произвольно добавляют материал, пока он не работает.
Примеры:
Перерисовка окна, которое по какой-то причине не нарисовано так, как хотелось бы программисту:
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;
Хотя особенно осторожные методы кодирования приводят к предупреждению компилятора на большинстве языков, на самом деле я видел все вышеперечисленное в рабочем коде!
В большинстве случаев этот вид кодирования защищается программистом и / или начальником. Причины всегда сводятся к этому ответу:
- Ну, больно, если мы перепроверим? Лучше быть в безопасности, чем потом сожалеть!
- Это защитное программирование, разве они не учили этому в университете?!
К сожалению, у меня нет веских причин не делать этого, хотя я все еще считаю, что это действительно очень плохой стиль, который может иметь плохие последствия.
Могу ли я представить какие-либо неопровержимые факты о том, что этот стиль в конечном итоге имеет плохие последствия?
РЕДАКТИРОВАТЬ: Спасибо за хорошие предложения, чтобы избавиться от этого стиля. Но я все еще интересуюсь причинами , которые я могу представить своим коллегам, чтобы объяснить и, возможно, убедить их, почему это плохо, и в их интересах не быть параноиком .