Вказівки щодо перегляду коду для CSS, JS та HTML


9

Мене попросили створити вказівки щодо огляду CSS, JS та HTML. Я знаю, що існують вказівки щодо кодування для JS, але я не знаю нічого про HTML та CSS. Для огляду JS я обов'язково буду дотримуватися цих вказівок та згадати їх. А як щодо CSS та HTML? Крім логічних помилок та відступів, чи є якісь конкретні речі, які мені потрібно перевірити, переглядаючи розмітку та / або CSS?


1
сьогодні це було саме на НН, можливо, це було б хорошим місцем для початку. taitems.github.com/Front-End-Development-Guidelines
agradl

Відповіді:


5

Деякі речі, на які слід звернути увагу:

  • Чи ідентифікована структурована інформація за допомогою відповідних тегів HTML? H1- H6для заголовків, UL/ OLта LIдля списків тощо?
  • Немає жодного застарілої HTML - тегів ( <b>, <i>, <center>, <font>) використовуються?
  • Чи сайт використовує найменший розмір розмітки?
  • Чи екстерналізована інформація про стиль до файлів CSS?
  • Чи весь зовнішній вигляд Javascript? включаючи обробників подій?
  • Чи посилаються назви класів CSS на функцію на сторінці ( img-caption), а не форму ( bold-red) чи вміст ( pink-elephant)?
  • Чи є зображення у відповідному форматі (PNG або JPEG, залежно від типу)?
  • Чи використовувалися мінімізовані версії бібліотек Javascript?
  • Необов’язково чи мінімізовано всі локально розроблені файли Javascript та CSS?
  • Чи підтверджує HTML / CSS?
  • Чи використовується YSlow (або подібне) для перевірки / оптимізації продуктивності?
  • (здебільшого) [SEO] Чи доступний веб-сайт із вимкненим Javascript?
  • [SEO] Чи є найбільш релевантний вміст у верхній частині HTML?

Щойно я знайшов книгу Стіва Сондерса на більш швидких веб-сайтах. Це дуже корисно, і деякі моменти, згадані вами, хороші.
Кумар

0

Одним з важливих елементів хорошого стилю в HTML є прогресивне вдосконалення . Це означає, що макет HTML буде корисним навіть без CSS або JavaScript. Потім, після обробки JS / CSS, він буде виглядати краще (наприклад, старий стиль HTML <select>стане анімованим).

Це також пов'язане з ненав'язливою розміткою. Замість <font style="color:red;font-size:16pt">Hello</font>одного використовував би <div class="red-colored-big-fond">Hello</div>.

Те саме з JavaScript. Замість <button onclick="javascript:alert('a');">Clickme</button>одного слід вказати клас / ідентифікатор кнопки та націлити його на JavaScript. Це також полегшує обслуговування коду розмітки.


0

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

Крім того, alex підкреслює чудову точку в обхідному напрямку. Переконайтеся, що ніхто не використовує назви класів типу "червоний-великий-шрифт", тому що приблизно через 20 секунд після його розгортання справжній хтось збирається змінити його на маленький синій шрифт. Я фактично бачив цей CSS:

.arial12pt { font-family: Verdana; font-size: 8pt; }

Все у вашій розмітці повинно описувати, якою є сторінка, а не як вона виглядає. Я безумовно погоджуюсь про прогресивне вдосконалення, але знову ж таки в обхідному напрямку. На сторінці немає жодних вимог виглядати десь близькими до CSS, як і без неї. Не намагайтеся зробити так, щоб вони виглядали однаково, тому що ви опинитеся в таблиці-землі та spacer.gif.


0

Що стосується HTML, я завжди зазначаю, що у своїх файлах є ієрархії та відступи. Наприклад, якщо у мене є купа дівок:

<div id="content">
   <div id="post">
     <div class="title">
       Blah Blah Title
     </div>
   </div>
</div>

Я думаю, що це досить очевидно для більшості, хто створює макети та шаблони, але частіше за все я просто бачу стислий HTML, який взагалі не має структурної ієрархії, що ускладнює читання іншій людині. Я думаю, що виходячи з більш CS-фону, це щось, що залишається в моїй свідомості. Те саме стосується і CSS. Скажімо, ви створюєте діва:

#whatever{
    background-image: url('blah.gif');
    color: #FFF000;
}

Відступ дозволяє набагато простіше швидко читати, коли ви звикли до іншої мови, змішаної як PHP / Ruby / Що б там не було. Знову ж таки, це залежить від того, як ти найкраще працюєш, але коли інші читають мій HTML, мені подобається зробити це справді організованим :).

Крім того, як було сказано вище, завжди ідеально називати ваші CSS-класи та ідентифікаційні імена відповідними іменам у вашій компоновці, особливо коли вона стає волохатою (як іменування змінних та методів іншими мовами). Ще щось, на що слід звернути увагу, - це жахливе «відгадування і перевірка» поля, прокладки та інші проблеми вирівнювання. Те, чого я часто намагаюся уникати, - це введення негативних цифр у мої поля та прокладки. Це може заплутатися, якщо ви не зробили макет самостійно і якщо хочете повернутися до нього пізніше та змінити його, можливо, доведеться його капітально відремонтувати. На мою думку, завжди гарна ідея не пробувати в CSS нічого hokey або "kludgy", навіть якщо це виглядає приємно; зазвичай є кращий спосіб зробити це, навіть якщо вам доведеться реструктурувати свій CSS!


0

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


0

Я натрапив на цей стандартний документ, який мені дуже сподобався. Я також повторюю те, що було сказано про прогресивне вдосконалення. Загалом, якщо хтось інший пише HTML / CSS, ви повинні мати змогу подивитися на це пізніше вниз за рядком і бути приємно здивованою, наскільки непогана розмітка, і потрібно вміти легко і ефективно робити перетворення стилів.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.