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

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

Ваш набор инструментов для борьбы с ошибками

1. Оператор печати

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

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

2. Отладчик

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

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

3. Система отслеживания ошибок

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

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

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

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

4. Верификация программ

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

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

5. Контроль версий

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

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

6. Модульность

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

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

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

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

7. Автоматизированные тесты

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

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

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

8. Метод «Плюшевый мишка» (или отладка «Резиновая уточка»)

Если верить легендам программирования Брайану Кернигану и Робу Пайку (Brain Kernighan и Rob Pike), отладка по типу «Резиновая уточка» возникла в университетском компьютерном центре, где студенты должны были садиться напротив плюшевого мишки и объяснять ему их ошибки, прежде чем обращаться за помощью к живому человеку.

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

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

9. Пишите комментарии к коду

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

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

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

10. Пишите документацию

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

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

На пути к мастерству: избавляемся от ошибок

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

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

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

Часть 3 – Отладка программы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поздравляем! Слово «ошибка» уже привычно для вас, равно как и «отладка программы». В качестве новичка вы можете изучать кодинг по книгам, онлайн-урокам или видео. И даже чужой код вам теперь не страшен :)

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

Зачем нужен валидный код и как устранить ошибки валидации

Валидация является одним из самых важных аспектов хорошего веб-дизайна. Давайте рассмотрим, что это такое и как проверить HTML код на валидность. В качестве примера возьмем самую распространенную систему управления контентом (CMS) – WordPress. После чего мы поделимся перечнем ошибок, с которыми столкнулись на практике и, самое главное, предложим свои, проверенные, методы по их устранению.

Зачем необходима проверка на валидность сайта

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

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

На что влияет валидность сайта

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

Некорректная веб-страница может быть прочитана браузерами по-разному. Это приведет к тому, что ваши посетители, возможно, даже не смогут правильно увидеть контент страницы в своих браузерах. Валидация в дальнейшем позволит исправить почти все основные различия и делает вашу веб-страницу доступной для чтения почти всеми веб-браузерами (чаще всего исключением становится Internet Explorer старых версий). Отсюда и появился термин “кроссбраузерная верстка” – т. е. верстка, которая одинаково хороша (совместима) для всех популярных браузеров.

А как же это повлияет на SEO? Важно понимать, что роботы поисковых систем любят семантические веб-страницы. Семантическая верстка, согласно данным Википедии, – это подход к созданию веб-страниц на языке HTML, основанный на использовании HTML тегов в соответствии с их семантикой (предназначением). Кроме того, структурная семантическая веб-страница позволяет поисковым роботам более точно определять значимость, как отдельных элементов веб-страницы, так и всего текста в целом. По заверению Google, валидный код никак не влияет на ранжирование страниц. Но при этом наличие ошибок в коде способно негативно повлиять на сканирование микроразметки и адаптированностью под мобильные устройства.

Так что, если в SEO-аудите вы встретите рекомендации по устранению ошибок, выявленных в процессе валидации, то лучше их исправить, а как это сделать мы вам расскажем.

Инструменты проверки для вашего сайта

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

Существует множество бесплатных сервисов для проверки сайта, такие как Markup Validation Service W3C, Web Page Analyzer, Browsershots и другие.

Служба проверки HTML разметки W3C, вероятно, является самым простым и популярным инструментом для проверки валидности веб-страницы. Используя этот инструмент, вы можете обнаружить ошибки валидации, начиная от отсутствующих атрибутов ALT для ваших IMG-тегов и заканчивая размещением элементов блок-уровня внутри встроенных элементов (например, <p> внутри <span>).

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

Служба проверки HTML разметки W3C

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

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

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

Откуда берутся ошибки

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

Как исправить ошибки, и улучшить валидность сайта

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

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

Предупреждение. Атрибут “type” элемента <script> не является обязательным для JavaScript ресурсов.

Предупреждение, использование устаревшего атрибута type для элемента script

Warning: The type attribute for the style element is not needed and should be omitted.

Предупреждение. Атрибут “type” для элемента <style> не нужен и его следует опустить.

Предупреждение, использование устаревшего атрибута type для элемента style

Для устранения данных двух предупреждений необходимо удалить атрибут type=”text/javascript” во всех тегах <script>, а также type=”text/css” во всех тегах <style>. В помощь нам приходит простая функция PHP preg_replace в паре с чудесной возможностью фильтрации данных в WordPress. Код выглядит так:

Встроенный редактор в админ панеле WordPress

Дополнительно удалим данный атрибут в некоторых файлах вашей WordPress-темы.

Ошибка. Тег <center> устарел. Используйте соответствующие CSS стили.

Предупреждение, использование устаревшего тега center

HTML 5 активно взаимодействует с CSS (язык описания внешнего вида документа, написанного с использованием HTML), поэтому запрет на многие теги и атрибуты, начатый в HTML 4 в пользу стилей, только усилился. Такого рода теги и атрибуты уже не поддерживаются некоторыми браузерами и должны исключаться из кода. Одним из таких тегов является тег <center>, а также атрибут “frameborder” тега <iframe>. При решении данных ошибок нам необходимо будет немного “поколдовать” над нашей Базой данных сайта.

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

Панель управления хостингом

Панель управления phpMyAdmin

Первым делом экспортируем всю базу данных в качестве резервной копии! Для этого нажимаем кнопку “Экспорт” в панели веб-интерфейса для администрирования. Далее выбираем закладку “SQL” для осуществления SQL запросов к базе данных, в нашем случае поиск и замена устаревших тегов и атрибутов. Прописываем следующие запросы:

SQL запросы в панели управления phpMyAdmin

Рассмотрим более подробно выше представленные SQL запросы.

Редактирование таблицы стилей

Второй строчкой SQL запроса заменяем закрывающийся тег </center> на закрывающийся </div>. А третьей – производим замену атрибут frameborder=”0” на класс “ag_border_zero” элемента <iframe>.

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

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

Ошибка. Атрибут “width” элемента <th> устарел. Используйте соответствующие CSS стили.

Ошибка, использование устаревшего атрибута width элемента th

В случае если данная ошибка несет массовый характер в статьях вашего проекта, воспользуемся поиском и заменой атрибута “width” в панели phpMyAdmin следующим SQL запросом:

После чего необходимо добавить стилевой класс width_ten_percent в файле style. css:
.width_ten_percent

Следует отметить, что при массовой замене устаревших атрибутов на стилевые классы в панеле phpMyAdmin, при наличии уже прописанного класса у элемента (например, <img />), может возникнуть другая ошибка – дублирование атрибута “class”. Подобная ситуация обстоит и с атрибутом “style” (например, <img style=”width: 300px” style=”height: 200px”>). Поэтому, нужно быть уверенным в отсутствии ранее указанного другого атрибута “class” / “style”, либо отказаться от редактирования БД SQL запросами в пользу ручной проверки и редактирования каждой отдельной статьи в редакторе админ панели WordPress.
Для примера, рассмотрим добавление дополнительного класса / свойства атрибута “style”, придерживаясь стилевых правил. Добавим дополнительный класс width_ten_percent к уже имеющемуся color_red (class=”color_red”), и получаем: width_ten_percent” (перечисляем имена классов через пробел). Добавим ширину в 10% к уже имеющемуся style=”color: red;”, в итоге у нас должно получиться так: style=”color: red; width: 10%;” (стилевые свойства разделяются между собой точкой с запятой и пробелом).

Также хотелось бы отметить частое ошибочное использование атрибута “width” для элемента <tr>, атрибута “height” для элемента <td>.

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

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

Устаревшие атрибуты Элемент
charset, coords, shape, methods, name, rev, urn <a>
nohref <area>
alink, bgcolor, link, marginbottom, marginheight, marginleft, marginright, margintop, marginwidth, text, vlink <body>
clear <br>
name <embed>
profile <head>
version <html>
longdesc <iframe>
longdesc, lowsrc, name <img>
usemap <input>
charset, methods, rev, target, urn <link>
scheme <meta>
name <option>
archive, classid, code, codebase, codetype, declare, standby <object>
type, valuetype <param>
event, for, language <script>
datapagesize <table>
abbr, axis <td> и <th>

Ошибка. Неприемлемое значение “300px” для ширины атрибута в элементе <img>: Ожидалась цифра, но вместо этого прочитал “px”.

Ошибка, неприемлемое значение для ширины атрибута в элементе img

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

В контексте <img width=”300px” /> атрибутом “width” допускается принимать любое целое положительное число. Необходимо установить допустимое значение для правильной разметки, а именно 285, без указания единицы измерения (px).

Редактирование содержимого виджетов в административной панели WordPress

Дополнительно встречается ошибочное указание параметра атрибута “height” элемента <img>.

Использование имени стилевого идентификатора (id=“имя”) более одного раза на одной странице.

Ошибка, использование стилевого идентификатора более одного раза на одной странице

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

Имя класса и идентификатор должен обязательно начинаться с латинского символа (A–Z, a–z). Может содержать цифры (0–9), символ дефиса (-) и подчеркивания (_), но не в начале слова. Использование русских букв в именах идентификатора недопустимо.

Тег noindex используется для исключения контента, который необходимо скрыть от поисковой системы Яндекс. Например, дубли элементов навигации. Однако многие используют его неверно:

<noindex>Текст или код, который нужно исключить из индексации</noindex>

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

Отсутствует открывающий или закрывающий тег.

Ошибка валидации, отсутствует открывающий или закрывающий тег

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

Блочные элементы внутри строчных.

Ошибка валидации, блочные элементы внутри строчных

Согласно спецификации блочный элемент запрещено вставлять внутрь строчного. Например, <span><p>Lorem ipsum…</p></span> не пройдёт валидацию, правильно вложить теги наоборот — <p><span>Lorem ipsum…</span></p>.

Наиболее часто используемыми блочными элементами являются:

Встроенные (строчные) элементы:

Отсутствует атрибут “alt” у изображения.

Отсутствие атрибута alt у изображения

Каждое изображение (даже если оно служит для дизайнерских целей) в документе HTML должно иметь атрибут “alt” с описанием содержания картинки. Данный атрибут индексируется поисковыми роботами и используется ими для определения содержимого обнаруженных картинок. А это, в свою очередь, важно как для улучшения релевантности веб-страниц, так и для привлечения на сайт дополнительного трафика из «поиска по картинкам».

Памятка для контент-менеджеров

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

Памятка для контент-менеджеров

Завершение

Результатом кропотливой работы над ошибками мы должны увидеть следующее: Проверка документа завершена. Каких-либо ошибок и предупреждений не выявлено (“Document checking completed. No errors or warnings to show.”).

Результат успешного прохождения проверки веб страницы на валидность

Что вы думаете о важности валидации? С какими ошибками сталкивались Вы и как их решали? Добавьте к этой статье свои комментарии!

Источники:

https://www. internet-technologies. ru/articles/10-sovetov-dlya-otladki-i-ustraneniya-nepoladok-v-programmirovanii. html

https://proglib. io/p/debugging/

https://apollon. guru/seo/validnost-html-koda/

Понравилась статья? Поделиться с друзьями:
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: