Како да оптимизујете ЦСС са водичима стилова кода

Када дизајнери говоре о стилу водича, они обично значе договорени приручник на кохерентан изглед и осећај веб странице или апликације, са добро осмишљеним шема боја, типографија и корисничко сучеље који се користи у целом пројекту.

Постоји још један тип водича за стил који можемо да користимо иу веб развоју, и он је једнако важан, али много рјеђе разматран: стилски водичи за сам код. Водичи за стил кодова су више за програмере него за дизајнере, а њихов главни циљ је оптимизација ЦСС-а или другог кода.

Употреба одговарајућих водича у стилу кода нам омогућава а боље организована, конзистентна база кода, побољшана читљивост кода и више одрживог кода. Није случајност да их велике компаније, као што су Гоогле, АирБнБ или Дропбок, добро користе.

У овом посту ћемо погледати како можемо паметно оптимизирати наш ЦСС уз помоћ водича за стил ЦСС кода.

Водичи за стилове кодова и библиотеке узорака

У нашој индустрији постоји одређени степен неизвјесности о томе што можемо назвати стилским водичем. А Лист Апарт на пример, користи га синонимно са термином либрари либрари у овом чланку, али можемо да налетимо на ову врсту дефиниције иу другим постовима.

С друге стране, постоје и публикације, као што су ЦСС Трицкс или Брад Фростов блог, које разликују водиче за стилове кода од библиотека узорака. Овај други приступ нас вероватно води ближе добро оптимизованој веб страници, као дозвољава нам да одвојено обрадимо код и дизајн, тако да ћемо ово користити у овом посту.

Водичи за стилове кода и библиотеке образаца укључују стратегију за стилинг, али различите врсте. Библиотеке образаца, као што су Боотстрап, Зурб фондација, ББЦ-јев глобални језик искуства, или библиотека образаца МаилЦхимп-а, пружају нам корисничко сучеље са премасе ЦСС класама, типографијом, схемом боја, понекад мрежним системом и другим дизајнерским обрасцима..

Водичи за стил ЦСС кода, као што су Еверноте или ТхинкУп (или они који се спомињу у уводу) садрже правила о писању ЦСС-а укључујући ствари попут конвенције именовања, структура датотека, редослед својстава, форматирање кода, и други.

Имајте на уму да живи генератори водича за стил, као што су КСС, Стиледовн или Паттерн Лаб, генеришите библиотеке образаца и не стилски водичи за кодирање. Док су библиотеке образаца такође веома корисне и подижу процес развоја веба, не дозвољавају нам да оптимизујемо сам код.

Направите Водич за стил ЦСС кода

Коначни циљ водича за стил ЦСС кода је да обезбедимо да можемо да радимо са конзистентном, лако дебагујућом базом кода коју су написали програмери који сви прате иста правила стила кода. Креирање водича за стил ЦСС кода може потрајати мало времена, али вреди труда, јер то морамо урадити само једном. Онда можемо користити исти водич кроз различите пројекте.

Важно је напоменути да су најбољи стилски водичи не садржи само правила за обликовање, већ и примере добре и лоше употребе, јер на овај начин програмери могу интуитивније разумети правила.

На пример, АирБнБ показује добрим и лошим примерима за програмере на следећи лако пробављив начин:

Структура датотеке

Прво, морамо да смислимо логику према којој ћемо организовати ЦСС фајлове. За мање пројекте један ЦСС фајл може бити довољан, али за веће је увек боље разбити код, и спојити одвојене датотеке касније у продукцији.

Неки стилски водичи као што је ТхинкУп, такође нас упозорава не користи уграђене или уграђене стилове осим ако је то неизбежно; то је такође корисно правило које се вреди применити.

Нестинг

Гнијежђење је одлична особина у ЦСС-у, али понекад може и изван контроле. Нико се не осећа посебно срећним, нарочито у сред фрустрирајућег процеса отклањања грешака, бумперујући у екстра дугачке селекторе као што је овај:

 .цласс_1 .цласс_2 # ид_1 # ид_2 ли спан цолор: #бад;

Тако да је увек добро поставите разумну границу гнијежђења, на пример, ГитХуб је изабрао три нивоа у свом стилском водичу. Ограничавањем гнијежђења можемо се и присилити да напишемо боље структурирани код.

Правила именовања

Коришћење кохерентних правила за именовање за ЦСС селекторе је од кључног значаја ако желимо да разумемо наш код месецима или чак годинама касније. Постоје многа решења, и постоји само једно строго правило које морамо слиједити тј. име селектора не може почети бројем.

Четири уобичајена стила која се користе у именовању селектора су .мала слова, .ундер_сцорес, .дасх-ес, и .ловерЦамелЦасе. У реду је изабрати било коју од њих, али морамо слиједити исту логику у цијелом пројекту.

Користећи само имена семантичког селектора такође је неопходно ако желимо имају смислени код. На пример, уместо .црвено дугме (што не показује шта типка ради) боље је користити .алерт-буттон име (које каже шта ради), на овај начин омогућавамо развојним програмерима (и нашим будућим особама) да разумеју шта је речено дугме.

Штавише ако желимо да промијенимо боју од црвене у неку другу у будућности, лако можемо то учинити без муке. Постоје и предефинисане конвенције именовања ЦСС-а, као што је БЕМ (Блоцк, Елемент, Модифиер) конвенција, резултира у конзистентној структури именовања са јединственим и смисленим именима.

Правила форматирања

Форматирање кода обухвата ствари као што су коришћење размака, картица, увлачења, размака, прелома линија итд. У стварању не постоји универзално добар или лош метод форматирања, једино правило је да одабрати кохерентна правила која резултирају читљивим кодом, и пратите их.

Дропбок, на пример, захтева од програмера да стави размаке после двотачке у декларацијама својстава, док Еверноте користи два простора за увлачење. Можемо да поставимо онолико правила форматирања колико нам је удобно, али никад више него што је могуће схватити.

Децларатион Ордер

Уређене ствари су увек лакше видети, и наручивање ЦСС декларација (својства са њиховим вредностима) према правилу које има смисла резултира боље организованим кодом.

Погледајте на пример правила за уређивање својстава ВордПресс-а, она дефинише следећу једноставну али логичну основу за уређивање у којој су својства груписана по њиховом значењу:

Приказ
Позиционирање
Бок модел
Боје и типографија
Друго

Јединице и вредности

Одлука о томе како желимо да користимо јединице и вредности није важна само за постизање конзистентног изгледа кода, већ и ако то не учинимо, можемо завршити са нечим чудним

Замислите место које наизменично користи пк, ем, и рем мјерења дужине. Неће изгледати лоше само у уређивачу кода, али ће највјероватније неки елементи бити изненађујуће мали или велики на том мјесту.

Такође морамо да доносимо одлуке о вредностима боја (хексадецимални, ргб, или хсл), и да ли желимо да користимо скраћена својства и према којим правилима. Постоји инструкција која је укључена у сваки водич за стил ЦСС кода у који сам налетио, тј. не наводе јединице за 0 вредности (стварно, једноставно не).

.цласс // гоод маргин: 0; // бад маргин: 0пк; // бад маргин: 0ем; // бад маргин: 0рем;

Цомментинг

Кодови за коментирање су неопходни на свим језицима, али у ЦСС-у то не само да олакшава исправљање грешака и израду документације, већ и секције ЦСС правила у логичке групе. Можемо користити било који / *… * / или //… стил нотације за коментаре у ЦСС-у, важна је ствар останите доследни са коментарима кроз наш пројекат.

На пример, идиоматски ЦСС успоставља смислен систем за коментирање који чак користи неке основне АСЦИИ уметности и резултира у лепо организованом коду: