Цель: сформировать умение составлять грамотно программный код.
Задачи:
1.Разработать консольное программное приложение по индивидуальному заданию, в оформлении которого должны использоваться следующие правила:
- форматирование с отступами и пробелами (расстановка блоков оператора начала и конца, пробелы вокруг символов в формулах);
- выбора имен переменных (язык, имена переменных и функций, префиксы, грамотное использование сокращений);
- комментарии.
2. Провести анализ (заполнить таблицы 1 и 2) оценки стилевого оформления кода программы.
3. Составить отчет в соответствии с требованиями СТО 02069024.101-2015, схемы алгоритма программы должны быть составлены в соответствии с ГОСТ 19.701-90. Отчет должен содержать: титульный лист, содержание, ход выполнения работы, схема алгоритма программы, текст программы в приложении.
Теоретические предпосылки:
Стиль программирования является важной составляющей кодирования программы. Создаваемый программный код должен быть понятным и удобным, то есть удобочитаемым. Стиль программирования является результатом соглашения между опытными программистами.
Любая программа должна иметь четкую структуру, содержать понятное именование переменных, сопровождаться подробными комментариями (пояснительные, вводные, оглавления для подпрограмм).
Программисты самого большого сообщества GNU фонда Free Software Foundation используют следующий стиль программирования:
1. Язык.
Использование англоязычных идентификаторов (например, не dengi, а pay). Знание английского языка для программиста необходимо.
2. Имена переменных и функций
Необходимо использовать понятные имена, не слишком сокращенные и не слишком длинные. Короткие названия переменных необходимо использовать только для именования индексных переменных в теле цикла или в качестве локальной переменной небольшой процедуры.
Рисунок 1 - Примеры "Плохого" и "Хорошего" стиля программирования
Например, необходимо именовать функцию "Убрать из строки все пробелы". Если вы назовете ее "strst", то в дальнейшем без комментариев будет очень сложно быстро понять, что эта функция делает. Одним из вариантов решения является использования имени - "StrRemoveSpaces".
Такой подход делает программу самодокументируемой и в таком случае можно обойтись от комментариев. Но тут другая проблема, что использовать данный способ следует с осторожностью, иначе сложные функции будут неудобочитаемыми и программа нагроможденной (Например, "RemoveAllSpacesFromThisString"). Такое именование функций используется в WinAPI.
В программировании константы традиционной записываются в верхнем регистре, например, COLO_BOT.
Конвенции C
Конвенции именования, используемые при программировании на C, предполагают, что:
- имена символьных переменных дополняются префиксом c или ch;
- целочисленным индексам присваиваются имена i и j;
- имена переменных, хранящих количество чего-либо, дополняются префиксом n_;
- имена указателей дополняются префиксом p_;
- имена строк начинаются с префикса s_;
- имена макросов препроцессора включают ТОЛЬКО_ЗАГЛАВНЫЕ_БУКВЫ; обычно это правило распространяется и на имена типов, определяемых при помощи директивы typedef;
- имена переменных и методов включают только_строчные_буквы;
- для разделения слов служит символ подчеркивания (_): имена_такого_вида читаются легче, чем именатакоговида.
Пример конвенции именования для языка С:
Эти правила справедливы для программирования на C в общем, а также для сред UNIX и Linux, однако в разных средах конвенции имеют свои особенности. Программисты на C, разрабатывающие программы для Microsoft Windows, предпочитают применять для именования переменных ту или иную форму венгерской нотации и буквы верхнего и нижнего регистров.
Ключевые моменты
1. Выбор хороших имен переменных — одно из главных условий понятности программы. С отдельными типами переменных — например, с индексами циклов и переменными статуса — связаны свои принципы именования.
2. Имена должны быть максимально конкретны. Имена, которые из-за невыразительности или обобщенности можно использовать более чем с одной целью, обычно являются плохими.
3. Конвенции именования позволяют провести различие между локальными данными, данными класса и глобальными данными, а также между именами типов, именованных констант, перечислений и переменных.
4. Над каким бы проектом вы ни работали, вам следует принять конвенцию именования переменных. При выборе типа конвенции следует учитывать размер программы и число работающих над ней программистов.
5. Современные языки программирования позволяют отказаться от сокращения имен. Если вы все-таки сокращаете имена, регистрируйте аббревиатуры в словаре проекта или используйте стандартизированные префиксы.
6. За чтением кода программисты проводят гораздо больше времени, чем за его написанием. Выбирайте имена так, чтобы они облегчали чтение кода, пусть даже за счет удобства его написания.
3. Префиксы
Традиционно использование префиксов удобно для восприятия. Так, например, если есть переменная типа DWORD, переменная с данным типом записывается как "dwMyVar", то есть название переменных начинается с символов ее типа.
Рекомендуется именовать глобальные переменные с префиксом g_... ("g_dwMyVar").
Переменные класса в MFC (Microsoft Foundation Classes) начинаются с префикса m_...
Существует множество таблиц префиксов переменных, каким следовать - решать разработчику. Главное, чтобы в команде разработчиков все придерживались одной таблицы.
4. Использование сокращений
Не стоит увлекаться использованием сокращений и аббревиатур в именовании идентификаторов, исключением могут быть только "общепринятые" сокращения, например: str -> string, src -> source, tbl -> table и т.д., так как если написать вместо server - srv, может или получиться путаница (возможно это означает - service), или другой программист этого сокращения вообще не поймет.
5. Именование в составе класса
Допустим вы написали класс с именем "CFile", выполняющий некоторые операции с файлом. Избыточно называть методы этого класса так: CFile::FileOpen() или CFile::FileClose(), ведь и так понятно, что класс работает с файлом. Tак и короче и логичней: CFile::Open(), CFile::Close().
6. Расстановка операторов начала и конца блока {} и отступы
Внутри любых управляющих конструкций операторы следует располагать с отступом на одинаковое количество пробелов (рисунок 2)
Рисунок 2 - Расстановка операторов начала и конца блока
Ниже я привел несколько рекомендаций по сокращению имен. Некоторые из них противоречат другим, так что не пытайтесь использовать все советы сразу. Итак:
- используйте стандартные аббревиатуры (общепринятые, которые можно найти в словаре);
- удаляйте все гласные, не являющиеся первыми буквами имен (computer — cmptr, screen — scrn, apple — appl, integer — intgr);
- удаляйте артикли и союзы, такие как and, or, the и т. д.;
- сохраняйте одну или несколько первых букв каждого слова;
- «обрезайте» слова согласованно: после первой, второй или третьей буквы (выбирайте вариант, уместный в конкретном случае);
- сохраняйте первую и последнюю буквы каждого слова;
- сохраняйте до трех выразительных слов;
- удаляйте бесполезные суффиксы: ing, ed и т. д.
- сохраняйте наиболее выразительный звук каждого слога;
- проверяйте, чтобы смысл имени переменной в ходе сокращения не искажался;
- используйте эти способы, пока не сократите имя каждой переменной до 8–20 символов или до верхнего предела, ограничивающего длину имен в конкретном языке.
7. Пробелы вокруг символов
Бинарные операторы следует оформлять пробелами:
Символ пробела ассоциируется с новым словом, поэтому формула читается не как непонятный набор символов, а как нечто осмысленное.
8. Комментарии
Расставлять комментарии надо по принципу "чем больше - тем лучше" - через некоторые время и не только другой программист, но и вы сами забудете что делает тот или иной программный блок в вашей программе. Принято комментировать код на английском языке. Или в крайнем случае транслитом. Если программа только для себя, то можно писать на любом удобном языке.
К хорошему тону относится использование однострочных комментариев для короткого комментария, а многострочного - для комментария, охватывающего несколько строк. Также можно использовать однострочные комментарии для большого текста, особенно в начале файла или важного блока кода.
При расстановке однострочных комментариев возможно два варианта:
непосредственно перед выполняемым оператором
и после точки с запятой
echo "Hello world!"; // Вывод текстовой строки в окно браузера
Лучше придерживаться первого правила, так как строка получается длинной и плохо воспринимается читающим. Единственным, где можно использовать второй вариант является закрывающая скобка длинного оператора, содержащего множество вложенных блоков.
Ключевые моменты
Вопрос о том, стоит ли комментировать код, вполне обоснован. При плохом выполнении комментирование является пустой тратой времени и иногда причиняет вред. При грамотном применении комментирование полезно.
Основная часть критически важной информации о программе должна содержаться в исходном коде. На протяжении жизни программы актуальности исходного кода уделяется больше внимания, чем актуальности любого другого ресурса, поэтому важную информацию полезно интегрировать в код.
Хороший код сам является самой лучшей документацией. Если код настолько плох, что требует объемных комментариев, попытайтесь сначала улучшить его.
Комментарии должны сообщать о коде что-то такое, что он не может сообщить сам — на уровне резюме или уровне цели.
Некоторые стили комментирования заставляют выполнять много нудной канцелярской работы. Используйте стиль, который было бы легко поддерживать.
9. Переменные в функциях и составные переменные
Допустим, существует функция, которая имеет 10 переменных:
MyFunc (a,b,c,d,e,f,g,h,i,j)
При вызове такой функции очень сложно визуально определить где какой параметр располагается. Для отделения параметров используются новые строки, иногда сопровождаемые комментариями:
Варианты заданий:
Написать программу, которая выполняет вычисление по следующей формуле (Задание 1) и вывод определенных действий (Задание 2):
| № варианта | Задание 1 | Задание 2 |
| 1 | 
| С клавиатуры вводится число в диапазоне 1..6. Вывести название соответствующего Месяца на экран и записать в файл. |
| 2 | 
| Ввести с клавиатуры число от 1 до 5. Вывести на экран и записать в файл его словесную расшифровку, то есть 1 – один, 2 – два и т.д. |
| 3 | 
| Вводится с клавиатуры номер буквы в алфавите (от 1 до 8). Вывести эту букву на экран и в файл. |
| 4 | 
| Вводится с клавиатуры буква (от а до я). Вывести номер этой буквы в алфавите. |
| 5 | 
| Вводится с клавиатуры возраст ребенка 5, 6, 7, 8. Вывести на экран и в файл имя ребенка – соответственно Оля, Миша, Сережа, Костя |
| 6 | 
| Вводится с клавиатуры число от 7 до 12. Вывести название соответствующего месяца. |
| 7 | 
| С клавиатуры вводится число (1-5). Вывести на экран Лето, Зима, Осень, Весна, Межсезонье соответственно |
| 8 | 
| Вводится с клавиатуры порядковый номер студента вашей группы. Вывести на экран Фамилию и инициалы. |
| 9 | 
| Вводится с клавиатуры число от 1 до 7.Вывести на экран и в файл день недели. |
| 10 | 
| Вводится с клавиатуры строка. Необходимо подсчитать количество символов. |
| 11 | 
| Вводится с клавиатуры строка. Необходимо вывести на экран и в файл все гласные буквы. |
| 12 | 
| Вводится с клавиатуры номер (1 до 7). Вывести на экран и файл 1- "1 пара", "2 пара",... |
| 13 | 
| Вводится с клавиатуры буква латинского алфавита. Вывести на экран и в файл номер этой буквы в алфавите. |
Таблица 1 - Контрольный список "Именование переменных"
| Контрольный список: именование переменных | Да | Нет |
| Общие принципы именования переменных | ||
| Описывает ли имя представляемую переменной сущность полно и точно? | ||
| Характеризует ли имя проблему реального мира, а не ее решение на языке программирования? | ||
| Имеет ли имя длину, достаточную для того, чтобы над ним не нужно было ломать голову? | ||
| Спецификаторы вычисляемых значений находятся в конце имен? | ||
| Используются ли в именах спецификаторы Count или Index вместо Num? | ||
| Именование конкретных видов данных | ||
| Выразительные ли имена присвоены индексам циклов (более ясные, чем i, j и k, если цикл содержит более одной-двух строк или является вложенным)? | ||
| Всем ли «временным» переменным присвоены выразительные имена? | ||
| Можно ли по именам булевых переменных понять, какой смысл имеют значения «истина» и «ложь»? | ||
| Включают ли имена элементов перечислений префикс или суффикс, определяющий принадлежность элемента к перечислению — например, префикс Color_ в случае элементов Color_Red, Color_Green, Color_Blue и т. д.? | ||
| Именованные константы названы в соответствии с представляемыми абст- рактными сущностями, а не конкретными числами? | ||
| Короткие имена | ||
| Стараетесь ли вы не сокращать имена без необходимости? | ||
| Избегаете ли вы сокращения имен только на одну букву? | ||
| Все ли слова вы сокращаете согласованно? | ||
| Легко ли произнести выбранные имена? | ||
| Избегаете ли вы имен, допускающих неверное прочтение или произношение? | ||
| Документируете ли вы короткие имена при помощи таблиц преобразования? | ||
| Распространенные проблемы именования. Избежали ли вы… | ||
| …имен, которые вводят в заблуждение? | ||
| …имен с похожими значениями | ||
| …имен, различающихся только одним или двумя символами? | ||
| …имен, имеющих похожее звучание? | ||
| …имен, включающих цифры? | ||
| …имен, намеренно написанных с ошибками с целью сокращения? | ||
| …имен, при написании которых люди часто допускают ошибки? | ||
| …имен, конфликтующих с именами методов из стандартных библиотек или предопределенными именами переменных? | ||
| …совершенно произвольных имен? | ||
| …символов, которые можно спутать с другими символами? |
Таблица 2 - Контрольный список "Хорошие методики комментирования".
| Контрольный список: Хорошие методики комментирования | Да | Нет |
| Общие аспекты | ||
| Может ли программист, взглянувший на код, сразу понять его? - Объясняют ли комментарии цель кода или резюмируют ли они выполняе- мые в коде действия вместо того, чтобы просто повторять код? - Используете ли вы процесс программирования с псевдокодом для сокращения времени комментирования? - Переписали ли вы хитрый код вместо того, чтобы комментировать его? - Актуальны ли комментарии? - Ясны ли комментарии? Корректны ли они? - Позволяет ли стиль комментирования с легкостью изменять комментарии? | ||
| Операторы и абзацы | ||
| Избегаете ли вы комментариев в концах строк? - Стремитесь ли вы отвечать в комментариях на вопрос «почему», а не «как»? - Готовят ли комментарии читателя к последующему коду? - Каждый ли комментарий важен? Были ли удалены или улучшены избыточ- ные, посторонние и неуместные комментарии? - Документируете ли вы сюрпризы? - Избегаете ли вы сокращений? - Ясно ли различие между общими и детальными комментариями? - Комментируете ли вы недокументированные возможности или код, предот- вращающий ошибки языка или среды? | ||
| Объявления данных | ||
| Указываете ли вы единицы измерения данных в местах объявления данных? - Указываете ли вы диапазоны допустимых значений численных величин? - Комментируете ли вы смысл закодированных значений? - Комментируете ли вы ограничения входных данных? - Документируете ли вы флаги до уровня отдельных битов? - Комментируете ли вы каждую глобальную переменную в месте ее объявления? - Поясняете ли вы при каждом использовании глобальной переменной ее глобальный характер при помощи конвенции именования, комментария или обоих способов? - Заменили ли вы магические числа на именованные константы или перемен- ные, вместо того чтобы ограничиться простым документированием? | ||
| Управляющие структуры | ||
| Комментируете ли вы каждый управляющий оператор? - Комментируете ли вы концы длинных или сложных управляющих структур или упрощаете ли вы эти структуры по мере возможности, чтобы они не требовали комментариев? | ||
| Файлы, классы и программы | ||
| Включает ли программа краткий документ, подобный документу Книжной па- радигмы, предоставляющий общую информацию об организации программы? - Описали ли вы назначение каждого файла? - Указали ли вы в листинге фамилию и имя автора, адрес электронной поч- ты и номер телефона? |
Контрольные вопросы:
1.Для чего нужно придерживаться определенного стиля программирования?
2. Для чего нужны отступы и пробелы при форматировании программного кода?
3. Каких правил следует придерживаться при выборе переменных?
4. Какие особенности конвенции С?
5. Для чего необходимо использовать комментарии в программном коде? Как в С# обозначаются комментарии? Как следует использовать комментарии в программном коде?