Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
книги хакеры / Питер_Гудлиф_Ремесло_программиста_Практика_написания_хорошего_кода.pdf
Скачиваний:
16
Добавлен:
19.04.2024
Размер:
9.23 Mб
Скачать

 

 

 

 

hang

e

 

 

 

 

 

 

 

C

 

E

 

 

 

 

X

 

 

 

 

 

 

-

 

 

 

 

 

d

 

 

F

 

 

 

 

 

 

t

 

 

D

 

 

 

 

 

 

 

i

 

 

 

 

 

 

 

 

 

r

 

P

 

 

 

 

 

NOW!

o

 

 

 

 

 

 

 

 

 

 

 

 

 

BUY

 

 

 

 

 

 

to

 

 

 

 

 

w Click

 

 

 

Контрольныеm

вопросы

 

 

 

 

w

 

 

 

 

 

 

 

 

 

 

w

 

 

 

 

 

 

 

o

 

 

.

 

 

 

 

 

.c

 

 

 

p

 

 

 

 

g

 

 

 

 

 

df

 

 

n

e

 

 

 

 

 

-xcha

 

 

 

 

 

 

 

 

hang

e

 

 

 

 

 

 

 

C

 

E

 

 

 

 

X

 

 

 

 

 

 

-

 

 

 

 

 

d

 

 

F

 

 

 

 

 

 

t

 

 

D

 

 

 

 

 

 

 

i

 

 

 

 

 

 

 

 

 

r

P

 

 

 

 

 

NOW!

o

 

 

 

 

 

 

 

 

 

 

 

 

BUY

 

 

 

 

 

 

to

 

 

 

 

 

51Click

 

 

 

 

 

m

 

 

 

 

 

 

w

 

 

 

 

 

 

 

o

 

 

w

 

 

 

 

 

 

 

 

w

 

 

 

 

 

 

.c

 

 

.

 

 

 

 

 

 

 

 

p

 

 

 

 

g

 

 

 

 

 

df

 

 

n

e

 

 

 

 

 

-x cha

 

 

 

 

Глава 12. Комплекс незащищенности

Защитное программирование – важнейшая технология создания надежных программных систем.

Глава 19. Спецификации

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

Контрольные вопросы

Подробное обсуждение этих вопросов можно найти в разделе «Ответы и обсуждение» на стр. 581.

Вопросы для размышления

1. Можно ли переусердствовать с защитным кодом?

 

 

 

 

hang

e

 

 

 

 

 

 

C

 

E

 

 

 

X

 

 

 

 

 

-

 

 

 

 

 

d

 

F

 

 

 

 

 

 

t

 

D

 

 

 

 

 

 

 

i

 

 

 

 

 

 

 

 

r

P

 

 

 

 

 

NOW!

o

 

 

 

 

 

 

 

 

 

 

 

BUY

 

 

 

 

 

to

 

 

 

 

w Click

 

 

 

52m

 

 

 

 

w

 

 

 

 

 

 

 

 

 

w

 

 

 

 

 

 

 

o

 

.

 

 

 

 

 

.c

 

 

p

 

 

 

 

g

 

 

 

 

df

 

 

n

e

 

 

 

 

-xcha

 

 

 

 

 

 

 

hang

e

 

 

 

 

 

 

 

C

 

E

 

 

 

 

X

 

 

 

 

 

 

-

 

 

 

 

 

d

 

 

F

 

 

 

 

 

 

t

 

 

D

 

 

 

 

 

 

 

i

 

 

 

 

 

 

 

 

 

r

P

 

 

 

 

 

NOW!

o

 

 

 

 

 

 

 

 

 

 

 

 

BUY

 

 

 

 

 

 

to

 

 

 

 

 

Глава 1. Держим оборонуClick

 

 

 

 

 

m

 

 

 

 

 

 

w

 

 

 

 

 

 

 

o

 

 

w

 

 

 

 

 

 

 

 

w

 

 

 

 

 

 

.c

 

 

.

 

 

 

 

 

 

 

 

p

 

 

 

 

g

 

 

 

 

 

df

 

 

n

e

 

 

 

 

 

-x cha

 

 

 

 

2.Нужно ли добавлять операторы контроля в каждую точку, где вы% явлена и исправлена ошибка?

3.Следует ли исключать из окончательных сборок операторы контро% ля посредством условной компиляции? Если нет, то какие конт% рольные операторы стоит оставить в окончательной сборке?

4.Что обеспечивает лучшую защиту – обработка исключений или операторы контроля в стиле C?

5.Следует ли включать защитную проверку пред% и постусловий в каж% дую функцию или только при вызове важных функций?

6.Насколько ограничения соответствуют идеалу защитного средства? Каковы их недостатки?

7.Можно ли обойтись без защитного программирования?

a.Можно ли изобрести язык, который устранит необходимость в защитном программировании? Как это сделать?

b.Следует ли из этого, что C и C++ порочны, поскольку они остав% ляют слишком много простора для возможных проблем?

8.Какого рода код не должен вызывать заботы о защитном програм% мировании?

Вопросы личного характера

1.Насколько тщательно вы обдумываете каждый оператор, который вводите? Проверяете ли вы безжалостно код возврата для каждой функции, даже если уверены, что она не может возвратить ошибку?

2.Указываете ли вы входные и выходные условия в описаниях функ% ций?

a.Присутствуют ли они в неявном виде в описании работы функ% ции?

b.Если входные и выходные условия отсутствуют, отмечаете ли вы это явно в документации?

3.Многие компании на словах одобряют защитное программирование. Рекомендуется ли придерживаться этой стратегии в ваших услови% ях? Изучите исходные коды – соблюдаются ли рекомендации на практике? Насколько распространена проверка допущений с помо% щью операторов контроля? Насколько тщательно осуществляется проверка ошибок в каждой функции?

4.Насколько вы по своему характеру недоверчивы? Пересекая дорогу, смотрите ли вы в обоих направлениях? Можете ли вы заставить себя делать неприятную работу? Проверяете ли вы свой код на все потен% циальные ошибки, какими бы маловероятными они ни казались?

a.Насколько легко делать это систематически? Не забываете ли вы о необходимости проверки ошибок?

b.Можно ли каким%то образом облегчить себе написание защитно%

го кода, более скрупулезно проверяющего ошибки?