بهترین تمرین در CSS: قراردادهای سازماندهی و نامگذاری

نوشتن کد آن طور که به نظر می‌رسد آسان نیست. بدون برخی از قوانین نوشتن، هر کدی پیچیده برای خواندن و دشوار برای عیب یابی است. بنابراین اقدامات خوب در CSS چیست که بتوان جلوی این قبیل مشکلات را گرفت؟

من بیش از سه سال است که کد می‌نویسم. همیشه از خودم در مورد روش‌های خوب و اینکه چگونه می‌توانم کد خود را خواناتر، قابل فهم، با نگهداری آسان به طوری‌که توسط سایر توسعه دهندگان قابل استفاده باشد، سوال کرده‌ام.

ما زمان بیشتری را صرف خواندن کد خود می‌کنیم تا نوشتن آن. زیرا همیشه به دنبال عنصری هستیم که بتوانیم آن را اصلاح کنیم، بهبود دهیم یا فقط بخاطر داشته باشیم که چگونه آن عنصر کار می‌کند. بنابراین مهم است که یک کد خوب یا به عبارتی یک کد تمیز، ثابت، قابل گسترش و صحیح بنویسید.

از stickler استفاده کنید

Stickler ابزاری قدرتمند است که به توسعه دهنده اجازه می‌دهد تا استانداردهای کد نویسی قبل از تحقق پروژه توسط خود یا تیم کاریش را رعایت کند. قبل از نوشتن هر خط کد، اغلب توسعه دهندگان استانداردهای کد گذاری را تعیین می‌کنند که برای تحقق پروژه‌ای که می‌خواهند روی آن کار کنند، از آن‌ها پیروی کنند. این ابزار در چندین زمینه‌ به خصوص در بهبود تورفتگی کد، تصحیح خطاهای سینتکسی و شناسایی مکان‌هایی که در آن‌ها نسخه برداری از کد وجود دارد، مداخله می‌کند.

Stickler توسط جامعه گسترده‌ای استفاده می‌شود و از نظر تنظیمات کاملا انعطاف‌پذیر است.

CSS را در چندین فایل تقسیم کنید

برش کد CSS در بسیاری از فایل‌ها که هر کدام مربوط به یک ماژول، یک ویو یا یک صفحه از برنامه شما هستند، بسیار توصیه می‌شود. بسته به آنچه برای شما مناسب‌تر است، انتخاب برش آزاد است.

تقسیم كدها به چند فایل‌ باعث مي‌شود هنگامي كه بايد عبارت‌هاي جديد را تمديد، اصلاح يا ايجاد كنيم، به راحتي مسيریابی شوند.

مثال:

homepage.css
header.css
footer.css
archive.css

محاسن تقسیم CSS به چندین فایل و افزایش آن عمدتا در مواردی ظاهر می‌شود که شخصی از CSS پیش پردازنده (Sass یا Less) استفاده کند.

درک خصوصیات

خصوصیات تعیین می‌کند که قانون CSS توسط navigator اعمال شود. این یک سلسله مراتب است، نه لزوما اعمال در ترتیب قوانین CSS.

مهم است که به خاطر داشته باشید همه سلکتورها باید با کمترین ویژگی ممکن تعریف شوند. این قابلیت استفاده مجدد از سلکتور را آسان می‌کند و وابستگی به سلکتور دیگر را کاهش می‌دهد.

ارجحیت:

.myclass {...}

نسبت به:

body.page .main .sidebar article > .myclass {...}

در بیشتر موارد، این امر باعث می‌شود شما مجبور نباشید با تعارضات خاص CSS کنار بیایید.

DRY (Don’t repeat yourself – خودت را تکرار نکن) یک اصل در توسعه نرم‌افزار با هدف کاهش تکرار کدها یا الگوهای نرم‌افزاری است.

درک اصل DRY ساده است: "هر دانش باید یک نمایش واحد، بدون ابهام و معتبر در یک سیستم داشته باشد".

مثال:

.texte-erreur {
 font-size: 15px;
 background-color: #ccc;
 border-color: red;
 color: red;
}
 
.bloc-erreur {
 width: 250px;
 height: 250px;
 background-color: #000;
 font-size: 17px;
 border-color: red;
 color: red;
}

مشاهده می‌کنیم که دو کلاس از ویژگی‌های حاشیه و رنگ برخوردارند. ما می‌توانیم در نظر بگیریم که آنها همیشه برای تعداد مشخصی از کلاس‌ها با هم می‌آیند. سپس می‌توانیم یک ترکیبی ازکلاس‌های زیر ایجاد کنیم:

mixin erreur-base() {
 border-color: red;
 color: red;
}
 
.texte-erreur {
 font-size: 15px;
 background-color: #ccc;
 @include erreur-base();
}
 
.bloc-erreur {
 width: 250px;
 height: 250px;
 background-color: #000;
 font-size: 17px;
 @include erreur-base();
}

به خوانایی بیشتری دست پیدا کردیم و برای جلوگیری از تکرار، کد خود را بازسازی کردیم.

قرارداد نامگذاری

نامگذاری موارد هرگز آسان نیست و نام کلاس‌ها و ویژگی‌های id در CSS از این قاعده مستثنی نیست. مشکل نامگذاری نامناسب این است که بعدا یافتن آن در کد دشوار است، بنابراین تعیین یک قرارداد خاص برای سازماندهی مناسب کد بسیار مهم است.

در طول تحقیقاتم در مورد این موضوع، به دو کنوانسیون معروف نامگذاری برخورد کرده‌ام، به نام OOCSS و BEM.

OOCSS

برنامه‌نویسی شی‌گرا (OOP) یک الگوی برنامه‌نویسی است که بر ایجاد اشیا قابل استفاده مجدد و ایجاد روابط بین آن‌ها متمرکز است. در مقابل برنامه‌نویسی رویه‌ای که کد را در رویه‌ها (روال‌ها، زیرروال‌ها یا توابع) سازمان می‌دهد.

CSS شی‌گرا توسط توسعه دهنده وب نیکول سالیوان در سال 2008 پیشنهاد شد.

این نه پیش پردازنده و نه حتی یک زبان جدید است، بلکه فلسفه کد است.

قواعد OOCSS:

جدایی "ساختار" از "پوسته"
جداسازی "کانتینر" از "محتوا"

محتوا – پوسته:

الگوهای تکراری "بصری" را به عنوان "پوسته" های قابل استفاده مجدد تعریف کنید.
الگوهای تکراری "نامرئی" را به عنوان "ساختارهای" قابل استفاده مجدد تعریف کنید.

/* structure */
.btn {
  display: inline-block;
  font-weight: 400;
  text-align: center;
  white-space: nowrap;
  vertical-align: middle;
  -webkit-user-select: none;
  -moz-user-select: none;
  -ms-user-select: none;
  user-select: none;
  border: 1px solid transparent;
  padding: 0.375rem 0.75rem;
  font-size: 1rem;
  line-height: 1.5;
  border-radius: 0.25rem;
  transition: color 0.15s; 
}

/*SKIN*/
.btn-success {
  color: #fff;
  background-color: #28a745;
  border-color: #28a745;
}

.btn-danger {
  color: #fff;
  background-color: #dc3545;
  border-color: #dc3545;
}

.btn-warning {
  color: #212529;
  background-color: #ffc107;
  border-color: #ffc107;
}

کانتینر – محتوا:

یک شی نباید به مکانی که آن را قرار داده‌اید وابسته باشد: این اغلب علت اصلی تکثیر کد است.

.announcecategory > div:nth(3) {
  color: red;
  /*...*/
  /*BAD! div:nth(3) styles are location dependent*/
}

.announcecategory {
  display: inline-block;
  /*...*/
  /*we can reuse this category style wherever*/
}

محدودیت ها و معایب OOCSS:

کلاس‌های نرم‌افزاری نشانه‌گذاری شما را به اجرا گره می‌زند.
OOCSS قوانینی در مورد ساختاری شفاف و محکم ارائه نمی‌دهد و زمان گذشته برای فاکتورهای ظاهری اغلب می‌تواند بیش از سود استفاده مجدد باشد. این می‌تواند زمان اجرای پروژه‌ها را به میزان قابل توجهی افزایش دهد.

من صحبت‌های نیکول سالیوان را به شدت به خواننده توصیه می‌کنم: بهترین تمرین ما کشتنمان است که در سال 2011 منتشر شده است. به چندین مجتمع اجازه داده است تا OOCSS را بهتر بشناسند و از این مفهوم نامگذاری استفاده کنند.

خواننده‌ای که مایل به تفکر و تامل است، می‌تواند ویکی پدیای فریمورک OOCSS را بخواند.

اگر تا به حال با بوت استرپ کار کرده‌اید، احتمالا با خواندن این بخش متوجه شده‌اید که تیم بوت استرپ به شدت از این روش استفاده می‌کنند.

یک روش خوب دیگری برای نامگذاری وجود دارد.

BEM

BEM مخفف Block, Element, Modifier است و تمام روش‌های نامگذاری در این سه کلمه وجود دارد. آنچه یک صفحه یا یک برنامه وب را تشکیل می‌دهد، همیشه می‌تواند در یک Block، Element و Modifier ذخیره شود.

Block موجودیتی مستقل است که باید بتواند بدون تأثیر بر شکل ظاهری یا عملکرد آن جابجا شود.

یک Element (عنصر) بخشی از Block است. زمینه یک عنصر مربوط به Block است. این می‌تواند یک هدر، یک فوتر، یک کانتینر (مقالات، بخش‌ها و ...)، یک منو یا حتی یک دکمه باشد. همانطور که به وضوح به نظر می‌رسد، یک Block می‌تواند شامل Block‌های دیگری نیز باشد. یک رابط می‌تواند شامل چندین نمونه از یک Block باشد.

Modifier ویژگی است که برای ایجاد انواع مختلف، ایجاد حداقل تغییرات مانند تغییر رنگ و اندازه استفاده می‌شود. همچنین مادیفایرهای Block و مادیفایرهای Element وجود دارد.

روش BEM دارای سه قانون اساسی است:

بلاک‌ها و عناصر موجود در یکدیگر، نام منحصر به فردی دارند که از آن به عنوان کلاس CSS استفاده می‌شود.
سلکتورهای CSS نیازی به استفاده از عناصر HTML ندارند (نه از قسمت پاورقی).
از cascade در سلکتورهای CSS باید خودداری شود (نه از foo> .bar.).

قرارداد نامگذاری:

بلاک

block-name

عنصر

block-name__element-name

مادیفایر

bloc-name--modifier-name

bloc-name__element-name--modifier-name

وبسایت رسمی مراقبت می‌کند تا مشخص کند که فقط مفاهیم شمرده می‌شوند، سینتکس آزاد باقی می‌ماند.

مزایای BEM:

عملکرد: عملکرد بیشتر مربوط به برنامه وب است. نامگذاری BEM اجازه می‌دهد تا اکثر کلاس‌های CSS در سطح اول وجود داشته باشد. مرورگرها کلاس‌های CSS را در جدولی از هش جهانی سازمان می‌دهند، اما ایجاد جدول‌های فرعی برای فرزندان در سطح هر عنصر HTML بسیار پیچیده است. همچنین در CSS، تنها اولین سطح انتخاب با عملکرد بالا است. CSS Cascade، هنگامی که تعداد زیادی از آن‌ها وجود دارد، این مشکلات را ایجاد می‌کند، به ویژه در صفحات متحرک برنامه های وب.
قابلیت انتخاب: نام کلاس‌ها منطقی و شهودی است و همه اعضای تیم می‌دانند که این عنصر در وبسایت چه کاری انجام می‌دهد. BEM به هرکسی که در یک پروژه قرار دارد یک سینتکسی خاص دارد که می‌تواند به اشتراک بگذارد. بنابراین، آن‌ها در یک صفحه هستند.

محدودیت‌ها و معایب BEM:

Verbose: نامگذاری BEM کمی شفاف است. در واقع، ما متذکر می‌شویم که به محض داشتن اصلاحاتی برای پیاده سازی، خود را خیلی سریع با یک ویژگی کلاس پیچیده و طولانی سازگار می‌کنیم.

مهم است که بدانید: کنوانسیون نامگذاری آزاد است، کسی می‌تواند دو کنوانسیون ذکر شده قبلی را بسته به نیاز پروژه یا حتی اگر کسی بهتر از کنوانسیون‌های نام موجود باشد، ترکیب کند.

جمع بندی

بهترین روش‌ها بسیار مهم هستند زیرا به ما امکان می‌دهد برنامه را با توجه به خوانایی کد، قابلیت نگهداری نرم‌افزار، مقیاس پذیری، سرعت اجرا و ... بهینه سازی کنید.

منبع