РИС. 2.5. Способы улучшения читаемости программы.
(Слегка подкорректированный материал из википедии)
Парадигма программирования (стиль программирования)— это совокупность подходов, методов, стратегий, идей и понятий, используемых при написании программ.
Парадигма программирования в современной индустрии программирования очень часто определяется набором инструментов программиста (язык программирования и операционная система).
Парадигма программирования представляет (и определяет) то, как программист видит выполнение программы. Например, в объектно-ориентированном программировании программист рассматривает программу как набор взаимодействующих объектов, тогда как в функциональном программировании программа представляется в виде цепочки вычисления функций.
Своим современным значением в научно-технической области термин «парадигма» обязан, по-видимому, Томасу Куну и его книге «Структура научных революций» (см. парадигма). Кун называл парадигмами устоявшиеся системы научных взглядов, в рамках которых ведутся исследования. Согласно Куну, в процессе развития научной дисциплины может произойти замена одной парадигмы на другую (как, например, геоцентрическая небесная механика Птолемея сменилась гелиоцентрической системой Коперника), при этом старая парадигма ещё продолжает некоторое время существовать и даже развиваться благодаря тому, что многие её сторонники оказываются по тем или иным причинам неспособны перестроиться для работы в другой парадигме.
Термин «парадигма программирования» впервые применил Роберт Флойд в своей лекции лауреата премии Тьюринга.
Флойд отмечает, что в программировании можно наблюдать явление, подобное парадигмам Куна, но, в отличие от них, парадигмы программирования не являются взаимоисключающими:
«Если прогресс искусства программирования в целом требует постоянного изобретения и усовершенствования парадигм, то совершенствование искусства отдельного программиста требует, чтобы он расширял свой репертуар парадигм.»
Таким образом, по мнению Роберта Флойда, в отличие от парадигм в научном мире, описанных Куном, парадигмы программирования могут сочетаться, обогащая инструментарий программиста.
Компонентами парадигм программирования являются о сновные модели программирования п одходы и приёмы
Термин стиль программировании не следует воспринимать как правила записи программного кода. В основе требований к записи программного кода лежат требования синтаксиса языка программирования. Критерии оценки исходного кода: понимаемость,
однозначность, удобство отладки, оптимальность, что ведет, в итоге, к правильной программе. Многие уделяют большое внимание конструированию имен при написании исходного кода.
Обратимся к первоисточникам.
Книга Б. Страуструпа "Язык программирования С++" дает описание языка, его ключевых понятий и основных приемов программирования на нем. Это завершенное руководство, написанное создателем языка, которое содержит описание всех средств С++, в том числе управление исключительными ситуациями, шаблоны типа (параметризованные типы данных) и множественное наследование.
Бьерн Страуструп является разработчиком языка С++ и создателем первого транслятора. Он - сотрудник научно-исследовательского вычислительного центра AT&T Bell Laboratories в Мюррей Хилл (Нью-Джерси, США). Он получил звание магистра математики и вычислительной техники в университете г. Аарус (Дания), а докторское звание по вычислительной технике в кэмбриджском университете (Англия). Он специализируется в области распределенных систем, операционных систем, моделирования и программирования. Вместе с М. А. Эллис он является автором полного руководства по языку С++ -"Руководство по С++ с примечаниями".
2.2 ИМЕНА
Имя (идентификатор) является последовательностью букв или цифр. Первый символ должен быть буквой. Буквой считается и символ подчеркивания _. Язык С++ не ограничивает число символов в имени. Но в реализацию входят программные компоненты, которыми создатель транслятора управлять не может (например, загрузчик), а они, к сожалению, могут устанавливать ограничения. Кроме того, некоторые системные программы, необходимые для выполнения программы на С++, могут расширять или сужать множество символов, допустимых в идентификаторе. Расширения (например, использование $ в имени) могут нарушить переносимость программы. Нельзя использовать в качестве имен служебные слова С++ (см. $$R.2.4), например : hello this is a most unusially long name Теперь приведем примеры последовательностей символов, которые не могут использоваться как идентификаторы: 012 a fool $sys class 3var pay.due foo~bar .name if Заглавные и строчные буквы считаются различными, поэтому Count и count - разные имена. Но выбирать имена, почти не отличающиеся друг от друга, неразумно. Все имена, начинающиеся с символа подчеркивания, резервируются для использования в самой реализации или в тех программах, которые выполняются совместно с рабочей, поэтому крайне легкомысленно вставлять такие имена в свою программу. При разборе программы транслятор всегда стремится выбрать самую длинную последовательность символов, образующих имя, поэтому var 10 - это имя, а не идущие подряд имя var и число 10. По той же причине elseif - одно имя (служебное), а не два служебных имени else и if .
DEFINED foO bAr u_name HorseSense
var0 var1 CLASS _class
Создание читаемой программы служит признаком хорошего стиля программирования. Это приводит к облегчению понимания смысла программы, поиска ошибок и в случае необходимости ее модификации. Действия, связанные с улучшением читаемости программы, кроме того, помогут более четко понять, что программа делает. На протяжении всего изложения мы будем пытаться указывать полезные приемы, способствующие достижению этой цели.
Мы уже упоминали о двух таких способах: выбор осмысленных обозначений для переменных и использование комментариев. Заметим, что эти два метода дополняют друг друга. Если вы дали переменной имя width (ширина), то необходимость в комментарии, сообщающем о том, что данная переменная определяет ширину, отпадает.
Еще один прием состоит в использовании пустых строк для того, чтобы отделить одну часть функции, соответствующую некоторому семантическому понятию, от другой. Например, в нашей простой программе одна пустая строка отделяет описательную часть от выполняемой (присваивание значения и вывод на печать). Синтаксические правила языка Си не требуют наличия пустой строки в данном месте, но поскольку это стало уже традицией, то и мы делаем также.
Четвертый принцип, которому мы следуем, заключается в том, чтобы помещать каждый оператор на отдельной строке. Опять же это только соглашение, которое никак не регламентируется правилами языка, так как Си имеет "свободный формат". Вы можете поместить несколько операторов на одной строке или распространить один оператор на несколько строк. Нижеследующий пример является абсолютно правильной программой:
main( )
{
int four; four = 4;
printf(" %d \n", four);
}
Совершенно очевидно, что символ "точка с запятой" указывает компилятору, где кончается один оператор и начинается следующий, но логика программы окажется проще, если вы последуете соглашениям, приведенным выше. Поскольку в нашем примере запутанной логики нет, вид программы в данном случае не влияет на понимание ее смысла, но, по нашему мнению, лучше прививать хорошие привычки с самого начала.
РИС. 2.5. Способы улучшения читаемости программы.
В от эти несколько слов: стиль программирования меня не волнует. Я достаточно краток? Если хотя бы половина времени, израсходованного на правильную расстановку фигурных скобок, тратилась на обдумывание программы или еще лучше — на общение с пользователями, то вся отрасль работала бы намного эффективнее. Конечно, единство стиля — вещь хорошая, но я еще не видел книги или руководства по стилю, которые бы стоили даже часового собрания группы в начале проекта (выделено Рудаковым С.А.). К тому же ни одна книга или руководство по стилю не превратят код неаккуратного программиста в нечто осмысленное. В сущности, стиль часто используется как оправдание недостатка внимания к самой программе. Наконец, я еще не видел, чтобы в спорах о стиле один программист в чем-то убедил другого, поэтому любые дискуссии на эту тему считаю бесполезной тратой времени.
У меня есть свои собственные принципы и свой стиль, но в основном я собираюсь отказаться от своего пути и понемногу пользоваться всеми стилями, с которыми мне приходилось встречаться. Книга посвящена языковым идиомам, а не расположению фигурных скобок или регистру символов. Надеюсь, мое решение будет раздражать всех читателей в равной мере.
Чтобы создать или определить переменную, нужно указать ее тип, за которым (после одного или нескольких пробелов) должно следовать ее имя, завершающееся точкой с запятой. Для имени переменной можно использовать практически любую комбинацию букв, но оно не должно содержать пробелов, например: x, J23qrsnf и myAge. Хорошими считаются имена, позволяющие судить о назначении переменных, ведь удачно подобранное имя способно облегчить понимание работы программы в целом. В следующем выражении определяется целочисленная переменная с именем myAge:
int myAge ;
……………………………………………………………..
Уважающие себя программисты стремятся избегать таких нечитабельных имен переменных, как J23qrsnf, а однобуквенные имена (например, x или i) используют только для временных переменных, таких как счетчики циклов. Старайтесь использовать как можно более информативные имена, например myAge или howMany. Такие имена даже три недели спустя помогут вам вспомнить, что вы имели в виду, когда писали те или иные программные строки.
Поставьте следующий эксперимент. Опираясь лишь на первые пять строк программы, попробуйте догадаться, для чего предназаначены объявленные ниже переменные.
Пример 1:
int main()
{
unsigned short x;
unsigned short y;
unsigned short z;
z=x*y;
return 0;
}
Пример 2:
int main()
{
unsigned short Width;
unsigned short Length;
unsigned short Area;
Area= Width * Length;
return 0;
}
……………………………..
Очевидно, что о назначении переменных во втором примере догадаться легче, и неудобство, связанное с необходимостью вводить более длинные имена переменных, впоследствии окупится с лихвой, потому, что вам не придется ломать голову, для чего предназначена та или иная переменная.
Нет слов! Вспоминаю анекдот (с бородой).
«Генерал проводит проверку знаний рядового состава.Вернемся к нашим баранам.
Как бы ему, г. Джесс Либерти, не барану, отправить письмо такого содержания:
«Уважающий себя программист, г. Джесс Либерти!Если бы не пример 2 на стр. 56 Вашей книги, я бы никогда не догадался, что же это делается в примере 1! Спасибо за подсказку г. Джесс Либерти – уважающий себя программист. Я - неуважающий себя программист, наконец-то понял, что в примере 1 умножается нерусская ширина на нерусскую длину и получается нерусская площадь! Спасибо за столь умные наставления, г. Джесс Либерти. Я в дальнейшем всегда буду стараться использовать информативные имена, например myAge или howMany, а то вдруг три недели спустя забуду, что означает z=x*y.
Обещаю Вам, уважающий себя программист, что буду использовать только хорошие имена и не буду использовать плохие имена, особенно такие, которые придумывают плохие программисты или те имена, которые пишут в России на заборах или говорят в госдуме.
С уважением уважающему себя программисту.
Рудаков С.А.»
Самое лучшее доказательство своей точки зрения состоит в доведении до абсурда противоположной точки зрения. Джесс Либерти, сам того не понимая, довел до абсурда требование имяпостроения и дискриминацию на этой основе программистов на хороших и плохих.
Считаю категорически, что не существует теории создания имен, построение имен - результат корпоративных соглашений и не может быть продиктовано как требования к обучению и контролю знаний студентов. Построение имен - только в советах и пожеланиях.