Как найти корректный код

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

Что такое валидность кода

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

Для этого есть специальные стандарты: если им следовать, страницу будут корректно распознавать все браузеры и гаджеты. Такой стандарт разработал Консорциумом всемирной паутины — W3C (The World Wide Web Consortium). HTML-код, который ему соответствует, называют валидным.

Валидность также касается файлов стилей — CSS. Если в CSS есть ошибки, визуальное отображение элементов может нарушиться.

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

Чем ошибки в HTML грозят сайту

Типичные ошибки кода — незакрытые или дублированные элементы, неправильные атрибуты или их отсутствие, отсутствие кодировки UTF-8 или указания типа документа.

Какие проблемы могут возникнуть из-за ошибок в HTML-коде

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

Как валидность кода влияет на SEO

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

Почитать по теме:
Главное о микроразметке: подборка знаний для веб-мастеров

Представитель Google Джон Мюллер говорил о валидности кода:

«Мы упомянули использование правильного HTML. Является ли фактором ранжирования валидность HTML стандарту W3C?

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

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

Итак, критические ошибки в HTML мешают

• сканированию сайта поисковыми ботами;
• определению структурированной разметки на странице;
• рендерингу на мобильных устройствах и кроссбраузерности.

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

Как проверить код на валидность

Не нужно вычитывать код и считать символы — для этого есть сервисы и инструменты проверки валидности HTML онлайн.

Что они проверяют:

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

  .

• DTD (Document Type Definition)
  Соответствие кода указанному DTD, правильность названий тегов, вложенности, атрибутов. Наличие пользовательских тегов и атрибутов — то, чего нет в DTD, но есть в коде.

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

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

Почитать по теме:
Уменьшить вес сайта с помощью gzip, brotli, минификации и других способов

Поэтому анализируйте предложения сервисов по исправлениям и ориентируйтесь на здравый смысл.

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

HTML и CSS валидаторы — онлайн-сервисы для проверки кода

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

Валидатор от W3C

Англоязычный сервис, онлайн проверяет соответствие HTML стандартам: можно проверить код по URL, залить файл или вставить код в окошко.

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

Валидатор CSS от W3C

Инструмент от W3C для проверки CSS, есть русский язык. Работает по такому же принципу, анализирует стили на предмет ошибок и предупреждений. Первым идет блок ошибок, предупреждения собраны ниже отдельно.

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

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

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

Что такое валидация кода

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

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

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

Почему важно проверять код

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

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

Что именно проверять и в каких сервисах

Проверяется не только HTML-разметка, но и соответствие кода спецификации CSS, адаптивность верстки и наличие битых ссылок. Расскажем, что такое валидатор кода и как он поможет сделать автоматическую проверку. 

Валидация HTML

Рассмотрим, как проверить, работает ли код HTML. Он отвечает за правильное отображение контента во всех браузерах. Для проверки используем валидатор W3C — один из самых популярных, так как разработан авторами стандартов для HTML.

Проверка HTML-кода может выполняться через расширения в браузерах. Например, в Google Chrome оно установлено по умолчанию и включается сочетанием трех клавиш: Ctrl + Shift + I. Вы увидите значок в строке состояния, который показывает количество ошибок в HTML-странице. Подробная информация об ошибках видна при просмотре исходного HTML-кода.

Более 80% времени разработчики тратят на чтение кода. Уметь читать код — даже важнее, чем уметь его писать.

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

«Действительно, соотношение времени, затрачиваемого на чтение и написание, составляет более 10 к 1. Мы постоянно читаем старый код в рамках усилий по написанию нового кода. <…> [Поэтому] облегчение чтения облегчает написание».

Зачем читать чужой код

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

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

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

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

С чего начать

Поиск понятной части кода

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

1. Сначала определите, в каком конкретном месте код создает этот файл.
2. Потом поймите, в каком месте отчет заполняется.
3. Сделайте еще один шаг и выясните, откуда взялась информация о пользователе, и так далее, шаг за шагом следуйте из конца в начало.

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

Этот процесс чем-то похож на судоку: сначала вы решаете легкие клеточки, а они приводят к решению сложных и неочевидных.

Git blame и git log

Скорее всего, код, который вы пытаетесь понять, импортировали из общей системы контроля версий — Git, SVN. Посмотрите историю изменения непонятной строчки с помощью команд git blame и git log — они выдадут историю всех коммитов и изменений.

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

Git blame может дать информацию об авторе этого кода — можете расспросить его лично.

Картина целиком

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

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

Чтение спецификации

Если в репозитории, который вы изучаете, есть test suite, то половина дела сделана за вас.

Тесты — отличное место, откуда стоит начинать читать код. Тесты — это намерение разработчика.

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

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

Комментарии как подсказки

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

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

Поиск Main

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

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

Структура и стиль

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

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

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

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

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

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

Мусорная часть кода

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

Не переживайте и смело удаляйте эти части. Человек, который придет на проект после вас, скажет спасибо.

Повторение и закрепление

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

Краткие итоги

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

1. Найдите понятную часть кода.
2. Посмотрите историю изменений с помощью git blame и git log.
3. Прочитайте спецификацию.
4. Оставьте себе комментарии, чтобы потом было легче ориентироваться.
5. Запустите код и посмотрите, как он работает.
6. Определите стиль и продолжайте его придерживаться в дальнейшей работе с кодом.
7. Удалите мусорную часть кода.