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

Обновлено: 04.07.2024

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

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

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

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

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

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

В процессе доказательства пытаются выяснить, все ли проявления ошибки объясняет данная гипотеза, если не все, то либо гипотеза не верна, либо ошибок несколько.

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

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

10.3. Методы и средства получения дополнительной информации

Для получения дополнительной информации об ошибке можно выполнить добавочные тесты или использовать специальные методы и средства:

• интегрированные средства отладки;

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

добавления или удаления операторов область затирания может сместиться в другое место и ошибка либо перестанет проявляться, либо будет проявляться по-другому.

Интегрированные средства отладки. Большинство современных сред программирования (Delphi, Builder C++, Visual Studio и т. д.) включают средства отладки, которые обеспечивают максимально эффективную отладку. Они позволяют:

• выполнять программу по шагам, причем как с заходом в подпрограммы, так и выполняя их целиком;

• предусматривать точки останова;

• выполнять программу до оператора, указанного курсором;

отображать содержимое любых переменных при пошаговом выполнении;

На рис. 10.5 показан вид программы в момент перехода в режим пошагового выполнения по достижении точки останова в Delphi. В этот момент программист имеет возможность посмотреть значения интересующих его переменных.

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

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

Для уточнения природы ошибки возможен анализ машинных кодов, флагов и представления программы и значений памяти в 16-ричном виде (рис. 10.6).

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

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

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

Подготовка кода к отладке с помощью анализатора кода интегрированной среды разработки

Исправление исключений (ошибки времени выполнения)

Минимизация ошибок путем написания кода с учетом его предназначения (с помощью оператора assert)

Аспекты использования отладчика

Создание примера приложения с некоторыми ошибками

Установите Visual Studio бесплатно со страницы скачиваемых материалов Visual Studio, если еще не сделали этого.

Запустите Visual Studio.

Visual Studio создаст консольный проект и откроет его в обозревателе решений (правая область).

Замените код по умолчанию в файле Program.cs проекта на пример кода ниже.

Ищите красные и зеленые волнистые линии!

Ошибка, представленная красной волнистой линией

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

Проверяйте лампочку!

Исправление кода с помощью лампочки

Если щелкнуть этот элемент, Visual Studio добавит оператор using System.Text в начало файла Program.cs, а красная волнистая линия исчезнет. (Если вы не уверены, что именно делает предложенное исправление, выберите ссылку Просмотреть изменения справа перед его применением.)

Исправление оставшихся ошибок и предупреждений

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

Ошибка преобразования типа

Так как анализатор кода не может угадать ваше намерение, в данном случае лампочки, которые могут помочь вам, отсутствуют. Чтобы устранить эту ошибку, необходимо знать предназначение кода. В этом примере легко заметить, что points должен быть числовым (целочисленным) значением, так как вы пытаетесь добавить points в totalpoints .

Чтобы устранить эту ошибку, измените член points класса User с такого:

Красные волнистые линии в редакторе кода исчезают.

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

Зеленая волнистая линия исчезает.

Исправление исключения

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

Начать отладку

Нажмите клавишу F5 (Отладка > Начать отладку) или кнопку Начать отладку на панели инструментов отладки.

Возникает исключение SerializationException

При возникновении исключения необходимо задать себе пару вопросов:

Может ли это исключение возникнуть у пользователей?

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

Ниже приведено несколько важных советов по обработке исключений:

Старайтесь не использовать пустой блок catch, например catch (Exception) <> , который не принимает соответствующее действие для предоставления или обработки ошибки. Пустой или неинформативный блок catch может скрывать исключения и усложнять, а не упрощать отладку кода.

Используйте блок try/catch вокруг конкретной функции, которая вызывает исключение ( ReadObject в примере приложения). Если использовать его вокруг большого фрагмента кода, вы в итоге скроете расположение ошибки. Например, не используйте блок try/catch вокруг вызова родительской функции ReadToObject , как показано здесь, или вы не сможете точно определить, где возникло исключение.

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

Для данного примера приложения исправьте SerializationException в методе GetJsonData , изменив 4o на 40 .

Уточнение предназначения кода с помощью оператора assert

Значение NULL в выходных данных

Можно заметить, что с выходными данными что-то не так. Значения name и lastname для третьей записи пусты.

Это подходящий момент, чтобы рассмотреть полезный и часто недооцененный подход к написанию кода, который заключается в использовании операторов assert в функциях. Добавив приведенный ниже код, вы включаете проверку во время выполнения, чтобы убедиться, что firstname и lastname отличаются от null . Замените приведенный ниже код в методе UpdateRecords :

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

  • Для имени требуется допустимая строка.
  • Для фамилии требуется допустимая строка.

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

Код assert активен только в отладочной сборке.

При перезапуске отладчик приостанавливает выполнение на операторе assert , так как выражение users[i].firstname != null вычисляется как false вместо true .

Оператор assert разрешается в значение false

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

В сценариях, где вы вызываете метод для значения null , возникает NullReferenceException . Обычно следует избегать использования блока try/catch для общего исключения, то есть исключения, не привязанного к определенной функции библиотеки. Любой объект может вызывать NullReferenceException . Если вы не уверены, изучите документацию по функции библиотеки.

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

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

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

Оператор assert можно использовать с любым видом выражения, которое разрешается в true или false . Например, можно добавить оператор assert следующего вида.

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

Проверка кода в отладчике

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

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

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

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

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

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

Исправление проблем производительности

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

Следующие шаги

В этой статье вы узнали, как предотвращать и устранять многие распространенные ошибки в коде и когда использовать отладчик. Далее вы можете подробнее узнать об использовании отладчика Visual Studio для исправления ошибок.

Отладка программы

Отладка, как мы уже говорили, бывает двух видов:

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

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

Отладка - это процесс локализации и исправления ошибок в программе.

Принципы отладки

Принципы локализации ошибок:

· Большинство ошибок обнаруживается вообще без запуска программы - просто внимательным просматриванием текста.

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

· Чрезвычайно удобные вспомогательные средства - это отладочные механизмы среды разработки: трассировка, промежуточный контроль значений. Можно использовать даже дамп памяти, но такие радикальные действия нужны крайне редко.

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

Принципы исправления ошибок еще больше похожи на законы Мерфи:

· Там, где найдена одна ошибка, возможно, есть и другие.

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

· Наша задача - найти саму ошибку, а не ее симптом.

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

· Исправляя одну ошибку, очень легко внести в программу еще парочку. "Наведенные" ошибки - настоящий бич отладки.

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

Методы отладки.

1. Силовые методы

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

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

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

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

Суммируя свойства силовых методов, получаем практические советы:

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

o использовать отладочную печать в небольших количества и "по делу";

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

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

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

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

5. Метод тестирования.

· Метод индукции.
Индукция - это анализ от частного к целому. Просматривая симптомы ошибки, установленные одним или несколькими тестами и взаимосвязи между ними, можно обнаружить причину ошибки.

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

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

Автоматизированные средства отладки программ.

Стандартные возможности отладчика. Контроль правильности написанной программы (этапы).

Средства отладки

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

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

3) Непосредственное слежение:

· арифметическое (за тем, чему равны, когда и как изменяются выбранные переменные),

· логическое (когда и как выполняется выбранная последовательность операторов),

· контроль выхода индексов за допустимые пределы,

· отслеживание обращений к переменным,

· отслеживание обращений к подпрограммам,

· проверка значений индексов элементов массивов и т.д.

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

· просмотреть текущие значения переменных, состояние памяти, участок алгоритма, где произошел сбой;

· прервать выполнение программы;

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

Автономное тестирование модуля целесообразно осуществлять в четыре последовательно выполняемых шага.

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

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

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

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

Советы отладчику

1) Проверяйте тщательнее: ошибка скорее всего находится не в том месте, в котором кажется.

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

3) Тщательнее следить за объявлениями констант, типов и переменных, входными данными.

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

5) Анализировать код, начиная с самых простых вариантов. Чаще всего встречаются ошибки:

· значения входных аргументов принимаются не в том порядке,

· переменная не проинициализирована,

· при повторном прохождении модуля, перемен ная повторно не инициализируется,

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

· скобки в сложном выражении расставлены неправильно.

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

7) Ошибка, скорее всего окажется вашей и будет находиться в тексте программы. Гораздо реже она оказывается:

· электропроводке в здании и т.д.

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

8) Убедитесь, что исходный текст программы соответствует скомпилированному объектному коду (текст может быть изменен, а запускаемый модуль, который вы тестируете - скомпилирован еще из старого варианта).

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

10) Старайтесь не жалеть времени, чтобы уясненить причину ошибки. Это поможет вам:

· обнаружить другие ошибки того же типа,

· не делать их в дальнейшем.

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

12) Самые труднообнаруживаемые ошибки - наведенные, то есть те, что были внесены в код при исправлении других.

оверкой называется проверка результатов тестирования самой тестируемой программой

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

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

Отладка программы

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

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

отладка программы

Синтаксические ошибки

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

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

Семантические ошибки

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

Рассмотрим данный пример:

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

3 + 5, заключенные в скобки, дадут желаемый результат, а именно 48.

Ошибки в процессе выполнения

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

Вот хороший пример:

Фрагмент кода выше будет скомпилирован успешно, но input 25 приведет к ZeroDivisionError. Это ошибка во время выполнения. Другим популярным примером является StackOverflowError или IndexOutofBoundError. Важно то, что вы идентифицируете эти ошибки и узнаете, как с ними бороться.

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

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

Отладка программы

Вот несколько советов о том, как правильно выполнять отладку:

  1. Использовать Linters. Linters – это инструменты, которые помогают считывать исходный код, чтобы проверить, соответствует ли он ожидаемому стандарту на выбранном языке программирования. Существуют линты для многих языков.
  2. Превалирование IDE над простыми редакторами. Вы можете выбрать IDE, разработанную для языка, который изучаете. IDE – это интегрированные среды разработки. Они созданы для написания, отладки, компиляции и запуска кода. Jetbrains создают отличные IDE, такие как Webstorm и IntelliJ. Также есть NetBeans, Komodo, Qt, Android Studio, XCode (поставляется с Mac), etc.
  3. Чтение кода вслух. Это полезно, когда вы ищете семантическую ошибку. Читая свой код вслух, есть большая вероятность, что вы зачитаете и ошибку.
  4. Чтение логов. Когда компилятор отмечает Error, обязательно посмотрите, где он находится.

Двигаемся дальше

В процессе кодинга измените что-нибудь, чтобы понять, как он работает. Но будьте уверены в том, что сами написали.

Читайте также: