Стиль программирования


23. Стиль программирования, необходимость использования стиля программирования.

Для создания качественного ПО следует использовать приемы такие как: тщательное проектирование, разработка пользовательского и программного интерфейса, своевременная выработка стратегии по проведению отладки и тестировании и многие другие приемы и подходы.

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

Стиль программирования — это результат соглашения между опытными программистами о правилах написания программ с учетом мирового опыта.

Основными приемами улучшения стиля программирования являются: правильная система идентификации, использование комментариев, структуризация текстов. Целью принятия и использования стандарта, является упрощение восприятия программного кода человеком.

Имена классов должны быть объявлены с использованием так называемого StadlyCaps каждое слово начинается с большой буквы и без разделителей.

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

24. Стиль программирования, использование комментариев.

Стиль программирования — это результат соглашения между опытными программистами о правилах написания программ с учетом мирового опыта.

Листинг – это визитная карточка программиста.

Комментарии бывают 3-х типов: вводные, оглавления и пояснительные.

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

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

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

Комментарии должны быть верными и грамотными. Неправильные комментарии хуже чем их отсутствие. Комментарии должны нести смысловую нагрузку.

В большом по объёму листинге рекомендуется использовать не менее 1 комментария на 10 операторов.

Комментарии следует писать в процессе написания программы.

25. Стиль программирования, система идентификации.

Стиль программирования — это результат соглашения между опытными программистами о правилах написания программ с учетом мирового опыта.

Имена переменных, классов методов должны нести смысловую нагрузку.

Правило формирования имен.

1. В аббревиатуру входят первые буквы слов в верхнем регистре.

2. Согласные буквы важнее гласных.

3. Начало слова важнее конца.

Если идентификатор состоит из нескольких слов, то эти слова можно соединять друг с другом различными способами:

— в соответствии с правилами Корнегана и Ричи соединение происходит с помощью знака _;

— каждое новое слово начинается с большой буквы и не разделяются;

C/C++ — стиль программирования

То что вы здесь прочитаете касается пока только именования идентификаторов, впoследствии надеюсь развить эту тему. Если у кого-то имеются свои доводы и суждения на счет стиля, буду очень благодарен за высланные комментарии.

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

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

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

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

Мне часто попадаются фрагменты кода приблизительно такого вида:

Eсли на этот исходник посмотрит какой-нибудь Билл Гейтс (который хочет взять вас на работу), то он ничего не поймет так как русского языка не знает. Кстати, мне попадались исходники на немецком и итальянском. Во вторых — английский язык достаточно емкий, сравните на сколько стало короче:

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

Размер

Допустим у вас есть переменная или функция означающая «Убрать из строки все пробелы», программист, именующий идентификаторы в стиле операционных систем Unix записал бы ее название так «strsptr» или даже «strst». То есть все было бы максимально кратко и в нижнем регистре. Да, я тоже читал про то что когда-то терминалы принимали данные со скоростью 10 символов в секунду и хитрые программеры специально записывали все как можно короче. Вполне возможно что эта привычка осталась еще и потому, что некоторые программисты писали свои первые программы на Бейсике, в старых версиях которого для имени переменной разрешалось использовать только один или два символа.

При таком подходе у исходных текстов программы имеется один большой недостаток. Если в тексте нет комментариев (а это скорее правило чем исключение), то через полгода просматривая исходник вы будете долго вспоминать, чего бы это значило — «if( !strst( mystr)) printf. «. На мой взгляд, не нужно лениться набивать «лишние» буквы. Краткое название идентификатора уместно использовать только для именования индексных переменных в теле цикла или в качестве локальной переменной небольшой процедуры. Например:


Стиль программирования

Узбекское Агентство
Связи и Информатизации

Ташкентский Университет Информационных Технологий

Кафедра
«Программное обеспечение информационных технологий»

Направления:

5521900 Информатика и
информационные технологии,
5523500 Защита информации,
5523600 Электронная коммерция,
5811200 Сервис (информационный сервис),
5811300 Сервис (электронные и
компьютерные технологии),
5320200 Информатика и
библиотековедение,
5140900 Профессиональное образование
(по направлению
информатика и
информационные технологии).

Выдержки из лекций

Глава 6. Стиль программирования

Под стилем программированияпонимается набор приемов или методов программирования, которые используют опытные прог­раммисты, чтобы получить правильные, надежные, эффек­тивные, удобные для применения и легко читаемые программы.

Правила хорошего стиля программирования — это результат соглашения между опытными программистами (маленький стан­дарт). Если бы все программисты придерживались своего инди­видуального стиля, то результатом было бы Вавилонское стол­потворение.

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

Слишком часто, стремясь побыстрее получить работающую программу, забывают о ее удобочитаемости. Трудночитаемые программы обычно сложно модифицировать. Особенно, если это приходится делать не автору программы. Как правило, к разра-ботке программы приступают со скромными целями, а в даль­нейшем расширяют ее возможности. Легко читаемая программа свидетельствует, что ее автор хорошо знал свое дело.

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

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

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

Стиль Си и стандарты программирования.

C Style and Coding Standards.

Glenn Skinner
Suryakanta Shah
Bill Shannon

AT&T Information System
Sun Microsystems

Вольный перевод: Поисов Дмитрий

Цель данного документа – описание стиля программирования на языке С, используемого в компаниях AT&T и Sun. Общий стиль программирования облегчает взаимодействия при разработке одной программы несколькими программистами. Использование единого стиля программирования для всего проекта улучшает читабельность кода и упрощает сопровождение проекта.

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

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

1. Привила именования файлов.

В операционной системе Unix используются определенные расширения файлов, обрабатываемых компилятором языка С.

Используйте следующие расширения файлов:

— для файлов с исходном кодом на языке С — расширение .c;
— для файлов с исходном кодом на языке assembler — расширение .s;
— для перемещаемых объектных файлов — расширение .o;
— для заголовочных файлов — расширение .h;
— для архивных библиотечных файлов — расширение .a;
— для файлов с исходным кодом на скриптовом языке C shell — расширение .csh;
— для файлов с исходным кодом командной оболочки Unix (Bourne shell) — расширение .sh;
— для файлов с кодом генератора синтаксических анализаторов yacc — расширение .y;
— для файлов с кодом генератора лексических анализаторов lex — расширение .l;

2. Организация программы.

Разделяйте программы на модули. Модульный код с четким разделением меньше подвержен программным ошибкам, проще сопровождается и легче расширяется. Хотя язык С и не представляет инструментария для разделения программы на модули, разделение на модули можно достичь с помощью методов и соглашений, описанных ниже.

Модуль – это группа процедур и данных, совместно реализующих некую абстракцию, например: таблицу символов или задачу управления памятью и т.д.

Примечание: Процедуры и данные, используемые другими модулями, называются «public» (публичными). Процедуры и данные, доступные только внутри модуля, называются «private» (приватными).

Модуль состоит из двух файлов: «интерфейсный» файла и «применяемый» файл. «Интерфейсный» файл содержит публичную (public) декларацию. «Применяемый» файл – содержит приватную (private) декларацию и код процедур. Приватная декларация в «применяемых» файлах должна быть объявлена как статическая.

В языке С роль «интерфейсного» файла играют заголовочные файлы (файлы с расширением .h). Роль «применяемых» файлов – файлы с исходным кодом на языке С (файлы с расширением .с).

Старайтесь повсеместно использовать модульный код. Степень модульности определяется исходя из сложности проекта/задачи и производительности обмена между модулями. Пользуйтесь здравым смыслом при распределении задачи на модули и соблюдайте баланс. Для выполнения простых операций использовать макросы препроцессора.

3. Организация файлов.

Файл должен разделяться на секции. Секции в файле должны отделяться пустыми строками.

Хоть формально максимальные требования к размеру файла не предъявляются, не рекомендуется использовать более 3000 строк кода в одном файле, так как код будет трудным для восприятия.

Так же следует избегать слишком длинных строк. Не все терминалы и текстовые редакторы хорошо работают с ними.

3.1 Заголовочные файлы.

Порядок разделов для .h файлов выглядит следующим образом:


а) Идентификатор автора: файл должен начинаться с указания автора кода.

б) #ifndef: Заголовочный файл часто может подключаться в нескольких файлах. Чтобы избежать многократного включения заголовочного файла в рамках одного проекта используется директива #ifndef. Директива #ifndef проверяет объявление идентификатора, который объявляется после директивы #ifndef. При первом подключении заголовочного файла данные файла используются, при последующих подключениях, директива #ifndef прервет использование данных заголовочного файла. Обычно идентификатор состоит из символа подчеркивания и имени файла. Директива #ifndef должна следовать сразу после указания автора.

в) Блок комментариев: после #ifndef должен идти блок комментариев, описывающий назначение объектов в файле (функций, глобальных переменных и т.д.). Описание должно быть коротким и по делу.

г) #includes: После блока комментариев подключаются дополнительные .h файлы.

д) #defines: далее следуют определения с помощью директивы #defines, относящиеся к модулю в целом, но не к отдельным элементам структур.

е) typedefs: после определения идентификаторов с помощью #define, идут определения новых типов данных с помощью оператора typedef.

ж) Декларация структур: если определение директивы #define, относится к глобальным данным (например, флаги слова), то определение должно следовать сразу же после объявления этих данных.

з) Декларация функций: объявление функций должно идти после декларации структур. Все внешние функции должны быть объявлены, даже те, которые возвращают int или ничего не возвращают (объявляются как возвращающие void).

и) Объявление внешних переменных: далее идет декларация внешних переменных.

к) Не определяйте статические и глобальные переменные в заголовочных файлах. Декларация переменных в заголовочных файлах часто является показателем плохого распределения кода по файлам.

3.2 Файлы с исходным кодом.

Порядок разделов для .c файлов приведен ниже:

а) Идентификатор автора: файл должен начинаться с указания автора кода.

б) Блок комментариев: сразу после имени автора должен идти блок комментариев, описывающий содержимое файла.

в) #includes: далее должно идти подключение заголовочных файлов.

г) typedefs and #defines: после подключения заголовочных файлов должны следовать определения с помощью операторов typedef и #define.

д) Определение структур: далее идет определение структур.

е) Глобальные переменные: они должны располагаться после определения структур.

ж) Декларация функций: далее должна следовать декларация функций. Декларироваться должны только приватные функции. Публичные функции уже объявлены в заголовочных файлах, которые подключены выше. Хотя С-компилятор и не требует объявления функций возвращающих int, декларировать такие функции считается хорошим тоном.

з) Определения: Наконец пришла очередь самих функций. Каждой функции должен предшествовать блок комментариев. Функции должны следовать в определенном порядке. Лучше если они будут упорядочены сверху вниз, чем снизу вверх. Функции схожего уровня «абстракции» лучше располагать рядом. Функции желательно размещать как можно ближе к месту их вызова. При наличии большого числа функций практически не имеющих взаимосвязи можно располагать их в алфавитном порядке.

а) Каждый новый уровень должен отделяться табуляцией (8 пробелов).

б) Каждая строка должна быть ограничена размером страницы (код не должен переноситься на новую строку).

в) Вставляйте табуляцию при объявлении переменных для выравнивания имен переменных. Это делает код более читабельным. Например:

г) Имена и параметры функций должны идти в колонку по одному на строке. Это облегчит поиск по файлу. Тип, возвращаемый функцией, должен размещаться на отдельной строке (int необходимо указывать явно). Определения параметров функции должны идти сразу после имени функции. Каждый параметры функции должен быть явно указан. Все параметры функции должны располагаться на одном уровне отступа. Открывающиеся и закрывающиеся фигурные скобки должны располагаться на отдельной строке на одном уровне отступа. Все локальные определения переменных и код функции должны иметь отступ хотя бы на один уровень. Декларация переменных должна иметь отступ от кода функции на одну пустую строку. Например:

д) Выражение, не умещающиеся в одну строку, например, вызов функции с множеством аргументов, должно быть перенесено после последней запятой, в случае вызова функции (а не посередине объявления аргумента), или после последнего оператора, который помещается на строке. Новую строку не следует начинать с бинарного оператора. В случае вызова функции, перенесенный на новую строку аргумент, должен быть выравнен с первым символом аргумента следующего непосредственно после открывающейся круглой скобки функции. Например:

е) Привала отступа при использовании операторов «if», «for», «switch» и т.д. описаны ниже в разделе 6.2.

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

а) Должны быть хорошо описаны нетривиальные решения и неординарные ситуаций, такие как «побочный эффект». Следует избегать дублирования информации, возникающее при комментировании очевидного кода.

б) В комментариях должны быть отражены все изменения в функциях, внешних переменных и указателях.

в) При использовании оператора case следует вводить соответствующие комментарии.

г) Все декларации должны комментироваться, за исключением декларации одноразовых счетчиков (например, для организации цикла) и очевидных имен констант. Комментарии при декларации переменных должны быть выровнены в один столбец.

д) Устаревшую информацию следует своевременно удалять из комментариев.

е) Блоки комментариев не должны выделяться специальными полями из символов (например, звездочек).

ж) Комментарии не должны содержать специальных символов, таких как «backspace».

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

и) Комментарии не должны содержать списки авторов и историю изменений кода.

Существует три стиля комментариев: блочный, однострочный, завершающий строку с кодом. Эти стили комментариев описаны ниже.

5.1 Блочные комментарии.

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


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

Файл, содержащий функцию main() должен содержать в начале файла блочный комментарий описывающий работу всей программы. Во всех остальных файлах в комментариях должно описываться только функционирование содержимого файла.

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

В блочных комментариях оператор /* должен идти с первого символа строки, в один столбец с оператором */. Перед каждой новой строкой комментариев должен идти символ *, вторым символом в строке (первый символ – пробел). Это позволит поиском строки «.\*» найти все блочные комментарии в файле. В первой и последней строках блочного комментария не должно быть текста. В начале блочного комментария тестовая строка должна отделяться от символа * на один пробел, далее отступ текста может увеличиваться при необходимости.

Пример блочного комментария:

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

5.2 Однострочные комментарии.

Однострочные комментарии используются для описания неочевидных «условий» и «возвращаемых значений».

а) Однострочные комментарии должны иметь отступ равный отступу комментируемого кода. Текст комментария должен быть отделен от операторов /* и */ пробелом.

б) Блочный комментарий должен использоваться, когда комментарий не помещается в одну строку.

5.3 Комментарии, завершающие строку с кодом.

Данный вид комментариев наиболее часто используется.

а) Комментарий должен отделяться от конца строки с кодом достаточно далеко.

б) Все комментарии параметров и локальных переменных должны быть выравнены в один столбец.

в) Если в блоке кода более чем один комментарий, то коментарии должны быть выравнены в один столбец.

г) Старайтесь не комментировать каждую строку кода.

Следующие стандарты должны использоваться при декларации:

а) Желательно, чтобы в одной строке кода была только одна декларация, так как декларация должна сопровождаться коментариями.

Однако последний стиль декларации допустим при декларации нескольких схожих по назначению переменных простого типа, такого как int или char.

б) Не смешивайте декларацию переменных и функций, как приведено в примере:

в) Не объявляйте локальные переменные с одним и тем же именем во внутренних блоках функции, например:

Хотя это и допустимый в языке С код, но в нем легко запутаться.

г) В структурах и объединениях (union) декларация каждой переменной должна начинаться с новой строки и сопровождаться комментарием. Открывающаяся фигурная скобка «<» должна быть на одной строке с объявлением структуры или объединения (union). Закрывающаяся фигурная скобка «>» должна быть на отдельной строке и располагаться в ее начале. Например:

д) Все внешние переменные, определенные в текущем модуле, но использование которых так же требуется в других модулях, должны декларироваться в отдельном заголовочном файле. Например, если в модуле «проверки» используется переменная aud_stat, определенная в заголовочном файле aud_ex.h, то другие модули, которым требуется данная переменная, должны подключать заголовочный файл aud_ex.h. Все модули, в которых используются внешние переменные, должны объявлять их в заголовочном файле с именем: modulename_ex.h

е) Переменные и функции, доступ к которым ограничен одним файлом, должны декларироваться как static. Это позволит четко знать, что функции и переменное – частные, используются только в одном файле. И так же исключает возможность конфликта имен переменных и функций в разных файлах.

ж) При декларации каждой функции необходимо явно указывать возвращаемое значение. Если функция не возвращает значений, то указывается – void.

з) Определения с помощью typedef используются для «параметризации» программ с целью повышения портабельности и модифицируемости. А так же для улучшения возможностей документирования исходного кода. Однако использование директивы typedef скрывает исходный тип декларации. Эта проблема особенно актуальна для сложных программ и программ для которых важна эффективность работы, а следовательно осведомленность разработчиков во всех деталях. Выбор возможности и объема использования директивы typedef остается за разработчиком. В примере ниже приведено неуместное использование директивы typedef:

и) Директива typedef не должна использоваться для определения указателей на структуру, так как полезно, а иногда необходимо однозначно и быстро понимать, что в коде используется указатель. В примере ниже показывается как не стоит делать:

7.1 Простые операторы.

а) Каждая строка должна содержать не более одного оператора. Не следует делать, как указано в примере:

б) Не используйте оператор «запятая» для объединения нескольких операторов в одной строке, или с целью исключения фигурных скобок, как это показано в примере:

г) Не группируйте операторы с троичным условным оператором «?:», как это показано в примере:

7.2 Сложные операторы.

Сложные операторы – это операторы, которые содержат список операторов заключенных в фигурные скобки «<>».

а) Список в фигурных скобках должен отступать от оператора на один уровень (tab).

б) Открывающаяся фигурная скобка должна быть в конце строки начала сложного оператора, а закрывающаяся скобка должна быть на отдельно строке, в столбце, с которого начинается сложный оператор (смотри пример ниже)

в) Использование фигурных скобок для выделения одиночного оператора, если он является частью структуры операторов, таких как if-else или for, определяется индивидуально. Например:

Однако в рамках одного проекта необходимо использовать только один стиль.

Не используйте фигурные скобки, если тело циклов for или while пусто:


д) Операторы if, if-else, if-else if-else должны иметь следующую форму:

е) Оператор for должны иметь следующую форму:

В операторе for используйте не более трех переменных. Очень тяжело воспринять организацию цикла при использовании большого количества переменных. Если нужно используйте отдельные операторы условия в теле цикла.

ж) Оператор while должен иметь следующую форму:

з) Оператор do-while должен иметь следующую форму:

и) Оператор switch должен иметь следующую форму:

Каждый оператор switch должен иметь состояние «default». Последний break – избыточен, но его применение желательно. Это избавит от ошибок при добавлении в конец оператора switch нового case. В языке С использование оператора switch желательно минимизировать.

Каждый многострочный блок оператора switch отделяйте пустой строкой, как показано в примере:

Пустые строки улучшают восприятие кода, объединяя разделы (участки кода) имеющие логическую взаимосвязь. Пустые строки нужно использовать в следующих случаях:

а) После секции #include.
б) После блока с #define – константами и #define – макросами.
в) Между декларациями структур.
г) Между функциями.
д) После декларации локальных переменных и между открывающейся фигурной скобкой функции и первой строкой функции с исходным кодом, если в этой строке не декларация локальных переменных.

Пробелы должны использоваться:

а) В ключевых операторах (sizeof, return и т.д.) после открывающейся скобки должен стоять один пробел. Пробел не должен использоваться между именем функции и открывающейся скобкой.

б) Пробелы должны ставиться в списках аргументов после запятой.

в) Все бинарные операции, за исключением «.» и «->» должны отделяться от операнда пробелом. Другими словами, пробелы должны ставиться до и после операторов присваивания, арифметических операторов, логических операторов. Пробелы никогда не должны отделять операнды от унарных операторов, таких как адрес (&), указатель (*), инкремент (++), декремент (—) т.д.. Например:

г) операторы в условии для цикла «for» должны разделяться пробелами:

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

е) Не используйте пробелы для выделения отдельных функций в тексте программы. Если надо обособить текст функции, то вынесите эту функцию в отдельный файл.

9. Имена файлов, функций и переменных.

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

а) Имена переменных и функций должны быть короткими, но осмысленными. Однознаковые имена переменных желательно избегать, за исключением «одноразовых» переменных. Имена переменных i, j, К, М, N должны использоваться для целых чисел, с, Д, Е для символьных переменных (строк), p — для указателей. Избегайте использовать имя переменной «L», так как в некоторых редакторах трудно отличить L от 1.

б) К именам указателей должен добавляться символ «p» для каждого уровня ссылки. Например, указатель на переменную dbaddr должен иметь имя dbaddrp. А указатель на указатель dbaddrp должен иметь имя dbaddrpp.

в) Разделяйте слова в длинных именах подчеркиванием, например: create_panel_item.

г) Имена констант, определенных директивой #define, должны состоять только из заглавных символов.

д) Название типов переопределенных с помощью typedef, должны заканчиваться на «_t» или начинаться с заглавной буквы, например:

е) Имена «макросов» должны состоять только из заглавных букв, за исключением «макросов» действующих как функции. В последнем случае имя «макроса» должно состоять только из строчных букв.

ж) Имена переменных и структур должны содержать только строчные буквы.

Примечание: следует избегать имен переменных, которые отличаются только регистром, например: Foo и FOO.

з) Индивидуальные элементы enums должны быть уникальными. Уникальность имени переменной можно гарантировать префиксом содержащим имя функции или модуля, в котором они используются, например:

и) Все внешние имена должны иметь префикс, идентифицирующий модуль, связанный с данной переменной (функций и т.д.), например:

10. Практика программирования.

а) Числовые константы не должны использоваться непосредственно в коде (в виде числа).

б) Определенные с помощью #define константы должны иметь осмысленные имена. Это также упростит корректировку больших программ, так как значение констант может изменяться путем изменения только значения указанного с помощью #define.

в) В ситуации, когда переменная может принимать ограниченное количество дискретных значений, предпочтительно использование типа данных enum, так как дополнительная проверка сможет осуществляться через lint.

г) Не рекомендуется использовать goto. Основная ситуация, когда допустимо использования goto – это выход из оператора switch.

д) Не используйте goto для перехода во внутрь блока программы, например так:

е) Не присваивайте значения переменным в длинной строке декларации переменных, например:

ж) Старайтесь не присваивать одно и то же значение нескольким переменным в одном операторе. Не используйте одновременно несколько присвоений, так как это тяжело воспринимается, особенно для сложных выражений. Например:

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


и) Не переопределяйте составные части структур с помощью #define, вместо этого используйте union. Однако, директива #define может использоваться для определения ссылок на составные части union. Например, вместо:

к) В конце конструкции #ifdef, которая используется для выбора необходимого набора опций, включайте #else. Данный пункт конструкции должен содержать информацию об ошибке, если не один из вариантов конструкции #ifdef не был выбран. Например:

л) Не используйте логическое отрицание (!) в «нелогических» выражениях. В частности никогда не используйте логическое отрицание для проверки на нулевой указатель или проверки успешного завершения работы функции strcmp. Например:

м) Не используйте оператор присвоения в месте, где его легко спутать с оператором проверки на равенство. Например:

Трудно понять, тольи программист хотел произвести присвоения, то ли ошибся и хотел сравнить переменные. Вместо этого используйте:

н) Не переопределяйте синтаксис языка С с помощью макрозамен/ #define BEGIN < Это сделает программу непонятной для всех, кроме автора замены, например:

Постарайтесь, чтобы структура вашей программы совпадала с вашими целями:

более понятно, если записано так:

в) Проверка на ненулевое значение:

даже если FAIL может иметь значение 0. Это поможет Вам позже, когда кто-нибудь решит, что возврат по ошибки -1 лучше, чем 0. Исключение можно сделать для функций, удовлетворяющих следующим ограничениям:

— не имеющих цель вернуть значения отличное от true или false,
— возвращающих 0 для false и 1 для true,
— названных так, что однозначно понято, что возвращено будет true, например is_valid or valid, а не check_valid.

г) Использование встроенных возможностей может улучшить производительность программы. Однако следует соблюдать компромисс между увеличением скорости и возможностью модификации программы. Например:

не стоит заменять на:

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

д) Если код содержит бинарные операции перед оператором «?» они должны помещаться в скобки:

е) Используйте lint для поиска неявных багов.

Указанный набор стандартов был приведён для стиля программирования на языке С++. Один из самых важных моментов – это использование пробелов и комментариев, делающее текст программы значительно лучше для восприятия.

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

Стиль программирования

Стиль программирования — набор приемов или методов программирования, которые используют программисты, чтобы получить правильные, эффективные, удобные для применения и легкочитаемые программы. См. также: Программирование Финансовый словарь Финам … Финансовый словарь

Стиль — Стиль: В Викисловаре есть статья «стиль» Стиль (писало, стило, стилос, стилус лат. … Википедия

Стиль отступов — Окно настроек форматирования KDevelop Стиль отступов правила форматирования исходного кода, в соответствии с которыми отступы проставляются в удобочитаемой манере. Используемый стиль отступов обычно особо оговаривается в стандар … Википедия

СТИЛЬ ЖИЗНИ — [англ. Lifestyle] в маркетинге совокупность целей и ценностей приобретения, а также направлений, способов и размеров использования разнообразных ресурсов, доступных человеку (биологических, социальных, материально финансовых, информационных и… … Маркетинг. Большой толковый словарь

Curl (язык программирования) — Curl Класс языка: мультипарадигменный: объектно ориентированный, разметка Появился в: 1998 Автор(ы): Стив Уорд, MIT Релиз: 7.0.0 Типизация данных … Википедия

Парадигма программирования — Парадигмы программирования Агентно ориентированная Компонентно ориентированная Конкатенативная Декларативная (контрастирует с Императивной) Ограничениями Функциональная Потоком данных Таблично ориентированная (электронные таблицы) Реактивная … Википедия

Интерпретируемый язык программирования — язык программирования, в котором исходный код программы не преобразовывается в машинный код для непосредственного выполнения центральным процессором (как в компилируемых языках), а исполняется с помощью специальной программы интерпретатора. В… … Википедия

Язык программирования Си (книга) — Эта статья о книге; о языке программирования см.: Си (язык программирования). Язык программирования Си The C Programming Language … Википедия

Рубин (язык программирования) — Ruby Семантика: мультипарадигмальный Тип исполнения: интерпретатор Появился в: 1995 г. Автор(ы): Юкихиро Мацумото Последняя версия: 1.9.1 … Википедия

Язык программирования Рубин — Ruby Семантика: мультипарадигмальный Тип исполнения: интерпретатор Появился в: 1995 г. Автор(ы): Юкихиро Мацумото Последняя версия: 1.9.1 … Википедия

Стиль программирования при написании программ

Хотя не существует жестких правил написания программ, однако можно дать общие рекомендации, которых целесообразно придерживаться с тем, чтобы программы были удобочитаемы не только самим разработчиком, но и другими программистами. Реализация этих правил позволяет быстрее понять суть работы программы, а также легче находить и исправлять ошибки, проще вносить в нее изменения (при необходимости).

Стиль программирования— набор приемов или методов программиро­вания, которые используют опытные программисты, чтобы получить надежные, эффективные, удобные для применения и легко читаемые программы. Правила хорошего стиля программирования — это результат соглашения между опытными программистами. Когда программист усвоит определенный стиль, его программа станет значительно легче для восприятия. Программа — это документ для последующего использования, учебный материал по кодированию алгоритмов и средство для дальнейшей разработки более совершенных программ. Следовательно, языки программирования должны обеспечивать возможность создания удобочитаемых совокупностей операторов. Язык Турбо Паскаль имеет такие средства обеспечения удобочитаемости.

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

Трудно читаемые программы обычно сложно модифицировать, особенно если это предстоит выполнять не самому автору программы.

Иногда легче полностью переписать чужую программу, чем ее модифицировать.

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

Дадим общие рекомендации. Они просты, не требуют для выполнения особых усилий и направлены на более четкую структуризацию программы. Суть их в следующем:

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

2. Не следует создавать большие текстовые файлы. Подпрограммы лучше компоновать в отдельные модули, размещая их в отдельные файлы. В этом случае при изменении какого-то одного модуля не нужно будет перекомпили­ровать все остальные.


3. При написании программы целесообразно использовать систему отступов, когда операторы, вложенные в другие операторы или в операторные скобки, пишутся в строке с отступом вправо-влево по отношению к другим операторам (обычно отступ делается в две-три позиции). Рекомендации здесь такие:

— зарезервированные слова типов данных (TYPE, VAR, CONST и т.д.) записывайте в первой позиции строки, а описываемые переменные — в следующей строке с отступом на несколько позиций;

— слова операторных скобок Begin-End, обозначающих соответствующий составной оператор, записывайте в одних и тех же позициях;

— операторы тела цикла сдвигайте правее относительно оператора цикла. Операторы внутренних циклов сдвигайте правее относительно операторов внешних циклов;

— в операторах условной передачи управления IF — THEN — ELSE слова THEN и ELSE, относящиеся к одному условию, целесообразно записывать одно под другим;

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

Такое расположение операторов позволяет разобраться со структурой программы, понять ее содержание, быстрее найти некоторые ошибки (напри­мер, отсутствие закрывающей операторной скобки END, соот­ветствующей открывающей скобке BEGIN). Примером такого расположения операторов являются программы и их фрагменты, приведенные в данном рабочем учебнике.

4. Не следует в одной строке объединять несколько операторов, за исключением простейших (А:=0; В:=А; Р:=0; и т.п.), так как это затруднит локализацию ошибки во время отладки программы, поскольку минимальный выполняемый блок команд в процессе отладки соответствует одной строке текста.

5. Делайте пробелы для улучшения читаемости программы. Широкое использование пробелов существенно облегчает чтение программы. Ставьте пробелы между элементами списка данных, а также до и после операций +, ‑, =. Иногда желательно отделять пробелами операции (*, /). Пробелы можно также использовать для указания приоритета операций. Например, запись вида I + А*В предпочтительнее, чем I+А * В.

6. Идентификаторы программы должны быть выразительными, т.е. обозначать сущность или сокращенное наименование параметров задачи. При написании идентификаторов следует широко использовать как строчные, так и прописные буквы, а также знак подчеркивания: MyProgram, File_of_Digits, Volumel, Razmer24 и т.д.

Не опасайтесь использовать длинные имена, т.к. через промежуточный буфер можно скопировать их необходимое число раз.

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

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

8. Следует использовать при написании программы возможность расцвечивания разными цветами различных ее элементов, что позволяет делать версия Турбо-Паскаль v.7.0. При этом проще проконтролиро­вать правильность использования зарезервированных слов языка, комментариев, вставок на ассемблере и т.д.

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

Малое количество скобок Дополнительные скобки

Основное правило такое: в сомнительных случаях всегда ставить скобки. Это не только сделает программу более понятной, но и предотвратит ошибки.

10. Во избежание неоднозначностей не следует локальным и глобальным параметрам давать одинаковые имена.

11. Пропуск строк — очень эффективный метод повышения наглядности программы. Последовательности операторов, выполняющих какое-то законченное действие, целесообразно отделять от предыдущих и последующих операторов пустыми строками. Пропуском строк можно разделить программу на отдельные фрагменты. Пропуском одной строки можно отделять каждую группу логически связанных операторов, пропуском двух строк отделяются основные логические фрагменты программы. Использование незаполненных строк облегчает поиск отдельных частей в программе. Пропуск строк до и после комментариев помогает выделить последние.

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

Редактор Турбо-Паскаля позволяет довольно легко выдерживать указанные рекомендации. Так, можно автоматически задавать отступы при написании программы, если в меню установлен параметр Option I Environment I Editor I Autoindent mode I.

Дата добавления: 2020-11-18 ; просмотров: 601 | Нарушение авторских прав

Стиль программирования. Выбор языка программирования

Программы должны составляться так, чтобы их могли прочитать в первую очередь люди, а не машины. Помните: программы читаются людьми, т.е. удобочитаемость программ — существенна, поэтому имеет смысл говорить о стандарте стиля программ.

Легко читаемая программа создает впечатление, что ее автор хорошо знал что делал.

Программа должна передавать логику и структуру алгоритма настолько, насколько это возможно.

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

Правило стандартизации стиля: если существует более одного способа сделать что — либо и выбор произвольный, остановись на одном способе и всегда его придерживайся.

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

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

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

Когда следует писать комментарий? В процессе написания программы. Бессмысленно вставлять комментарии, после того, как программа завершена.

Делайте комментариев больше, чем это кажется необходимым. Т.к. цель комментариев — облегчить понимание программы. Если вы затрудняетесь в написание комментария — значит “Вы не ведаете, что творите! ”

Три типа комментариев:

  • 1. вводные
  • 2. оглавление
  • 3. пояснительные.

Каждая программа, подпрограмма или процедура, должна начинаться с комментариев, поясняющих, что она делает. Минимальная информация, содержащаяся в вводных комментариях должна включать следующие пункты:

  • — Назначение программы.
  • — Указания по вызову программы и ее использованию.
  • — Список и назначение основных переменных или массивов.
  • — Указание по вводу — выводу. Список всех файлов.
  • — Список используемых подпрограмм.
  • — Назначение применяемых математических методов.
  • — (иногда) Сведения о времени выполнения программы.
  • — Требуемый объем памяти.
  • — Специальные указания оператору.
  • — Сведения об авторе.
  • — Дату написания программы.


Пояснениями нужно сопровождать те части программы, которые трудно понять без комментариев. Сопровождайте комментариями те действия, которые, с вашей точки зрения, могут быть не совсем понятны другому. Комментарии не должны объяснять синтаксис языка программирования, а должны раскрывать логику программы или цель конкретного действия. Если логика программы понятна только на основании прочтения комментариев, это качественные комментарии.

Комментарии легче читаются, если они отделяются пустыми строками (до и после комментариев). Дополнительный метод выделения комментариев — заключение их в прямоугольник из специальных символов (звездочки, слеши, скобки и т.д.). Располагаются комментарии т. о., чтобы это не делало программу менее наглядной. Неправильные комментарии хуже, чем их отсутствие. Делайте пробелы для улучшения читаемости программ.

Выбор имен переменных, файлов.

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

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

При записи операторов для указания связи между ними делают одинаковый отступ от начала строки. И хотя отступы не оказывают влияния на логику программы, существенно улучшают ее читаемость. Циклы — типичный случай для использования отступов.

  • — Для выявления структуры программы — используйте отступы.
  • — Если операторы занимают несколько строк, то строки, начиная со второй, должны иметь отступ чтобы находиться справа от знака равенства.

Выбор и обоснование языка программирования.

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

Трансляция — один из способов преодолеть “языковый” барьер. Если воспользоваться языком, понятным программисту, а потом обеспечить перевод с него в машинный код, проблема будет решена. Может показаться, что для этой цели лучше выбрать естественный язык, например, английский, но на самом деле удобнее сконструировать особый язык. На сегодняшний день создано много таких языков, которые названы — языки программирования высокого уровня.

Хорошо сконструированные языки высокого уровня обладают целым рядом достоинств, основанных на следующих фактах:

  • а) Средства, предоставляемые языком, позволяют удовлетворить потребности конкретной прикладной области. Например, один язык может быть разработан для научных, преимущественно численных расчетов, другой для коммерческих приложений, обрабатывающих много нечисловой информации, третий будет применяться в других прикладных областях.
  • б) В визуальном отношении программа должна быть такой, чтобы ее легко было читать, и чтобы была ясна ее структура. Проектирование и написание больших программ — сложная интеллектуальная задача, и для ее успешного решения программист должен предельно сосредоточиться на том, что он делает и ясно представлять себе задачу. Это очень полезно не только тому, кто пишет программу, но и особенно программисту, которому поручено ее усовершенствовать.
  • в) В язык могут быть (и даже должны быть) встроены средства, помогающие выявлять и предупреждать ошибки. Учитывая важность того, чтобы законченная программа была правильной, и принимая во внимание естественную подверженность программиста ошибкам, такие средства следует признать главным достоинством языков высокого уровня.

Отношение и эффективность.

Существует три типа программ и отношение к эффективности этих программ должно быть различным.

Первый тип — это часто используемые программы: операционные системы, компиляторы, трансляторы, прикладные программы. Для таких программ эффективность является первостепенной задачей, вследствие их частого использования и специфического выполнения. Второй тип — производственные программы, написанные профессиональными программистами, эксплуатируемые долгое время. Хотя эффективность таких программ существенна, обычно большее внимание уделяется их эксплуатационным характеристикам.

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

Следовательно: ещё до написания программы необходимо установить, насколько эффективной она должна быть.

Очевидно, что следует модифицировать только те программы, которые многократно повторяются (используются). «Не стоит экономить на спичках». Многие методы, делающие программу эффективной могут существенно влиять на ее удобочитаемость, а удобочитаемость программы более существенно, чем ее эффективность. В каком случае эффективности отдают предпочтение в ущерб удобочитаемости: если программа должна быть выточена в библиотеку часто используемых программ функции, программа не помещается в памяти, она важна, но слишком долго выполняется.

Если программу следует оптимизировать, необходимо тщательно проверить алгоритм.

Программу, подлежащую оптимизации следует разбить на подпрограммы (в соответствии с принципом структурного программирования). Если не возможно учесть время выполнения каждой подпрограммы подсчитайте количество операторов в подпрограмме, особенно выполненных в тело циклов. Ищите операторы, которые можно модифицировать — (do While и CASE) особенно это касается операторов цикла и ввода — вывода. Для каждой подпрограммы можно вычислить коэффициент: процент времени * процент улучшения. Программу с высоким коэффициентом следует оптимизировать в первую очередь. Здесь можно использовать два подхода: «чистка» (использование очевидных неточностей в исходной программе) и перепрограммирование (если подвергается подпрограмма существенным изменениям).

Эффективность выполнения программ.

Эффективность программы во время выполнения определяйте использованием двух ресурсов. Первый — необходимое для работы время, второй — понять, какая, требуется программа. Хорошей считается программа, которая выполняется при минимальном расходе минимального времени. Вопрос о распределении памяти не представляет интереса до тех пор, пока ее достаточно. Но когда памяти явно не хватает, вопрос об экономии становится очевидным. С широким внедрением ПК в быт, с использованием мультимедийных возможностей появилась еще больше необходимости деления памяти на участки различного размера.

Общее понятие о стилях программирования

Стили, их ипостаси, методологии, методики, технологии

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

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

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

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

Метод — сильное оружие, и поэтому наряду с большими достоинствами он обязательно имеет большие недостатки. В частности, применение метода требует достаточно высокого интеллектуального уровня и владения рядом навыков, прививаемых точными науками, в частности, умением переходить к абстрактному от конкретного и обратно. Поскольку подавляющее большинство специалистов не владеют мышлением на таком уровне, чтобы они могли применять метод в чистом виде, метод конкретизируют в методику .

Методика — это набор шаблонов, процедур и рецептов, конкретизирующих метод 3 В идеале это так. Но в жизни не всегда методика опирается на метод, чаще — на традиции. . Например, метод многоаспектного моделирования, положенный в основу UML ( Unified Modelling language ), конкретизирован в методику .

Примером методики служит общая часть RUP (Rational Unified Process). Сам UML лишь поставляет материал для конкретной методики : формы, в которых можно строить систему взаимосвязанных моделей, описывающих разные стороны создаваемой программы, и процедуры отладки таких описаний. Методикой может пользоваться уже значительное меньшинство 4 Здесь термин значительное меньшинство не является опиской: уже достаточно много, но еще не большинство. специалистов, поскольку ее применение требует элементарных операций конкретизации и композиции и доступно людям, владеющим комбинационным мышлением . Но для успешного применения в коллективе методика должна конкретизироваться далее.

Тот же самый RUP , помимо методики применения многоаспектных моделей, содержит часть, касающуюся регламента работы программистского коллектива согласно данной методике . Это — технология . В технологии расписываются действия, даются шаблоны документов, определяются роли и функции лиц, задействованных в проекте. Поскольку в программистских коллективах чернорабочий имеет квалификацию техника обычного «железного» производства, программистские технологии , в отличие от индустриальных, оставляют некоторый простор для конкретизации и модификации, давая возможность подставлять в шаблоны целые серии динамически определяемых конкретных действий. На «железном» производстве технология — строго определенная последовательность операций, примерно соответствующая отлаженной программе в программистском мире.

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

Но, кроме методов, есть еще два этажа. Первый из высших этажей начали рассматривать в 70-е гг. XX века. Это методологии программирования 5 Стоит заметить, что «методология» в программировании не согласуется с употреблением этого термина в обычной жизни и в производстве. Она соответствует парадигме в науке и технологической дисциплине в стандартном производстве. . Методология на самом деле ортогональна методам: это надстройка на другом крыле программистского здания. В этом случае достаточно сослаться на структурное программирование . Метод реализуется при помощи методологии и в ее рамках.


Второй из высших этажей впервые был систематически исследован в книге [ 22 ] . Он связан с тем, что в программировании мы имеем дело с намного более абстрактными и идеальными понятиями, чем в материальном производстве. Поэтому длина логических построений возрастает, сложность формализации используемых методов убывает, и мы в гораздо большей степени зависим от логики наших рассуждений, чем от «материи».

Логика построения отличается от логики оформления готовых рассуждений, которую преподают на стандартных курсах и на которой основана классическая версия математики. Уже с начала ХХ века в математике появилось конструктивное направление (вариантами которого являются, в частности, интуиционизм и советский конструктивизм), для которого главное не доказательство , а содержащееся в нем идеальное построение. Основатель конструктивного направления Л. Э. Я. Брауэр (Голландия) установил, что причины, по которым математическое доказательство не всегда дает построение, лежат в логике. Так появилось понятие конструктивной логики , в которой мы интересуемся не истинностью формул , а их реализуемостью (возможностью построения решения задачи заданными средствами).

В дальнейшем выяснилось, что разным классам средств и ресурсных ограничений соответствуют разные логики. Эти логики не просто расходятся, а противоречат друг другу. Для того чтобы сохранить хотя бы минимальную внутреннюю согласованность наших рассуждений в ходе построения сложного искусственного объекта (в нашем случае программы), нужно с самого начала определить класс средств и ресурсных ограничений, которые необходимо принимать во внимание.

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

Структурное программирование соответствует взгляду на вычислительную обстановку как на хранилище отдельных значений, связанных отношениями, и взгляду математики XIX века на мир как на то, что может быть описано числовыми характеристиками; роль программы при этом — вычисление новых значений по старым.

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

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

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

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

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

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

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

Действия Условия Стиль
Локальные Локальные Структурный
Глобальные Локальные Автоматный
Локальные Глобальные Событийный
Глобальные Глобальные Сентенциальный

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

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

В автоматном стиле имеется две ипостаси : последовательная и параллельная. Последовательная ипостась хороша, когда система представляется как единый блок информации, а параллельная — когда система делится на относительно автономные взаимодействующие подсистемы.

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

В событийном стиле имеются две ипостаси : от событий и от приоритетов. Здесь можно увидеть, что стиль появляется и существует независимо от языковой поддержки и порою даже вопреки ей.

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

Стиль программирования

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

Основные принципы форматирования

Основная теорема форматирования гласит, что хорошее визуальное форматирование показывает логическую структуру программы. Создание красивого кода — хорошо, а демонстрация структуры кода — лучше. Если одна методика лучше показывает структуру кода, а другая выглядит красивей, следует использовать ту, которая лучше демонстрирует структуру.

Форматирование — это ключ к структуре программы. Компьютеру важна исключительно информация о скобках или операторах begin и end, а читатель-человек склонен делать выводы из визуального представления кода. Взгляните на фрагмент кода, приведенный ниже, схема отступов в котором заставляет человека думать, что все три выражения выполняются при каждом проходе цикла.

// меняем местами правые и левые элементы во всем массиве

Стиль программирования

Узбекское Агентство
Связи и Информатизации

Ташкентский Университет Информационных Технологий

Кафедра
«Программное обеспечение информационных технологий»

Направления:

5521900 Информатика и
информационные технологии,
5523500 Защита информации,
5523600 Электронная коммерция,
5811200 Сервис (информационный сервис),
5811300 Сервис (электронные и
компьютерные технологии),
5320200 Информатика и
библиотековедение,
5140900 Профессиональное образование
(по направлению
информатика и
информационные технологии).

Выдержки из лекций

Глава 6. Стиль программирования

Под стилем программированияпонимается набор приемов или методов программирования, которые используют опытные прог­раммисты, чтобы получить правильные, надежные, эффек­тивные, удобные для применения и легко читаемые программы.

Правила хорошего стиля программирования — это результат соглашения между опытными программистами (маленький стан­дарт). Если бы все программисты придерживались своего инди­видуального стиля, то результатом было бы Вавилонское стол­потворение.

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

Слишком часто, стремясь побыстрее получить работающую программу, забывают о ее удобочитаемости. Трудночитаемые программы обычно сложно модифицировать. Особенно, если это приходится делать не автору программы. Как правило, к разра-ботке программы приступают со скромными целями, а в даль­нейшем расширяют ее возможности. Легко читаемая программа свидетельствует, что ее автор хорошо знал свое дело.

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

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

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

Илон Маск рекомендует:  Cnsearch плагины (plug ins)
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL