(no subject)
Jul. 23rd, 2009 03:37 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
norianЛитературная критика и шаблоны программирования
Существует некоторая, почти незаметная, разница между намерением и действием. Например, школьник собирается пойти в школу, но почему-то оказывается в пивнушке. Или мы собираемся пометить страницу в кэше и для этого выставляем флаг.
В языке ассемблера команды могут выполнять всякие хитрые действия, но мы судим о них в первую очередь по названию (например, DAA - аккумулятор выравнивания десятичных величин). Хоты команда и её название соотносятся напрямую, более высокий уровень названия может скрывать действие команды, которая просто переставляет биты по некоторому алгоритму. Если мы видим, что на самом деле выполняет команда, означает ли это, что мы злоупотребляем мухоморами? Ответ на этот вопрос зависит от обстоятельств.
Когда мы видим разницу между намерением и действием, у нас есть возможность оценить эффективность действия и выяснить, что мы можем узнать о намерении, или области намерений по структуре действия. Возможно, другое действие било бы лучше? Соответствуют результаты действия заявленным намерениям? Когда мы делаем это с книгами, это называется литературной критикой и воспринимается серьёзно. Если мы хотим понять, как писать лучшие программы, нам нужно узнать как можно больше об этом специфическом виде литературной критики, поскольку только так мы можем вести тонкие дискуссии об особенностях структуры или деталях, которые характеризуют стиль. Есть ещё одно приятное отличие программной критики от литературной - это такое доказательство правоты, как сообщения об ошибках в программе, которые придают процессу особый смак.
Мы можем получить строгий и элегантный стиль кодирования из разницы между намерением и действием. Рассмотрим следующий пример:
// Search the list of available dealers and find those that
// handle the triggering stock. Send them notification of
// the event.
for(DealerIterator DI(DealersOnline); DI.more(); DI++)
if(DI.CurrentDealer()->InPortfolio(TheEvent.GetStock()))
DI.CurrentDealer()->HandleEvent(TheEvent);
Определения объектов позволили лаконично выразить намерения в действии. Однако, здесь нельзя разбить код на более мелкие части и написать комменты так, чтобы они не были совсем идиотскими. Если мы чередуем комменты и код на этом естественном уровне, все строки кода окажутся объяснены в комментах. Поэтому есть мотивация разработать объекты или функции так, чтобы сохранить этот уровень. При этом легче исправить неэлегантный код, чем объяснять его кривизну в комментах.
Осознание разницы между намерениями и действиями помогает также совместить детальное документирование и комментирование кода, заодно помогая его верифицировать. Размещая всё в одном месте, мы способствуем когерентности уровней. Эта концепция развита в "литературном программировании" кнута, хотя и требует инструментальной поддержки. Но не обязательно покупать всё снаряжение, чтобы заниматься этим видом спорта - литературное программирование больше жизненная позиция, чем инструмент.
Существует некоторая, почти незаметная, разница между намерением и действием. Например, школьник собирается пойти в школу, но почему-то оказывается в пивнушке. Или мы собираемся пометить страницу в кэше и для этого выставляем флаг.
В языке ассемблера команды могут выполнять всякие хитрые действия, но мы судим о них в первую очередь по названию (например, DAA - аккумулятор выравнивания десятичных величин). Хоты команда и её название соотносятся напрямую, более высокий уровень названия может скрывать действие команды, которая просто переставляет биты по некоторому алгоритму. Если мы видим, что на самом деле выполняет команда, означает ли это, что мы злоупотребляем мухоморами? Ответ на этот вопрос зависит от обстоятельств.
Когда мы видим разницу между намерением и действием, у нас есть возможность оценить эффективность действия и выяснить, что мы можем узнать о намерении, или области намерений по структуре действия. Возможно, другое действие било бы лучше? Соответствуют результаты действия заявленным намерениям? Когда мы делаем это с книгами, это называется литературной критикой и воспринимается серьёзно. Если мы хотим понять, как писать лучшие программы, нам нужно узнать как можно больше об этом специфическом виде литературной критики, поскольку только так мы можем вести тонкие дискуссии об особенностях структуры или деталях, которые характеризуют стиль. Есть ещё одно приятное отличие программной критики от литературной - это такое доказательство правоты, как сообщения об ошибках в программе, которые придают процессу особый смак.
Мы можем получить строгий и элегантный стиль кодирования из разницы между намерением и действием. Рассмотрим следующий пример:
// Search the list of available dealers and find those that
// handle the triggering stock. Send them notification of
// the event.
for(DealerIterator DI(DealersOnline); DI.more(); DI++)
if(DI.CurrentDealer()->InPortfolio(TheEvent.GetStock()))
DI.CurrentDealer()->HandleEvent(TheEvent);
Определения объектов позволили лаконично выразить намерения в действии. Однако, здесь нельзя разбить код на более мелкие части и написать комменты так, чтобы они не были совсем идиотскими. Если мы чередуем комменты и код на этом естественном уровне, все строки кода окажутся объяснены в комментах. Поэтому есть мотивация разработать объекты или функции так, чтобы сохранить этот уровень. При этом легче исправить неэлегантный код, чем объяснять его кривизну в комментах.
Осознание разницы между намерениями и действиями помогает также совместить детальное документирование и комментирование кода, заодно помогая его верифицировать. Размещая всё в одном месте, мы способствуем когерентности уровней. Эта концепция развита в "литературном программировании" кнута, хотя и требует инструментальной поддержки. Но не обязательно покупать всё снаряжение, чтобы заниматься этим видом спорта - литературное программирование больше жизненная позиция, чем инструмент.