[Закрыть]
 
popoff.donetsk.ua
Если дать ссылку на страничку с десятью примерами, то всегда найдутся люди, которые будут вести себя так, как будто этой ссылки не было и просить: «нет, ну ты приведи хотя бы один пример!»
Начало | Новости | Статьи | Форум | Опросы | Карта сайта | Обо мне
popoff.donetsk.ua - Статьи - Программирование - Технологии программирования - Что такое «правильная программа»?
Я это делаю
Персональное меню
Голосование
Деньги, либо любимое занятие? Постоянный адрес этого вопроса
Деньги, но неинтересная работа и невозможность уделить время семье
Интересная работа, возможность саморазвиваться, но нищенский заработок
Ваш возраст (не обязательно)
Почему? (не обязательно)

Голосование закрыто.

Поиск по сайту
Реклама
Программное обеспечение любой сложности
koins.com.ua
Статистика

Что такое «правильная программа»?

Постоянный адрес статьи

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

Таким образом, «правильная программа» - это термин.

Приведённые ниже свойства «правильной программы» следует проверять как для всей программы, так и для любых её фрагментов.

  1. В «правильной программе» легче найти и не допустить ошибку, чем в «неправильной».

    Чем проще и яснее Ваш алгоритм, тем легче в нём найти и не допустить ошибку.

    При сравнении любых отдельно взятых, идентичных по выполняемым действиям фрагментов программ, «более правильным» является тот, который короче, который зависит от наименьшего количества входных данных и который генерирует наименьшее количество результатов. Чем меньше входов и выходов у программы - тем легче в ней найти и не допустить ошибку.

    Более правильным является тот фрагмент программы, который зависит от наименьшего количества других фрагментов, потому что для корректного функционирования этого фрагмента не нужно помнить о том, как работает тот другой фрагмент и не нужно вносить изменения в тот другой фрагмент при модификации этого фрагмента программы.

  2. «Правильная программа» - это программа, которая будет работать правильно всегда, даже в ситуациях, которые кажутся невозможными.

    В отличие от «неправильной программы», которая работает правильно только на каком-то наборе тестов.

    При этом правильно должна функционировать не только программа целиком, но и каждый отдельный её фрагмент.

    Например, писать в SQL-запросе всегда, даже для целых чисел
    "... i_integer='".mysql_real_escape_string($i_integer)."' ..."
    правильно, потому что при правильно работающей функции mysql_real_escape_string() такой подход всегда гарантирует отсутствие SQL-инъекций, в отличие от «неправильной программы», в которой значение сначала проверяется, а потом подставляется в запрос без дополнительных преобразований, хотя бы только потому, что программа проверки исходных данных сама может содержать в себе ошибки. Второй вариант также зависит от большего количества фрагментов программы, что противоречит первому свойству «правильной программы» (программа должна зависеть от наименьшего количества других фрагментов), а также будет некорректно функционировать, если рассматривать вставку значения в SQL-запрос не целиком, вместе с кодом проверки исходных данных, а как отдельный фрагмент (что противоречит требованию, согласно которому каждый отдельный фрагмент программы должен работать правильно).

  3. В «правильной программе» легко разобраться.

    Как эвристику можно использовать такой подход: если в программе требуются комментарии для того, чтобы разобраться в ней, то это «неправильная программа».

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

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

Юрий Попов, popoff.donetsk.ua

Смотрите также

Что считать ошибкой?
http://popoff.donetsk.ua/text/work/prg/error.html

Обработка ошибок программистами и обработка сообщений об ошибках программами
http://phpclub.ru/faq/ErrorHandling

Последняя модификация: 06.08.06 02:22

Обсуждение статьи в форуме

Не проходите мимо! Оставьте Ваш комментарий в форуме! >>>

27.07.07 17:52 Aleksey

Статья в целом неплохая.

Однако существует ряд всяких «но»Например в разделе 1 написано
о простоте алгоритмов: простые алгоритмы не всегда эффективны. Например самый простой вид сортировки это пузырьковая, но более сложные алгоритмы Шелла и Квика или Блочной сортировки работают гораздо быстрее. Тому кто только начал заниматься программированием понять эти алгоритмы будет достаточно сложно. К тому же чем более универсальная программа тем она будет более сложной для понимания.

Что касается пункта 3, то на него следует наложить определенные рамки
по сложности программы. Например исходники «винды» без комментариев будут нечитабельны. То есть в сложных программах нужна очень большая модульность что бы информацию можно было воспринимать
доступными порциями, но дело в том что такая модульность тоже ведет к усложнению программы.

05.08.07 23:18 popoff

Aleksey,
Вопрос в п.1 - не в эффективности как таковой. Там не рассматривается эффективность ни по скорости, ни по памяти. Там вопрос в том, насколько устойчиво будет работать та программа.

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

Нужно, правда, учитывать, что для начинающих программистов не очевидно, решает ли их алгоритм одну общую задачу или несколько независимых задач. Они наваяли код и думают, что это - самый простой способ. Чтобы понять, что задач решается несколько, нужно иметь опыт. Здесь вопрос в алгоритмизации; в том, чтобы программист понимал, какие задачи и как он решает. Программисты, которые ваяли приведённый в предыдущем абзаце пример, убеждены, что они решали цельную, не делимую на части задачу.

Вопрос в п.1 - не о начинающих программистах, которым «понять будет достаточно сложно» чужой алгоритм сортировки. А о тех программистах, которые способны придумать десять собственных способов и выбрать среди них лучший.

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

К п.1 могу добавить, что иногда имеет смыл упростить саму задачу. Возможно даже, упростить за счёт эффективности. Ломается обычно лифт, а не лестница. Хотя, конечно, никто же не спорит, что лифт удобнее лестницы. Вот только как Вы будете выбираться из здания, если лестницы не предусмотрены, а свет выключился из-за пожара?

В Вашем примере с быстрой сортировкой, сортировка пузырьком - лучше, потому что она понятнее. Этот самый начинающий программист получит более правильную программу, если будет использовать более понятный ему алгоритм. А если он будет использовать метод быстрой сортировки, до конца в него не вникнув, то ошибок не избежать. Но вопрос этот не нужно сводить к личным способностям и наличию/отсутствию лени каждого отдельного программиста.

В действительности в методе пузырька нет ничего хитромудрого, в отличие от тех алгоритмов, которые явно можно упростить и, поэтому, назвать неправильными по критерию чрезмерной сложности.

П.3 - написано же: «эвристика». Когда я придумывал ту эвристику, я думал не о тех редких случаях многомегабайтных исходников, написанных профессионалами, о которых говорили Вы, а о тех чуть ли ни ежедневно встречающихся мне программках в несколько строк, в которых без комментариев даже автор разобраться не может.

Если какая-то часть исходников «винды» - не читабельная из-за отсутствия комментариев, то это совсем не является доказательством того, что другие сложные нечитабельные программы - правильные. Вы привели в качестве примера винду, скорее всего, из-за того, что она не просто большая, она - огромная; чтобы внести туда какие-то изменения и правки, нужно поднять огромное количество людей; необходимость приведения исходников винды в читабельный вид - практически нулевая, потому что она и так работает. У Вас нет автоматических тестов для модулей винды, поэтому, внося изменения в исходники винды Вы не можете быть уверены, что после Ваших изменений она останется работоспособной.

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

Просмотреть все комментарии в режиме форума. Всего комментариев: 2
Не проходите мимо! Оставьте Ваш комментарий в форуме! >>>