Рефакторинг и отладка кода (занятие 1)

1.

Рефакторинг и отладка кода
Занятие 1.
Преподаватель
Нефедова Л.П.

2.

• 18 часов теоретический курс (Тестирование)
• 18 часов практический курс (Отчеты по
практическим работам)
_______________________________
зачет

3.

Отчеты
обязательны!
• Один титульный лист на все практические
работы (образовательная организация,
дисциплина, ФИО студента, группа, ФИО
преподавателя, год).
• Содержательная часть отчета: название и №
работы, цель , отчет согласно требованиям,
ответы на вопросы, вывод.

4.

Планируемые результаты
Код
ОК 1.
ОК 2.
ОК 3
ОК 4
ОК 5
ОК 6
ОК 7
ОК 8
ОК 9
ОК 10
ОК 11
Наименование общих компетенций
Выбирать способы решения задач профессиональной деятельности, применительно к
различным контекстам
Осуществлять поиск, анализ и интерпретацию информации, необходимой для выполнения
задач профессиональной деятельности.
Планировать и реализовывать собственное профессиональное и личностное развитие.
Работать в коллективе и команде, эффективно взаимодействовать с коллегами, руководством,
клиентами
Осуществлять устную и письменную коммуникацию на государственном языке с учетом
особенностей социального и культурного контекста
Проявлять гражданско-патриотическую позицию, демонстрировать осознанное поведение на
основе традиционных общечеловеческих ценностей
Содействовать сохранению окружающей среды, ресурсосбережению, эффективно
действовать в чрезвычайных ситуациях.
Использовать средства физической культуры для сохранения и укрепления здоровья в
процессе профессиональной деятельности и поддержания необходимого уровня физической
подготовленности
Использовать информационные технологии в профессиональной деятельности.
Пользоваться профессиональной документацией на государственном и иностранном языке
Планировать предпринимательскую деятельность в профессиональной сфере
Код
Наименование профессиональных компетенций
ПК 1.3
Выполнять отладку программных модулей с использованием
специализированных программных средств
ПК 1.4
Выполнять тестирование программных модулей
ПК 1.5
Осуществлять рефакторинг и оптимизацию программного кода

5.

Изучаемые темы
• Стандарты оформления кода и инструменты
разработки
• Отладка программного кода
• Рефакторинг кода и проверка
работоспособности

6.

7.

Так ли это важно?
Оценивание демонстрационного экзамена 2024г

8.

Тема1. Общие сведения о стандартах оформления
кода. Методы усовершенствования кода.
Занятие 1
Приемы написания красивого и
понятного кода

9.

Смысл кода должен быть виден
из самого кода…

10.

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

11.

Стандарт оформления кода обычно принимается и
используется
разработчиком
(группой
разработчиков)
программного
обеспечения
для
единообразного оформления совместно используемого кода.
Целью принятия и использования стандарта является
упрощение восприятия программного кода человеком,
минимизация нагрузки на память и зрение при чтении
программы.
Образцом для стандарта кодирования может стать
набор соглашений, принятых в какой-либо распространённой
печатной работе по языку (например, стандарт кодирования
на языке Си, получивший сокращённое наименование K&R,
происходит из классического описания Си его авторами),
широко применяемая библиотека или API (так, на
распространение венгерской нотации явно повлияло её
использование в MS-DOS и Windows API, а большинство
стандартов кодирования для Delphi используют, в той или
иной мере, манеру кодирования библиотеки VCL).

12.

Реже разработчик языка выпускает
подробные рекомендации по кодированию.
Например,
выпущены
стандарты
кодирования на C# от Microsoft и на Java от Sun.
Предложенная разработчиком или принятая в
общеизвестных источниках манера кодирования
в большей или меньшей степени дополняется и
уточняется в корпоративных стандартах.
Стандарт оформления кода — Википедия
(wikipedia.org)

13.

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

14.

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

15.

*Самостоятельно
1. Что такое Документирующие
комментарии?
2. О каких магических числах должны знать
программисты?
3. Что такое Спагетти-код?

16.

• Документирующий комментарий — это особым образом
оформленный
комментарий
к
объекту
программы,
предназначенный для использования каким-либо конкретным
генератором документации. От того, какой генератор
документации применяется, зависит синтаксис конструкций,
используемых в документирующих комментариях.
• В документирующих комментариях может содержаться
информация об авторе кода, описываться назначение объекта
программы, смысл входных и выходных параметров — для
функции/процедуры, примеры использования, возможные
исключительные ситуации, особенности реализации.
• Документирующие комментарии, как правило, оформляются
как многострочные комментарии в стиле языка Си. В каждом
случае
комментарий
должен
находиться
перед
документируемым
элементом.
Первым
символом
в
комментарии (и в начале строк комментария) должен быть *.
Блоки разделяются пустыми строками.
• :
• /** * Имя или краткое описание объекта * * Развернутое
описание * * @имя_дескриптора значение * @return
тип_данных */

17.

Пример документирующего комментария
на языке PHP

18.

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

19.

Часто «магическими числами» называют плохую практику
программирования, когда в исходном тексте встречается числовое значение
и неочевиден его смысл.
Например, такой фрагмент, написанный на Java, будет плохим:
drawSprite(53, 320, 240);
Тому, кто не писал программу, трудно понять, что такое 53, 320 или 240.
Но если этот код переписать, всё становится на свои места.
final int SCREEN_WIDTH = 640;
final int SCREEN_HEIGHT = 480;
final int SCREEN_X_CENTER = SCREEN_WIDTH / 2;
final int SCREEN_Y_CENTER = SCREEN_HEIGHT / 2;
final int SPRITE_CROSSHAIR = 53;
...
drawSprite(SPRITE_CROSSHAIR, SCREEN_X_CENTER, SCREEN_Y_CENTER);
Теперь понятно: этот код выводит в центр экрана спрайт — перекрестие
прицела. В большинстве языков программирования все значения,
используемые для таких констант, будут вычислены ещё на этапе
компиляции и подставлены в места использования значений (свёртка
констант). Поэтому такое изменение исходного текста не ухудшает
быстродействие программы.

20.

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

21.

Например,
любой
откомпилированный
класс
языка Java начинается с шестнадцатеричного «магического
числа» 0xCAFEBABE.
Второй широко известный пример — любой
исполняемый файл ОС Microsoft Windows с расширением
.exe начинается с последовательности байт 0x4D5A (что
соответствует ASCII-символам MZ — инициалы Марка
Збиковски, одного из создателей MS-DOS).
Менее
известным
примером
является
неинициализированный указатель в Microsoft Visual C++
(начиная с 2005 версии Microsoft Visual Studio), который в
режиме отладки имеет адрес 0xDEADBEEF.
В UNIX-подобных операционных системах тип файла
обычно определяется по сигнатуре файла, вне
зависимости от расширения его названия. Для
интерпретации сигнатуры файла в них предусматривается
стандартная утилита file.

22.

Спагетти-код (также индусский код) — плохо
спроектированная, слабо структурированная, запутанная и
трудная для понимания программа, особенно содержащая
много операторов GOTO (как правило, переходов
назад),
исключений
и
других
конструкций,
ухудшающих
структурированность.
Самый
распространённый антипаттерн программирования.
Спагетти-код назван так, потому что ход выполнения
программы похож на миску спагетти, то есть извилистый и
запутанный. Иногда называется «кенгуру-код» (kangaroo
code) из-за множества инструкций «jump».
В настоящее время термин применяется не только к
случаям злоупотребления GOTO, но и к любому
«многосвязному» коду, в котором один и тот же
небольшой фрагмент исполняется в большом количестве
различных ситуаций и выполняет очень много различных
логических функций.

23.

Спагетти-код обычно возникает от:
• неопытности разработчиков;
• давления по срокам, установленного руководством
(например, в принятой в компании системе
мотивации на «работу быстрее»)];
• давления по срокам, установленного
разработчиком самому себе (желание всё сделать
наиболее быстрым способом);
• оптимизации времени исполнения программы.
При этом не является результатом преднамеренного
запутывания.

24.

Стандарты кодирования
и синтаксис языков
Основные принципы распространённых стандартов
кодирования в последнее время оказывают влияние на
синтаксис вновь создаваемых языков программирования. В
некоторых из них соглашения, ранее применявшиеся только
в
стандартах
кодирования,
стали
обязательными
элементами синтаксиса. Так, в некоторых современных
языках (Python, Nemerle) отступы влияют на логику
исполнения (то есть блоки кода выделяются не ключевыми
словами, а размером отступов), в других (Ruby) — частью
языка стали соглашения о регистре букв и префиксах для
типов, констант, переменных и полей классов. Если ранее
недисциплинированный программист мог игнорировать
стандарты кодирования из личных соображений, ради
удобства или скорости написания кода, то теперь, при работе
на новых языках, соблюдение стандартов в определённой
мере контролируется транслятором.

25.

По соглашению программы C# применяют «Паскаль
Кейс» для имен типов, пространства имен и всех открытых
членов. Плюс команда dotnet/docs пользуется такими
соглашениями (были приняты из стиля кодирования команды
среды выполнения .NET):
• Названия интерфейсов начинают с большой буквы I.
• Все виды атрибутов заканчиваются «Attribute».
• Все виды перечисления применяют единственное
существительное для нефлагов и множественное
существительное для флагов.
• Идентификаторы не могут включать 2 последовательных
символа подчеркивания (_).
• Выбирать значимые и описательные имена для переменных,
методов, классов.
• Не применять имена с одной буквой, кроме простых счетчиков
циклов.
• Ясность важнее краткости.
• Применяйте «Паскаль Кейс» для имен классов и методов,
а также для имен констант, полей.

26.

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

27.

Американский космический турист.
Глава и основатель компании
Intentional Software. Участник двух
космических полётов на российских
кораблях
Союз
ТМА
к
Международной
космической
станции.
Автор венгерской нотации.

28.

Cтили написания составных слов
CamelCase — стиль написания составных
слов, при котором несколько слов пишутся
слитно без пробелов, при этом каждое слово
пишется с заглавной буквы. Стиль получил
название CamelCase, поскольку заглавные буквы
внутри слова напоминают горбы верблюда.
Альтернативным способом создания имён в
программном код spinal_case (несколько слов
разделяются символом нижнего подчеркивания
'_') и snake-case (используется тире '-').

29.

CamelCase — первое слово может начинаться с
маленькой буквы, используется для именования
переменных и функций во многих языках.
PascalCase — соглашение, когда каждое слово
начинается с большой буквы. Как правило,
применяется для наименования классов.
Snake_case применяется для имен полей баз
информации, переменных и функций.
Kebab-case —вместо пробела используется
дефис. Применяется в URL и CSS. В языке «Лисп»
таким образом пишутся все названия.

30.

Вывод
• Код — это «текст», написанный на одном
из языков программирования.
• Программы для ПК, игровые проекты и вебсайты работают по правилам, которые
содержатся в коде. А он влияет на внешний
вид, внутреннюю структуру. Еще код
анализирует задачу и решает ее.
• Чистый код — это хороший код. Он написан
просто и без излишеств, без дублей. Его
структура построена так, чтобы его было легко
читать и людям, и ПК.