Как называется программа для поиска ошибок в других программах

Логические ошибки

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

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

Если вы запустите программу с n=20, программа выведет следующее значение:

Это правильное значение для 20!? Я не знаю. Может быть, мне стоит протестировать свою программу на более простом случае? Я знаю, что 3!=6, поэтому я изменю значение n на n=3 и перезапущу программу. Программа выводит следующее значение:

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

Выводы

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

Однако еще лучшая стратегия — избегать ошибок, "будучи программистом-самураем". Это означает, что вы должны хорошенько подумать о проблеме и изучить ее, прежде чем писать какой-либо код. Например, если бы я зашел на support.sas.com и ввел в поиск «factorial», я бы обнаружил, что в SAS есть встроенная функция FACT, которая сокращает программу до одной строки:

Это не может быть намного проще.

Об авторе

Рик Виклин, доктор философии, известный исследователь вычислительной статистики в SAS и главный разработчик программного обеспечения SAS/IML. Его области знаний включают вычислительную статистику, моделирование, статистическую графику и современные методы статистического анализа данных. Рик является автором книг Статистическое программирование с помощью программного обеспечения SAS/IML и Моделирование данных с помощью SAS.

7 комментариев

Цзянтан Ху указал, что я неправильно подсчитал количество цифр в числе 200!. Правильный ответ: 375 цифр.

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

Как правило, люди, разрабатывающие компьютерные языки, намеренно разрабатывают язык так, чтобы он был нетерпим к ошибкам, и требуют, чтобы программист правильно указывал команды. Есть несколько исключений. Чтобы обсудить проблемы и взглянуть на функции автокоррекции в программном обеспечении SAS, см. статью "Должен ли язык программирования принимать ключевые слова с ошибками?"

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

Чтобы добиться высокой доступности и отказоустойчивости в AWS, ИТ-администраторы должны сначала понять различия между двумя моделями.

Amazon ECS и EKS похожи, но их различий достаточно, чтобы выделить их для пользователей AWS. Узнайте, что лучше всего подходит для вашего .

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

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

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

Будь то создание автоматизированных инструментов для сертификации ОС или изучение eBPF как способа обеспечения безопасности цепочки поставок в домене .

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

Kubernetes и Terraform предоставляют множество преимуществ управления кластером контейнеров, но их сочетание делает их еще более эффективными. В.

Насколько хорошо вы знаете обработку исключений в Java? Эти 10 сложных вопросов с несколькими вариантами ответов для проверенных и непроверенных .

Не позволяйте возникновению RuntimeException в Java привести к остановке вашего кода. Вот 10 примеров того, как избежать .

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

Считаете, что готовы к сертификационному экзамену AWS Certified Solutions Architect? Проверьте свои знания, ответив на эти 12 вопросов и.

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

Amazon хотела бы укрепить свое глобальное присутствие, но гигант электронной коммерции сегодня сталкивается с препятствиями и проблемами, которых у него не было.

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

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

Предварительные условия для эффективной отладки

• Понимание структуры и алгоритма. Если вы работаете над модулем и не понимаете его структуры или алгоритмов, отладка будет очень сложной. Если вы не понимаете структуру, вы не сможете протестировать модуль, потому что не знаете, что он должен делать. Если вы не понимаете алгоритмы, вам будет очень сложно найти ошибки, которые выявляет тестирование. Вторая причина важности понимания алгоритмов заключается в том, что вам может понадобиться это понимание для создания хороших тестовых примеров. Это особенно верно для алгоритмов для сложных структур данных.
• Проверка правильности. Существует несколько методов проверки правильности реализации перед ее выполнением.
• Доказательства правильности. Одной из полезных проверок кода является проверка кода с использованием логических методов доказательства правильности. Например, если вы знаете предусловия, инварианты, условия завершения и постусловия для цикла, то вы можете выполнить несколько простых проверок. Означает ли предварительное условие вместе с любым кодом входа в цикл, что инвариант изначально истинен? Сохраняет ли тело цикла инвариант? Продвигается ли выполнение тела цикла к завершению цикла? Подразумевает ли инвариант вместе с условием завершения цикла и кодом выхода из цикла постусловие? Даже если эти проверки не найдут всех ошибок, вы сможете лучше понять алгоритм, выполнив проверки.
• Отслеживание кода. Часто ошибки можно обнаружить путем отслеживания выполнения различных вызовов служб модуля, начиная с различных начальных условий для модуля. По плохо понимаемым психологическим причинам отслеживание работает лучше всего, если вы описываете свое отслеживание кому-то другому. Чтобы быть эффективной, трассировка процедуры или функции должна выполняться при условии, что вызовы других процедур и функций работают правильно, даже если они являются рекурсивными вызовами. Если вы проследите вызываемую процедуру или функцию, вы обнаружите, что имеете дело со слишком большим количеством уровней абстракции. Обычно это приводит к путанице. Если есть какие-либо сомнения относительно вызываемых процедур и функций, их можно проследить отдельно, чтобы убедиться, что они работают в соответствии со спецификациями. Опять же, трассировка может не выявить все ошибки, но она может улучшить ваше понимание алгоритмов.
• Экспертная проверка. Экспертная проверка включает в себя экспертную проверку вашего кода на наличие ошибок. Чтобы быть эффективным, одноранговый узел должен либо уже быть знаком с алгоритмом, либо должен получить алгоритм и код заранее. Когда рецензент встречается с автором кода, автор кода должен представить код с пояснениями того, как он правильно реализует алгоритм. Если рецензент не понимает часть реализации или не согласен с ней, он обсуждает эту часть до тех пор, пока оба не придут к согласию относительно того, является ли это ошибкой. Роль рецензента заключается только в том, чтобы помочь обнаружить ошибки. Разработчику остается исправить их. Большая часть пользы от рецензирования проистекает из психологии представления того, как что-то работает. Часто автор кода обнаруживает свои собственные ошибки во время проверки. В любом случае, полезно, чтобы кто-то со стороны просмотрел вашу работу, чтобы получить другую точку зрения и обнаружить белые пятна, которые кажутся неотъемлемыми при оценке вашей собственной работы. Как и трассировка кода, рецензирование может занять много времени. Для работы в классе рецензирование всего модуля вряд ли окупит себя с точки зрения учебной ценности. Поэтому обзоры должны быть ограничены короткими сегментами кода. Однако для коммерческого программирования гораздо важнее качество кода. Таким образом, рецензирование является важной частью программы обеспечения качества программного обеспечения.
• Предвидеть ошибки. К сожалению, люди делают ошибки с аргументами правильности и иногда пропускают случаи при отслеживании кода, а равноправные узлы также не всегда обнаруживают ошибки. Так что программист должен быть готов к тому, что некоторые ошибки останутся в коде после перечисленных выше шагов. Надеюсь, их не будет слишком много.

Требования к отладке

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

Управление модулем

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

Получение информации о модуле

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

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

• Немедленно сообщайте об ошибках. Много времени уходит на отладку, чтобы выяснить причину ошибок. Чем раньше обнаружена ошибка, тем проще найти ее причину. Если неправильное состояние модуля обнаруживается сразу после его возникновения, то часто можно определить причину с минимальными усилиями. Если она не обнаружена до тех пор, пока симптомы не появятся в клиентском интерфейсе, может быть сложно сузить список возможных причин.
• Максимальное количество полезной информации и простота интерпретации. Очевидно, что желательно максимальное количество полезной информации, и что ее должно быть легко интерпретировать. Простота интерпретации важна в структурах данных. Некоторые ошибки модулей не так просто обнаружить, добавив проверки кода, потому что они зависят от всей структуры. Таким образом, важно иметь возможность отображать структуру в форме, которую можно легко проверить на правильность.
• Сведите к минимуму количество бесполезной и отвлекающей информации. Слишком много информации может быть таким же препятствием, как и слишком мало. Если вам приходится работать с распечаткой, которая показывает вход и выход из каждой процедуры в модуле, вам будет очень трудно найти первое место, где что-то пошло не так. В идеале отчеты о состоянии выполнения модуля должны выдаваться только в случае возникновения ошибки. Как правило, отладочная информация, в которой говорится, что проблема здесь, должна быть предпочтительнее, чем отчеты, в которых говорится, что проблема не здесь.
• Избегайте сложного одноразового тестового кода. Одной из причин, по которой добавление проверок правильности модуля для ошибок, затрагивающих всю структуру, является контрпродуктивным, является то, что код для этого может быть довольно сложным. Очень обескураживает потратить несколько часов на отладку проблемы только для того, чтобы обнаружить, что ошибка была в отладочном коде, а не в тестируемом модуле. Сложный тестовый код целесообразен только в том случае, если сложные части кода можно использовать повторно.

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

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

• Утверждения утверждений. Некоторые компиляторы Pascal и все компиляторы C, соответствующие стандарту ANSI, имеют процедуры утверждения. Процедура assert имеет единственный параметр, который является логическим выражением. Когда вызов assert выполняется, выражение оценивается. Если он оценивается как true, то ничего не происходит. Если он оценивается как false, программа завершается с сообщением об ошибке. Процедуру утверждения можно использовать для обнаружения ошибок и сообщения о них.
• Обратные трассировки. Многие компиляторы Pascal генерируют код, который приводит к обратным трассировкам всякий раз, когда возникает ошибка времени выполнения. Трассировка — это отчет о последовательности активных в данный момент подпрограмм. Иногда трассировка также указывает номера строк в активных подпрограммах. Если доступно, обратная трассировка показывает, где произошла ошибка во время выполнения, но программист должен определить, в чем причина.
• Отладчики общего назначения. Многие компьютерные системы или компиляторы поставляются с программами отладки. Например, в большинстве операционных систем UNIX есть отладчики общего назначения, такие как sdb и dbx. Программы отладки предоставляют возможности для пошагового выполнения программы построчно и запуска программы с точками останова, установленными пользователем. Когда строка с точкой останова должна быть выполнена, программа прерывается, чтобы пользователь мог проверить или изменить данные программы. Программы отладки также могут обеспечивать обратную трассировку в случае ошибок во время выполнения. Отладчики часто трудно научиться эффективно использовать. Если они являются единственным инструментом, используемым для отладки, то, вероятно, они не сэкономят много времени. Например, отладка модуля структуры данных с помощью отладчика, но без хорошего тестового драйвера, скорее всего, приведет к тому, что будет потрачено много времени на получение фрагментарной информации об ошибках.

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

Пошаговое тестирование

В хорошем дизайне сложного модуля код разбит на множество подпрограмм, длина большинства из которых не превышает 10–15 строк. Для модуля, разработанного таким образом, инкрементное тестирование дает значительные преимущества. Для пошагового тестирования подпрограммы классифицируются по уровням, при этом подпрограммы самого низкого уровня — это те, которые не вызывают другие подпрограммы. Если подпрограмма A вызывает подпрограмму B, то A является подпрограммой более высокого уровня, чем B. Стратегия пошагового тестирования состоит в том, чтобы тестировать подпрограммы по отдельности, работая от самого низкого уровня к более высоким уровням. Чтобы выполнить тестирование на более низких уровнях, тестовый драйвер должен либо иметь возможность вызывать низкоуровневые подпрограммы напрямую, либо программист должен иметь возможность предоставить несколько тестовых входных данных, каждый из которых включает только небольшое количество низкоуровневых подпрограмм. Разработка этих тестовых случаев требует глубокого понимания алгоритмов модуля, а также хорошего воображения. Сила инкрементного тестирования заключается в том, что в любой момент процесса есть лишь небольшое количество мест, где могут возникнуть ошибки. Это автоматически делает отладочную информацию более значимой и приводит к более быстрому определению причины ошибки. Вторая причина инкрементного тестирования заключается в том, что оно значительно снижает вероятность того, что вам придется иметь дело с двумя или более ошибками одновременно. Множественные ошибки часто приводят к запутанной индикации ошибок.

Проверки работоспособности

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

Булевы константы для включения и выключения кода отладки

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

Переменные ошибок для управления поведением программы после ошибок

Когда в код добавляются операторы отладочной печати, существует вероятность огромного взрыва бесполезной информации. Проблема в том, что оператор печати сам по себе будет выполняться независимо от того, есть ли ошибка. Таким образом, если ошибка не появляется до тех пор, пока не будет выполнено большое количество вызовов подпрограммы, то большинство сообщений просто говорят вам, что пока все в порядке. Эта проблема значительно усугубляется, если добавленный код отображает внутреннюю структуру структуры данных. Предполагая, что модуль имеет проверки работоспособности для обнаружения ошибок, в модуль можно добавить логическую переменную ошибки. Он должен быть инициализирован значением false, указывающим на отсутствие ошибки. Для большинства структур данных существует операция Create для инициализации. Переменная ошибки может быть инициализирована одновременно. Вместо выхода проверки работоспособности модифицируются таким образом, что они устанавливают переменную ошибки в значение true.Затем код отладки можно заключить в операторы if, чтобы информация печаталась только при обнаружении ошибок. Одним из возможных применений этого метода является получение информации о трассировке, когда она недоступна иным образом.

Методы отслеживания

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

Исправление ошибок кода

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

Предположим, что вы запускаете какой-то код и получаете ошибку сегментации. После некоторой проверки вы определяете, что указатель NULL был передан в процедуру, которая не проверяла наличие NULL, но все равно пыталась сослаться через указатель. Следует ли добавить в процедуру проверку указателя NULL, заключив все тело процедуры в оператор if? На этот вопрос невозможно ответить без понимания конструкции и алгоритма. Возможно, если алгоритм реализован правильно, то указатель не может быть NULL, и процедура не выполняет проверку. Если это так, то добавление оператора if не устраняет причину проблемы. Наоборот, это усугубляет ситуацию, скрывая симптомы. Проблема наверняка проявится где-то еще, но теперь симптомы будут дальше удалены от причины. Такой код, как проверка указателя на NULL, следует добавлять только в том случае, если вы уверены, что он должен быть частью алгоритма. Если вы добавите проверку указателя NULL, которая не требуется алгоритмом, она должна сообщить об ошибке. Другими словами, это должна быть проверка на вменяемость. [произошла ошибка при обработке этой директивы]

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

Вы разобрались с редактором и создали код. Теперь вы хотите убедиться, что код работает правильно. В Visual Studio, как и в большинстве IDE, код работает в два этапа: создание кода для обнаружения и устранения ошибок проекта и компилятора и запуск кода для поиска ошибок времени выполнения и динамических ошибок.

Создайте свой код

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

Самый простой способ собрать проект — нажать F7, но вы также можете начать сборку, выбрав в главном меню «Сборка» > «Сборка решения».

Вы можете наблюдать за процессом сборки в окне вывода в нижней части пользовательского интерфейса Visual Studio. Здесь отображаются ошибки, предупреждения и операции сборки. Если у вас есть ошибки (или если у вас есть предупреждения выше настроенного уровня), ваша сборка завершается ошибкой. Вы можете нажать на ошибки и предупреждения, чтобы перейти к строке, где они произошли. Пересоберите свой проект, либо снова нажав F7 (для перекомпиляции только файлов с ошибками), либо Ctrl+Alt+F7 (для чистого и полного перестроения).

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

Если сборка прошла успешно, в окне вывода вы увидите такие результаты:

Просмотрите список ошибок

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

Щелкните строку с ошибкой в ​​окне "Список ошибок", чтобы перейти к строке, в которой возникла ошибка. (Или включите номера строк, нажав Ctrl+Q, введя номера строк, а затем выбрав Включить или выключить номера строк в меню результатов. Это самый быстрый способ открыть диалоговое окно «Параметры», в котором можно включить нумерацию строк.)

Нажмите Ctrl+G, чтобы быстро перейти к номеру строки, где произошла ошибка.

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

< бр />

Просмотрите список ошибок и исправьте все ошибки в коде.

Подробно просмотреть ошибки

Многие ошибки могут не иметь для вас смысла, если они сформулированы в терминах компилятора. В таких случаях вам потребуется дополнительная информация. В окне Список ошибок вы можете выполнить автоматический поиск Bing для получения дополнительной информации об ошибке или предупреждении. Щелкните правой кнопкой мыши соответствующую строку ввода и выберите «Показать справку по ошибке» в контекстном меню или щелкните значение кода ошибки с гиперссылкой в ​​столбце «Код» списка ошибок.

В зависимости от ваших настроек либо ваш веб-браузер отображает результаты поиска кода и текста ошибки, либо в Visual Studio открывается вкладка, отображающая результаты поиска Bing. Результаты получены из разных источников в Интернете, и не все могут быть полезными.

Используйте анализ кода

Анализаторы кода ищут распространенные проблемы с кодом, которые могут привести к ошибкам во время выполнения или проблемам в управлении кодом.

Анализ кода C++

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

Нажмите Alt + F11 (или выберите "Анализ" > "Выполнить анализ кода решения" в верхнем меню), чтобы начать статический анализ кода.

Все новые или обновленные предупреждения отображаются на вкладке "Список ошибок" в нижней части IDE. Нажмите на предупреждения, чтобы перейти к ним в коде.

Используйте быстрые действия для исправления или рефакторинга кода

Быстрые действия можно использовать везде, где анализаторы кода определяют возможность исправления, рефакторинга или улучшения кода. Щелкните любую строку кода, щелкните правой кнопкой мыши, чтобы открыть контекстное меню, и выберите «Быстрые действия и рефакторинг». Если доступны параметры рефакторинга или улучшения, они отображаются. В противном случае в левом нижнем углу среды IDE отображается сообщение "Здесь нет доступных быстрых действий".

При наличии опыта вы сможете быстро использовать клавиши со стрелками и Ctrl+. чтобы проверить возможности простого рефакторинга и очистить свой код!

Запустить очистку кода

Помимо форматирования файла с учетом пробелов, отступов и т. д., Code Cleanup также применяет набор определяемых вами соглашений о стиле кода.Ваши настройки для каждого стиля кода считываются из файла EditorConfig, если он есть для проекта, или из настроек стиля кода в диалоговом окне «Параметры».

Отладка работающего кода

Теперь, когда вы успешно создали свой код и выполнили небольшую очистку, запустите его, нажав F5 или выбрав Отладка > Начать отладку. Это запустит ваше приложение в среде отладки, чтобы вы могли подробно наблюдать за его поведением. IDE Visual Studio изменяется во время работы вашего приложения: окно вывода заменяется двумя новыми (в конфигурации окна по умолчанию), окном с вкладками Autos/Locals/Watch и окном с вкладками Call Stack/Breakpoints/Exception Settings/Output. В этих окнах есть несколько вкладок, которые позволяют вам проверять и оценивать переменные, потоки, стеки вызовов и различные другие параметры вашего приложения во время его работы.

Остановите приложение, нажав Shift+F5 или нажав кнопку "Стоп". Или вы можете просто закрыть главное окно приложения (или диалоговое окно командной строки).

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

Установите простые точки останова

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

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

Общее использование точек останова включает:

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

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

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

Если вы пишете код C или C++, используйте точки останова для остановки кода, чтобы вы могли проверять значения адресов (искать NULL) и счетчики ссылок при отладке сбоев, связанных с памятью.

Дополнительную информацию об использовании точек останова см. в разделе Использование точек останова.

Проверяйте свой код во время выполнения

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

Выполнить модульные тесты

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

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

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

  
• Температура выключения в биосе, что это такое
  
• Зеркало для компьютера
  
• Утилита настройки Asrock UEFI Setup BIOS
  
• Комплект для сима, что это за программа для Android
  
• Лучшее программное обеспечение для рисования манги