Стандарты кодирования для HTML, CSS и JavaScript’a

Уже давненько я поднимал вопрос о стандартах кодирования в PHP, и вот решился описать правила хорошего тона для HTML, CSS и JavaScript’a.

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

  • HTML – markup layer – верстка
  • CSS – presentation layer – представление
  • JavaScript – behavioural layer – поведение

Но давайте по порядку…

Strict DOCTYPE

Не будем вступать в дискуссию, какой стандарт лучше HTML 4.0 иль XHTML 1.0 – оба они хороши и вполне подходят в качестве стандарта, но я придерживаюсь XHTML’a ;). А вот насчет DOCTYPE – то пора уже взрослеть и переходить на strict… если конечно у Вас не табличная верстка, иначе прийдется остаться на transitional…

1
2
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

Ссылки:

Данная статья написана в далёком 2008-м году, а сейчас HTML5 там правит бал, а всё что выше – уж давно кануло в Лету

Кодировка и спец-символы

Кодировка UTF-8 и точка. Не надо разводить холивар, принимаем сие как стандарт.

Далее нам надо бы сию кодировочку прописать в нашем HTML’е – для этого необходимо поместить соответствующий тег внутрь тэга , но есть небольшой подводный камень – есть большой соблазн запихнуть <title> до объявления кодировки – не ведитесь – иначе браузер может заняться произволом и попытается определить кодировку самостоятельно по тексту в <title>, и обычно не очень удачно.

1
2
3
4
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Anton Shevchuk's Home</title>
</head>

Насчет символов аля &, <, > – если вы хотите соответствовать стандартам – то заменяем сие неподобство на соответствующую последовательность &, <, >

Валидация

Зеленый текст W3C validator’а – это наша цель, так что не забывайте закрывать теги, да прописывать обязательные параметры…

1
2
3
4
5
6
7
<!-- найди ошибки - получи пирожок -->
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
Nunc urna metus, ultricies eu, congue vel, laoreet id, justo.
Aliquam fermentum adipiscing pede. Suspendisse dapibus ornare
quam. Lorem ipsum dolor sit amet, consectetuer adipiscing elit.<p>
<a href="/index.php?mod=default&act=image"><img src="/img001.jpg"></a>
<!-- подсказка - их тут пять (XHTML 1.0 Strict)-->

Ссылки:

Форматирование отступами

Отступы – невидимые в браузере, но такие незаменимые для верстки (X)HTML’а – они в разы повышают читаемость кода.
И их использование – просто песня – начинаешь новый вложенный тег – сделай отступ, закрываешь – убери.
В качестве отступа принято использовать символ табуляции (tab) либо несколько пробелов (обычно 4).

Сравните код:

1
2
3
4
    <ul class="bigBarNavigation"><li>
<a href="/">Home</a></li><li>
<a href="/about.html">About Us</a></li><li>
<a href="/contact.html">Contact Us</a><div class="subMenu"><!-- Example --></div></li></ul>

И код с отступами:

1
2
3
4
5
6
7
8
<ul class="bigBarNavigation">
    <li><a href="/">Home</a></li>
    <li><a href="/about.html">About Us</a></li>
    <li>
        <a href="/contact.html">Contact Us</a>
        <div class="subMenu"><!-- Example --></div>
    </li>
</ul>

Точно так же можете применять отступы в вашем CSS файле:

1
2
3
4
5
6
7
#header  { .. }
    #header h1 { .. }
    #header h2 { .. }
 
#content { .. }
    #content .title { .. }
    #content .post  { .. }

P.S. Когда займетесь блошиной оптимизацией вашего сайта, то решите, что 4 пробела – это в 4-ре раза больше трафика чем один символ табуляции :)

Теги любят порядок

Очень часто в шапке нашего сайта мы пишем тег <h1> с названием нашего сайта, да еще и оформляем его ссылкой на главную страницу сайта, и для этого обрамляем наш тег <h1> в <a>. Большинство браузеров адекватно отобразит нам сие творение, но с технической точки зрения это не верно, т.к. тег <a> отображается как inline, а <h1> как block, а block элементы не должны располагаться в inline элементах (это bad practices).

Плохо:

1
<a href="/index.html"><h1>Мой сайт</h1></a>

Хорошо:

1
<h1><a href="/index.html">Мой сайт</a></h1>

Ссылки:

“Дивная” верстка

В английском языке есть термин “divits” – сим термином награждают HTML разметку с чрезмерным использованием div’ов без потребности, я же обзываю такие творения “дивными”. Обычно таким грешат новички, которые для применения стилей CSS оборачивают элементы в div’ы, что и приводит к их размножению без нужды.

01
02
03
04
05
06
07
08
09
10
<div class="topNav">
    <ul class="bigBarNavigation">
        <li><a href="/">Home</a></li>
        <li><a href="/about.html">About Us</a></li>
        <li>
            <a href="/contact.html">Contact Us</a>
            <div class="subMenu"><!-- Example --></div>
        </li>
    </ul>
</div>

В данном примере, div (с классом “topNav”), оборачивает ul (с классом “bigBarNavigation”). Оба, div и ul, являются блочными элементами, так что нам нет необходимости заворачивать <ul> в <div>; все, что мы можем сделать с <div> мы можем проделать и с <ul>.

Выбираем правильные имена

Самое время обсудить правила именования id и class’ов. Возьмем пример из предыдущего абзаца – у нас использовался неупорядоченные список с идентификатором “bigBarNavigation.” “Navigation” – эта часть имени несет смысловую нагрузку о содержимом списка, но “big” и “Bar” относится лишь к внешнему представлению, актуальному на данный момент, но если мы изменим дизайн сайта (и, скажем, навигация у нас будет выпадающим меню), то данный ID будет неактуальным и добавит лишь путаницы.

1
2
<h1>Мой сайт о <span class="blue italic">ёжиках</span></h1>
<!-- Сегодня blue и italic, а завтра red и bold? -->

Приведу примеры “правильных” id и class’ов: “mainNav”, “subNav”, “sidebar”, “footer”, “metaData”, а так же “неправильные” имена (которые описывают дизайн): “bigBoldHeader”, “leftSidebar”, “roundedBox”.

CSS’у CSS’ное

Очень часто, в меню сайтов, используют написание текста в верхнем регистре. Конечно это легко сделать используя клавишу Shift на клавиатуре, но мы то не просто так CSS изучали, так что сей функционал стоит перенести в CSS, для это цели стоит воспользоваться {text-transform: uppercase}. Теперь, если вы вдруг передумаете, Вы сможете с легкостью изменить вид вашего меню изменив лишь одну строчку в CSS.

HTML практически без изменений:

1
2
3
4
<ul>
    <li><a href="/index.html">Home</a></li>
    <!-- ... -->
</ul>

И совсем чуть-чуть изменений в CSS:

1
ul li a {text-transform: uppercase}

Ссылки:

Class/id для <body>

Зачем? Объясню на примере – представьте – у Вас есть страница сайта на которой расположение элементов иное нежели на всех остальных, дабы сие сотворить Вам необходимо внести изменения в существующий стиль для div’a с id=”mainContent”, для этого создаете новый id=”mainContent-500″, создаете и вносите изменения, и так для каждого элемента в нашем шаблоне, а если у нас таких страниц несколько?, а потом сие еще внедрять разработчику сайта…

Если же у body был класс, то мы бы добавили к нему еще один (<body class="blogLayout width-500">) и уже в CSS прописывали изменения для всех дочерних элементов (не зря ж это каскадная таблица стилей). Таким образом мы очень сильно упрощаем жизнь разработчикам, которые будут внедрять наш дизайн.

1
2
3
body.width-500 #mainContent {
   width:500px;
}

Логический порядок

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

1
2
3
4
5
6
7
8
<body class="body">
    <div id="header"></div>
    <div id="wrapper">
        <div id="content"></div>
    </div>
    <div id="sidebar"></div>
    <div id="footer"></div>
</body>

CSS во внешних файлах

Вы можете добавить описание стилей CSS в самом теле HTML, используя соответствующий тег <style type="text/css" media="screen">...</style>, но только за такое творчество хочется дать по рукам, ведь такой стиль будет применяться только для определенной страницы (хотя иногда в этом есть необходимость), гораздо удобней вынести сие во внешний файл CSS.

Вроде смотрится неплохо:

1
2
3
4
<style type="text/css" media="screen">
    body { background:pink }
    /* etc */   
</style>

Но таки так лучше:

1
<link rel="stylesheet" href="/css/style.css" type="text/css" media="screen" charset="utf-8" />

То же самое касается и JavaScript’a, но о нем чуть позже.

Стандарты кодирования CSS

К сожалению я не нашел стандартов для написания файлов стилей, лишь пожелания:

  • Комментарии к элементам
  • Форматирование отступам – от этого не все в восторге
  • Правильные имена селекторов – уже обсуждалось выше

Ссылки:

Отделяем Javascript от HTML

Нам следует отделить всю функциональность JavaScript’а от HTML’а и запихнуть её в отдельный файл. Для этой цели лучше всего нам подойдет jQuery фреймверк, ибо удобно, быстро, и красиво (да и взгляните на график)

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

Плохо:

1
<a onClick="doSomething()" href="#">Click!</a>

Хорошо:
Все обработчики событий помещаем во внешний файл, который подключим в начале страницы используя тег <script>. Соответственно немного переделаем предыдущий код:

1
<a href="backuplink.html" class="doSomething">Click!</a>

В JavaScript файле будет что-то типа:

1
2
3
4
5
6
... 
$('a.doSomething').click(function(){ 
    // Do something here! 
    alert('You did something, woo hoo!'); 
}); 
...

Семантическая верстка

Возвращаясь к теме верстки стоит упомянуть – дабы писать красивый JavaScript код с использованием jQuery нам необходима максимально прозрачная структура документа.

Очень Плохо:

01
02
03
04
05
06
07
08
09
10
<table> 
    <tr> 
        <td onclick="doSomething();">First Option</td> 
        <td>First option description</td> 
    </tr> 
    <tr> 
        <td onclick="doSomething();">Second Option</td> 
        <td>Second option description</td> 
    </tr> 
</table>

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

1
2
3
4
5
6
<dl> 
    <dt onclick="doSomething();">First Option</dt> 
    <dd>First option description</dd> 
    <dt onclick="doSomething();">Second Option</dt> 
    <dd>Second option description</dd> 
</dl>

Хорошо:
Мы убрали все лишние, и добавили id к элементу dl – дабы в JavaScript’е мы смогли добавить обработчики событий для элементов dt:

1
2
3
4
5
6
<dl id="OptionList"> 
    <dt>First Option</dt> 
    <dd>First option description</dd> 
    <dt>Second Option</dt> 
    <dd>Second option description</dd> 
</dl>

К примеру вот так будет выглядеть обработчик событий:

1
2
3
$('#OptionList dt').click(function(){
    /* do something */
});

Лечим JavaScript зависимость

При разработке web-приложений стоит избегать JavaScript зависимости, т.е. наш сайт должен работать и при отключенном JavaScript’e, конечно, каких-то красивостей не будет, но сайт должен работать.

Плохо:

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

1
2
3
4
5
var now = new Date(); 
if(now.getHours() < 12) 
    document.write('Доброе утро!'); 
else 
    document.write('Добрый день!'); 

;

Хорошо:

Приветствие размещается в теле странички:

1
<p title="Good Day Message">Доброе утро!</p>

И заменяется другим приветствием в зависимости от времени суток:

1
2
3
4
5
6
var now = new Date(); 
if(now.getHours() >= 12) 
{ 
    var goodDay = $('p[title="Good Day Message"]'); 
    goodDay.text('Добрый день!'); 
}

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

Теперь приведу более сложный пример, реализация которого невозможна без изменений серверной части нашего приложения. Давайте сделаем загрузка контента страницы посредством AJAX’а, но при этом оставим поддержку браузеров с отключенным JavaScripti’om, возьмем уже знакомый нам пример с меню сайта:

1
2
3
4
5
6
<ul class="Navigation">
    <li><a href="/">Home</a></li>
    <li><a href="/about.html">About Us</a></li>
    <li><a href="/contact.html">Contact Us</a></li>
</ul>
<div id="MainContent"><!-- Content --></div>

Данный пример работает у нас без JavaScript’a, все страницы в нашем меню используют один и тот же шаблон для вывода информации, и по факту у нас изменяется лишь содержимое div’a с id=”MainContent”. Естественно можно улучшить данный функционал используя для загрузки контента AJAX – для этого добавим следующий код:

01
02
03
04
05
06
07
08
09
10
$(document).ready(function() 
{
    // вешаем обработчик на все ссылки в нашем меню Navigation
    $("ul.Navigation a").click(function(){
        var url = $(this).attr("href"); // возьмем ссылку
            url =+ "?ajax=true";        // добавим к ней параметр ajax=true
        $("#MainContent").load(url);    // загружаем обновленное содержимое
        return false;                   // возвращаем false - дабы не сработал переход по ссылке
    });
});  

В данном примере мы предполагаем, что сервер видя параметр ajax=true вернет нам не полностью всю страницу, а лишь обновление для div’a с id=”MainContent” (конечно сервер может быть умнее и не требовать явного указания на использования AJAX’а, а вполне удовлетвориться словив header X_REQUESTED_WITH со значением XMLHttpRequest)

Событие onload

Обычно все Javascript события вешались на “onload” тега <body> – это позволяло нам выполнять их по завершению загрузки страницы. Забудьте это.
jQuery предоставляет нам специальный метод, называемый “ready”, именно он, позволит нам выполнять код после полной загрузки DOM. Именно благодаря ему, мы можем внедрять ненавязчивые скрипты, при этом полностью отделив Javascript от разметки. Используя $(document).ready(), мы можем поставить в очередь целый ряд событий и все они будут выполнены после загрузки страницы.

Слайды, слайды…

Плохо
Приведу пример кода для отображения alert-сообщения с текстом “Hello World”, без использования jQuery и события onload:

1
alert('Hello World');

Хорошо
Old-school style – хорошо, коли у Вас нет необходимости во фреймворках:

1
2
3
window.onload = (function(){
  alert('Hello World');
});

А теперь с использованием jQuery напишем следующий скрипт:

1
2
3
4
$(document).ready(function() 
{ 
    alert('Hello World'); 
});  

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

Стандарты кодирования JavaScript

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

Написание комментариев, так же является хорошим тоном, но если они еще и будут помогать в генерации документации – будет лучше:

Так же правилом хорошего тона является сжатия исходных кодов JavaScript’а для уменьшения времени загрузки (для live-сервера):

P.S.

Если с jQuery у Вас возникли трудности, то советую почитать следующие статьи:

А ещё лучше – скачайте и изучите учебник jQuery для начинающих

Данная статья подготовлена по материалам:

73 thoughts on “Стандарты кодирования для HTML, CSS и JavaScript’a”

  1. Начало хорошее, а вот обсуждение js скатывается к обсуждению конкретной библиотеки. Я не спорю jQuery очень и очень неплох. Особенно если ты умеешь им пользоваться, а сроки выполнения работы горят. Но довольно часто бывает, что использование сей библиотеки – пальба из пушки по воробьям.

    В одном из наших проектов надо было на лету менять оформление элементов. Отлично, быстренько набросал пару строк кода и все отлично. Но стоило начать наращивать функционал и полезли проблемы. В итоге кое какие элементы кода были подсмотрены в jQuery, а остальное было написано сенсеем ручками. Получилось аккуратно и быстро. Быстро в плане выполнения скрипта, с jQuery при отработке события элемент моргал.

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

  3. Вместо

    1
    <img src="/img001.jpg">

    должно быть

    1
    <img src="/img001.jpg" />

  4. Не просто классная, а офигенная статья :), вот только “несторонники” jQuery будут немного против такого PR-а :)

    Относительно стандартов CSS я к сожалению не нашёл ссылок, затерялись :(… но они есть – найду – напишу. Я бы к приведенному перечню добавил бы ещё обнуление внутренних стилей браузера (reset).

  5. Закрывая глаза на упоминание jQuery в качестве примеров (хотя мне она нравиться)все по делу, хотя для технолога написанное выше – прописные истины. Что касается форматирования отступами в CSS – это на вкус и цвет; мне, допустим, так удобнее. Главное, все в одном месте – спасибо.

  6. Почти ничего нового, хотя статья огромная. Интересуюсь форматированием css и css-фреймворков/ресетами/стилем организации файлов.

  7. В тексте есть несколько ошибок:
    — «да прописывать обязательные переметры…»
    — «Class/id для…» — тег body не экранирован.
    — «т.е. нам нужны стандарты кождирования»

  8. @Артём Сапегин:
    спасибо – исправил…

    @All:
    Конечно, использование jQuery в данных примерах – это лишь мои симпатии к данному фреймворку, в действительности, в большинстве случаев, хватает getElementById :)

    По стандартам и правилам хорошего тона для CSS – если у кого есть ссылки по данной теме – буду очень благодарен…

  9. Очень полезная для любого новичка в верстке / JS-кодировании статья.
    Лучше сразу к хорошему привыкать, что бы потом жить было проще.

    @Штудер
    Привязка к jQuery тут была только для примера, и автор сразу это сказал. На этом же месте мог быть и MooTools и prototype, и практически ничего бы не изменилось, и тот и другой поддерживают и domready и css селекторы, так что разница была бы совсем не большая, тут же главное «приучить» к «ненавязчивому» JS’у, а как его реализовывать — каждый выбирает для себя сам )

    Как всегда отличная статья, спасибо.

    P.S.
    В дополнение к Grin’у:
    Вместо:

    1
    2
    3
    4
    5
    <!-- найди ошибки - получи пирожок -->
    <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
    Nunc urna metus, ultricies eu, congue vel, laoreet id, justo.
    Aliquam fermentum adipiscing pede. Suspendisse dapibus ornare
    quam. Lorem ipsum dolor sit amet, consectetuer adipiscing elit.<p>

    Должно быть:

    1
    2
    3
    4
    5
    <!-- найди ошибки - получи пирожок -->
    <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
    Nunc urna metus, ultricies eu, congue vel, laoreet id, justo.
    Aliquam fermentum adipiscing pede. Suspendisse dapibus ornare
    quam. Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p>

    и

    =>

    и

  11. Не очень понятно, зачем конвертировать в ентити те символы, что есть в UTF-8?

  13. Хорошо правильно писать Тег, а не Тэг.
    Плохо использовать два варианта.

  15. 1
    2
    <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Nunc urna metus, ultricies eu, congue vel, laoreet id, justo. Aliquam fermentum adipiscing pede. Suspendisse dapibus ornare quam. Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p>
    <a href="/index.php?mod=default&amp;act=image" title="A link"><img src="/img001.jpg" alt="The image" /></a>

  17. >>но я придерживаюсь XHTML’a ;).
    если страницы будут раздаваться как text/html ( а так они и будут раздаваться для обеспечения кроссбраузерности ) то использование XHTML не имеет практического смысла

    >>А вот насчет DOCTYPE – то пора уже взрослеть и переходить на strict
    А можно хоть один практический аргумент почему надо тратить дополнительное время на валедакцию по Strict схеме? И кстати никто не запрещал использовать таблицы в Strict доктайпе.

    >>да прописывать обязательные параметры…
    код статьи является отличным примером :), у всех изображений есть аттрибут alt, конечно он же обязательный :)), правда он всюду пустой, но это ж не беда, главное что строго по схеме!

  18. > Так сие есть требование XHTML 1.0 Strict
    покажи, плз, ссылку.

  19. XHTML Strict замечательно уживается с таблицами

    И лично мне топик не очень понравился: как-то с миру по нитке что ли.

  20. @pepelsbey:
    Пожалуй таки я не совсем однозначно написал – имеются ввиду символы которые могут поломать XML документ: &, <, >

  21. Ссылка на валидатор вроде была, он доходчиво сообщает обо всех ошибках:
    1. inline элемент „a“ должен быть внутри как минимум одного block-level элемента, к примеру, внутри „p“
    2. тег „p“ не закрыт
    3. тег „img“ не закрыт
    4. тегу „img“ требуется alt
    5. в href нужно использовать &

  22. Просто в примере апостроф выведен при помощи юникодного ентити, вот я и смутился. Тогда ясно )

  23. В целом статья понравилась, как раз к ужину было приятно почитать. Только смутили странные примеры в “Событие onload”, Антон, я думаю что первый вариант должен выглядить так:

    1
    2
    3
    4
    5
    <script type="text/javascript">
      window.onload = (function(){
        alert('Hello World');
      });
    </script>

  24. @adw0rd:
    Ваш пример – это как раз относится к правильной реализации – т.е. с привязкой к событию onload (у меня же используется jQuery).
    Но сей пример добавлю :)

  25. @adw0rd:
    При вашем варианте этот блок нужно вставлять в конец страницы после тега body иначе он не сработает. А это уже зависимость от структуры страницы.

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

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

    P.S. на самом деле я использую в основном $(document).ready() по возможности.

  28. Жаль, что пирожок никому не достанется — ошибок не пять, а четыре :) Криво закрытый p, неотбитый амперсанд в ссылке, незакрытый img, отсутствующий alt.

    Что касается JS, то тут я обычно стараюсь не перегружать код всяческим мусором, без которого можно обойтись (точки с запятой, скобки в явно завершённых стейтментах вроде if (!var) return). Не очень понимаю, зачем все гайдлайны советуют делать иначе.

  30. Честно говоря, мне кажется, что Вы не правы по поводу “Никогда не используйте аттрибуты on**”. Вы так говорите, как будто по стандарту их запрещено использовать. Но ведь это Ваше личное мнение.

    Использовать привязку событий к элементу через jQuery – это извращение, имхо. Я уж не упираюсь в то, что jQuery используется далеко не везде и уже во многих проектах он бывает лишним.
    Обращение к элементу через tagName.className, приводит к тому что jQuery ходит по DOM’у в поисках тега, если я не ошибаюсь. Если у меня на странице форма с 20 сабмитами, то страница будет 20 раз прочесана, чтобы привязать события. Это как калькулятор на Php или проверка правильности мыла через ajax.

    Может будем все атрибуты и классы стилей через jquery отдавать?

  31. @Kalan: Это наверное потому, что вы не работали в большой команде или не писали большие скрипты.
    Я всегда пользуюсь JSLint oт небезизвестного Douglas Crockford. Внедрили его стандарты на код в компании (ссылка в статье). Кстати автор статьи ссылку-то привёл, а сам не следует: фигурная скобочка должна быть на той же строке, что и команда к ней относящаяся (if, function, return, etc)

  32. Статья неплохая, но вот опять развод холивара по поводу отступов!
    Не стоит их рекомендовать только потому что вы их ставите!
    Тот у кого падает читаемость кода без отступов сам к этому придет. А для всех остальных – код без отступов нормально читаем. Это же вам не код в одну строку! =) Притом многие редакторы, включая бесплатные, позволяют показывать текущее положение.

    И в вашем примере код с отступами идет в какой-то вообще бредовой структуре – элементы на одной строке расположены абсолютно не логически.

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

    01
    02
    03
    04
    05
    06
    07
    08
    09
    10
    11
    12
    <ul class="bigBarNavigation">
    <li>
    <a href="/">Home</a>
    </li>
    <li>
    <a href="/about.html">About Us</a>
    </li>
    <li>
    <a href="/contact.html">Contact Us</a>
    <div class="subMenu"><!-- Example --></div>
    </li>
    </ul>

    И где здесь плохая читаемость кода? =)

  34. @stolho:
    Ваш пример так же читается плохо, не смотря на то, что он более структурирован…

    @Vadim Voituk:
    Ссылки есть в статье…

  35. =)
    Честно говоря ожидал такой ответ!
    Не буду больше дискуссировать по этому поводу – каждый все равно останется при своем мнении!

    Тут кроме того играет роль еще и привычка.Заметил по знакомым программистам. Когда одним отдаешь готовую верстку – они сразу же начинают с ней работать, другие – выбирают в редакторе авто-форматирование. =)

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

  36. @stolho:
    Возможно это вопрос привычки, кому как – но я думаю Вы замечательно прочитаете код с отступами, а вот Ваш код без оных может вызвать ступор у части программистов, собственно я призываю использовать их дабы охватить наибольшую часть аудитории (опять же ИМХО)…

    Использую Eclipse, который Zend Studio + Aptana для HTML/JS/CSS

  37. Антон, вы навешиваете эвент JS-а используя селектор по классу, хотя по всем правилам логики class используется для элементов, когда их >1. И $(‘EL.classA’).click(..) не сработает в IE для второго элемента попадающего под эту выборку(если их 2 и более), нужно будет использовать each. Отсюда сам когда-то пришел к выводу, что классы – исключительно приблуда для CSS, а эвенты навешиваю только по id или выбирая элемент через .parent() .child() и тд, если требует того задача.

  38. stolho
    Представьте, вложенность:

    01
    02
    03
    04
    05
    06
    07
    08
    09
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    <div>
    <div>
    <div>
    <span>
    </span>
    <span>
    </span>
    <span>
    </span>
    </div>
    <span>
    </span>
    <span>
    <div>
    <span>
    </span>
    <span>
    </span>
    </div>
    </span>
    <span>
    </span>
    </div>
    <span>
    </span>
    <span>
    </span>
    </div>

    Как быстро Вы удалите второй див?

  43. Относительно JavaScript’a можно использовать мозилловский стайл гайд – https://developer.mozilla.org/En/JavaScript_style_guide (стайл гайд, описанный Крокфордом похож, за исключением того, что используется 2 пробела, а не 4). Также, этот стайл гайд похож на гайд от Java.

    Кстати, jQuery, как раз-таки, не соответствует этим стандартам =)

    … что 4 пробела – это в 4-ре раза больше трафика чем один символ табуляции :)

    Пока табы не стандартизированы, лучше, все же использовать пробелы. Любой нормальный редактор поддерживает софт-табы. А для оптимизации используется обфускация. С одной стороны табы хороши – каждый видет свои отступы в зависимости от размера таба. Но 207%, что завтра, кто-то (пусть даже случайно) возьмет да и поставит в одной строке 4 пробела (по его кол-ву табов), в итоге у меня код съезжает (таб 2 пробела). В случае с договоренным количеством пробелов, такой проблемы не будет.

    jQuery фреймворк, ибо удобно, быстро, и красиво

    jQuery в этой статье практически приравнен к JavaScript’y =)

    Old-school style – хорошо … А теперь с использованием jQuery

    Туда же относится. Понимаете, таким образом Вы сеете безграмотность среди тех, кто знает JS пока на начальном уровне. В итоге будут думать, что организация onDOMContentLoaded – это что-то, что существует лишь благодаря “великому” jQuery =)

    Кстати, ничего против jQuery не имею. Библиотека хоть и тяжелая, но очень удобная (особенно тем, кому глубоко в JS разбираться не надо и не хочется).

    Что касается JS, то тут я обычно стараюсь не перегружать код всяческим мусором, без которого можно обойтись (точки с запятой

    Б. Айк ввел механизм автоматической вставки точки с запятой, чтобы JS (по его словам) был “более лоялен к ошибающимся, новичкам и непрофессионалам”. Всем остальным точку с запятой ставить в обязательном порядке.

    В целом, хорошая статья. Призыв к единым стандартам – дело благородное ;)

    .ps: сие, таки – что за слова-паразиты у Вас? =) вся статья ими пропитана. Иной раз к месту, но здесь – чересчур.

  44. Стардарты, фигнярты. То что вы написали ерунда чуть менее чем полностью. Наполовину очевидные вещи, наполовину вполне не обязательные и даже вредные если делать только так а не иначе. И смешаны понятия стандарты хорошего тона при кодировании с собственно, стандартами HTML, CSS..
    Да и какие это стандарты, это так, набор мыслей, далеко не являющихся истиной в последней инстанции..
    Как уже сказали, jQuery не панацея. Иногда нет смысла подключать лишние библиотеки, а иногда используются совсем другие, например офигенная либа Extjs. Но это никак не отностится к стандартам ). За стандартами – добро пожаловать на w3c.org, тока читать много )).
    Кстати, я склонен к тому, что навешивать события лучше и правильнее всего через addEventListener типа такого
    window.addEventListener(‘load’, function () {alert(‘loaded’)}, true) правда кажется с этим в IE проблемы, лень искать. Это позволяет добавить сколько угодно слушателей.

    И кроме того можно код включать в конце страницы, чтоб не навешивать что-то на body.onload.

    http://validator.w3.org/check?uri=http%3A%2F%2Fanton.shevchuk.name%2Fjavascript%2Fhtml-css-javascript-standarts%2F&charset=(detect+automatically)&doctype=Inline&group=0
    а говорите о стандартах

    Кстати не верно, а надо …

  45. @Dmitry A. Soshnikov:
    Спасибо за комментарий и ссылку…
    Насчет табов – сам использую 4 пробела в (X)HTML и CSS – в соответствии с PHP стандартами :)
    Слова паразиты – ну тут да, присутствует сей недочет…

    @Мудоид:
    Собственно W3C – это стандарты языков (X)HTML и CSS – но ни как не стандарты кодирования – т.к. даже самый нечитаемый код может быть валиден – собственно – W3C – это как компилятор/интерпритатор – он лишь может сказать в какой строчке ошибка.
    Собственно я не та инстанция, которая может вводить стандарты – по этой причине – это лишь правила хорошего тона, хотя в моем отделе – это стандарты :)
    jQuery – не панацея – а лишь фреймворк который мне более всего симпатичен, и на его примере удобно показывать разделение (X)HTML и JavaScript’a

    Код в конце страницы – противоречит разделению (X)HTML и JavaScript’a.

    Насчет валидации данной страницы – то я не собираюсь заниматься переписыванием всех плагинов для WordPress’a дабы они проходили W3C валидацию (при этом главная страница сайта показывает зеленый цвет)

    P.S. “Офигенная либа ExtJs” – спасибо, не надо – проходили…

  46. Извините, но вы вносите сумбур в понятие “Стандарт”

    Пример. Название ID и классов – не стандарт. Это ваши рекомендации. К тому же спорные местами. А вот пример с неправильной последовательностью блочно-строчных тегов [h] и [a], или размещение стилей в body – это из области стандартов.

    Имхо все что касается w3c-стандарта нужно заменить одной строкой – “Хорошая верстка должна проходить проверку без ошибок (и предупреждений)” Кстати у вас в img отсутствует alt. Не ошибка. Но лучше чтобы и warning’и не мозолили глаза.

  47. Почему простой алерт – это плохо, а алерт внутри сложной структуры, приводимый в действие с помощью огромного!!! количества процедур – это хорошо? Вот, который раз уже вижу этот наивный пример с алертами… ;)

    Old-school style

    Ух ты, уже ‘old’, как время-то летит…

  48. @Мудоид,
    @Исаак Тынгылчав,

    Имелось в виду Programming style guide.

    Просто Anton Shevchuk назвал статью “стандарты кодирования“, в то время как в большинстве случаев описывал приемы программирования (предложенные некими персонами).

    Так, к примеру, “ненавязчивый JavaScript” – это прием, который позволяет расширить аудиторию сайта, привлекая людей, у которых JS отключен вовсе, либо людей с браузерами, сшитыми при царе Горохе, где JS не поддерживается. Здесь речь даже не о JS и не о правилах кодирования, а о построении сайтов. Однако, если речь будет идти именно о полной JS-системе (не сайте! и не блоге!), то здесь эти правила уже не актуальны и уж тем более не могут быть представлены определением “Стандарт”.

    Но зачем придираться? Ведь человек, просто привел интересные и полезные приемы, которые позволят сделать сайт лучше (а код – более структурным и чистым).

    @Исаак Тынгылчав:

    Пример. Название ID и классов – не стандарт. Это ваши рекомендации. К тому же спорные местами.

    Да, фишка в том, что официальных “бумаг”, подтверждающих то или иное положение мало. К примеру, я привык (поскольку являюсь JS-программистом) использовать camelCase для именования функций и переменных. Однако, в официальном (вот это важно! хорошо, когда на официальном сайте вывешен style guide языка) гиде кодирования Python’a написано, что для именования переменных используется underscore_case. И все, локальные привычки здесь не уместны. Если вы хотите писать код на международном уровне – пишите его согласно официальным style guide’ам, потому что понятия “профессиональный почерк” никто не отменял.

    Более того, в каждом официальном style guide написано, что можно все же пренебречь им в пользу стиля локальной компании (а отсюда начинаются холиворы). Так и Дж. Резиг (вероятно из-за любви к Питону) забил на общепринятые (но не официальные) стандарты кода в JS и написал jQuery в Python-стиле (хотя, на самом деле – кашеобразном стиле, т.к. там присутствуют разные стили).

    В этом плане мне понравился подход Python’a в плане отступов – компилятор вообще выдаст ошибку, если будет неверное количество отступов, принятое в начале кода. Этакая принудительная (но полезная) мера, обращенная придать коду единый вид.

    Что же касается валидации – компиляторам пофиг, как у вас код написан – в одну строчку или с отступами. Это касается стандарта языка, но не стандарта кодирования.

  49. Привет, Zeroglif! ;)

    Почему простой алерт – это плохо, а алерт внутри сложной структуры, приводимый в действие с помощью огромного!!! количества процедур – это хорошо?

    Я позволю себе рассказать прописные истины (но не тебе, конечно, а так – просто вслух).

    Все это вытекает из усиления абстракций. А любая последующая абстракция несет, как правило, потери в производительности. Тут вопрос лишь в том, кто “стоял у руля”, когда создавал новую абстракцию (которая позволит писать код еще короче, еще быстрее)?

    Это было (и будет), естественно, постоянно (в одном из параграфов Лебедева нечто подобное описано – http://www.artlebedev.ru/kovodstvo/sections/151/). Но речь именно об ухудшении потребления ресурсов для обеспечения новой абстракции. Но в то же время – и об улучшении (или лучше сказать – об упрощении) интерфейса общения с объектом, для которого эти абстракции разрабатывались (в данном случае, это машина).

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

    Утрированно: было так:

    1
    2
    3
    mov dx, offset someString
    mov ah, 09h
    int 21h

    создали новый язык (абстрагируясь от ассеблера), и стало так:

    1
    printf(someString);

    что там сейчас внутри происходит? – знают только профессионалы (образно, опять) асма и сетуют, что – ну тяжелый это язык – Си. И они правы, но уже ничего не сделать. Остальным же – пофигу абсолютно!

    И все дальше и дальше. Что правит этим? Лень? Не знаю – возможно (но это, как правило, в случае с теми, кто, возможно, и не программист вовсе. Просто, благодаря программистам, у него появилась возможность тоже стать программистом на этом новом уровне абстракции). В идеале, по одной из теорий, ручной ввод кода должен быть вообще сведен к минимуму (“Правило генерации: избегайте ручного ввода кода; при любом возможном случае пишите программы, которые бы писали программы”). Ясно-понятно, что подобные системы должны учитывать множество комбинаций и тем самым будут более тормозными, по сравнению с предыдущими, которые писали “лишь половину” за нас. Но – железо-то тоже развивается – в итоге, на мощных машинах эта тормознутось не заметна.

    Так появляются различного рода фестивали (например, посвященные демо-сценам), где собираются мастера программирования и на чистом ассемблере пишут код в 64Кб, общаясь с железом в реальном времени и умудряясь запихать в этот код столько красивой графики и музыки. Это своего рода – “смотрите, как можно! А вы со своим jQuery тут тормознутым!” Но – у руля стоял Дж. Резиг, которому помогли большие институты пропихнуть эту либу в массы – в итоге, либа уже включена в состав .Net’a =), хотя профессионалы JS видят в ней кучу недочетов.

    Возможно, скоро появятся большущие либы написанные уже на jQuery, и так же – поклонники jQuery будут находить к них неоптимальные места и сетовать уже на эту абстракцию, которая может выглядеть так (это будет язык, а не либа):

    1
    2
    3
    создайМнеСайт(даПобыстрей);
    создайБлог;
    сделайМеняАдмином;

    Это может показаться устареванием относительно новых абстракций, но это не так! Вовсе не так! От точки отсчета абстракции, на которой подключились мы, мы идем всегда дальше, просто видя недочеты в новых абстракциях, и стараясь эти недочеты устранить – советами (у меня, к примеру, такое ощущение, что всегда будет у тебя что спросить, относительно JS =)), еще чем-то (не суть). Другие либо не могут видеть эти недочеты (они только что подключились – на этом этапе абстракции), либо не хотят видеть (на кой ляд им это “mov ax, 09h”, если надо вывести красивый алерт onDOMContentLoaded?).

    Все, закругляюсь =) Прошу извинить за прописные истины – просто отстранено порассуждал вслух.

  50. @ Dmitry A. Soshnikov

    “ненавязчивый JavaScript” – это прием

    Высосанный из пальца термин. Зобмирует публику, которая обычно начинает (и часто заканчивает) расшифровывать его, как “сайт должен работать без js” и “отделяем А от Б”. И первое, и второе совершенно не обязательно и непосредственно от js далеко.

Comments are closed.