كانت مراجعات الكود جدلاً حول المسافات والفواصل: كيف أنقذنا Prettier من جحيم “حروب التنسيق”؟

يا جماعة الخير، السلام عليكم ورحمة الله.

قبل كم سنة، كنت في اجتماع مراجعة كود (Code Review) لواحد من الشباب الجداد في الفريق. الشب، ما شاء الله عليه، شاطر وذهنه متقد، ومخلص الشغل المطلوب منه على أكمل وجه من ناحية منطقية. لكن لما فتحنا الـ Pull Request على الشاشة الكبيرة، شفت نظرات الامتعاض على وجه المبرمج الأقدم في الفريق. بدأت التعليقات تنزل زي المطر: “ليش مستخدم دبل كوت (“) بدل سنغل كوت (‘)؟”، “المسافة قبل القوس هاد زيادة”، “ليش ما في فاصلة في آخر عنصر بالمصفوفة؟”، “المسافة البادئة لازم تكون 2 مش 4″…

خلال دقايق، تحولت مراجعة الكود من نقاش حول جودة الحل البرمجي إلى “طوشة” على التنسيق. الشب الجديد صار يدافع عن حاله، والقديم مصرّ على رأيه، وأنا قاعد بالنص بحاول ألملم الموضوع وأحكي “يا جماعة صلوا عالنبي، الكود شغال والمنطق سليم”. بس الحقيقة المرة كانت إنه هاي “الطوشة” بتتكرر مع كل مراجعة كود تقريبًا. كانت بتستهلك وقتنا، وطاقتنا، وبتحبط المبرمجين الجداد. هنا أدركت إن المشكلة مش في الناس، المشكلة في غياب النظام الآلي. ومن هنا بدأت رحلتنا مع المنقذ: Prettier.

ما هو Prettier ولماذا هو “المنقذ”؟

ببساطة، Prettier هو أداة لتنسيق الكود بشكل آلي، أو زي ما بحب أسميه “مُهذّب الكود”. لكن قوته الحقيقية مش بس في التنسيق، بل في فلسفته. Prettier هو ما يسمى بـ “Opinionated Code Formatter”، يعني “صاحب رأي حاسم”. هو ما بسألك “كيف بتحب أنسق الكود؟”، هو بقولك “هيك الكود لازم يكون”، وبيفرضه على كل الملفات.

هذا الرأي الحاسم هو اللي بيقضي على كل النقاشات. بطل فيه مجال للأذواق الشخصية. سواء كنت بتحب الفاصلة المنقوطة أو لأ، أو بتفضل الأقواس في سطر جديد، Prettier بيفرض أسلوب واحد موحد على كل الفريق. والنتيجة؟ كود يبدو وكأنه مكتوب بيد شخص واحد، حتى لو عمل عليه 100 مبرمج.

فلسفة Prettier: الرأي الواحد الحاسم

على عكس أدوات مثل ESLint اللي ممكن تعطيك مئات الخيارات والقواعد لتضبطها بنفسك (وهو أمر جيد لأمور أخرى تتعلق بجودة الكود وليس فقط التنسيق)، Prettier يركز على شيء واحد ويتقنه: التنسيق. يأخذ الكود اللي كتبته، يحلله إلى شجرة بنية مجردة (AST)، ثم يعيد طباعته من الصفر بأسلوبه الخاص. هذا يعني أنه يتجاهل تمامًا التنسيق الأصلي للكود، وهذا هو سر قوته.

نصيحة من أبو عمر: لا تحارب الأداة. الهدف من Prettier هو إنهاء الجدال، وليس خلق جدال جديد حول إعداداته. اقبل بـ 95% من قراراته، واستمتع بالوقت الذي ستوفره.

لنبدأ العمل: تثبيت وتهيئة Prettier

طيب يا أبو عمر، حمستنا. كيف نبدأ؟ الموضوع أسهل مما بتتخيل. خلينا نمشي خطوة بخطوة لمشروع JavaScript/TypeScript كمثال.

الخطوة الأولى: التثبيت في مشروعك

افتح الطرفية (Terminal) في مجلد مشروعك واكتب الأمر التالي:

npm install --save-dev --save-exact prettier

أو إذا كنت من محبي Yarn:

yarn add --dev --exact prettier

ملاحظة مهمة: أنا استخدمت --save-exact عن قصد. هذا يضمن أن كل أعضاء الفريق يستخدمون نفس الإصدار من Prettier بالضبط، مما يمنع أي اختلافات طفيفة في التنسيق بين الأجهزة.

الخطوة الثانية: ملف الإعدادات .prettierrc

صحيح أنه “صاحب رأي”، لكنه بيعطينا شوية خيارات بسيطة نتفق عليها كفريق. أنشئ ملف جديد في جذر المشروع اسمه .prettierrc.json وضع فيه الإعدادات الأساسية اللي بتناسب فريقك. هذا مثال جيد للبدء:

{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "es5",
  "printWidth": 100
}

• semi: هل تريد فواصل منقوطة (;) في نهاية الأسطر؟
• singleQuote: هل تفضل علامات الاقتباس المفردة (‘) على المزدوجة (“)؟
• tabWidth: كم مسافة تريدها للمسافة البادئة (Indentation)؟
• trailingComma: هل تريد فاصلة في نهاية العنصر الأخير في المصفوفات والكائنات؟ (أنصح بشدة بـ “es5” لأنها تسهل مراجعة التغييرات في Git).
• printWidth: أقصى عرض للسطر قبل أن يقوم Prettier بتقسيمه.

بمجرد وجود هذا الملف، يصبح هو “الدستور” الذي يتبعه Prettier في مشروعك.

الخطوة الثالثة: تجاهل ما لا يجب تنسيقه مع .prettierignore

تمامًا مثل .gitignore، يمكنك إنشاء ملف .prettierignore لتخبر Prettier بتجاهل ملفات أو مجلدات معينة. هذا مهم جدًا للملفات التي يتم إنشاؤها تلقائيًا أو مكتبات الأطراف الثالثة.

مثال لمحتوى ملف .prettierignore:

# Ignore build output
/build
/dist

# Ignore dependency directories
/node_modules

# Ignore auto-generated files
package-lock.json
yarn.lock

دمج Prettier في سير العمل اليومي (وهنا يكمن السحر ✨)

تثبيت الأداة شيء، وجعلها جزءًا لا يتجزأ من عملك اليومي شيء آخر تمامًا. هدفنا هو أن يصبح التنسيق آليًا لدرجة أنك لا تفكر فيه أبدًا.

الأتمتة هي مفتاح النجاح: خطافات Git (Git Hooks)

هذه هي أهم نصيحة سأعطيك إياها. لا تعتمد على ذاكرة المبرمج لتشغيل Prettier يدويًا. اجعل العملية إجبارية قبل كل عملية commit. سنستخدم أداتين رائعتين لتحقيق ذلك: husky و lint-staged.

1. ثبت الأدوات: npm install --save-dev husky lint-staged
2. هيئ Husky: شغل الأمر npx husky-init && npm install. هذا سينشئ مجلد .husky.
3. اربط lint-staged: عدّل الملف .husky/pre-commit ليصبح محتواه كالتالي:

   #!/bin/sh
   . "$(dirname "$0")/_/husky.sh"
   
   npx lint-staged
   

4. أخبر lint-staged ماذا يفعل: أضف هذا الجزء إلى ملف package.json الخاص بك:

   "lint-staged": {
     "*.{js,css,md,json,ts,tsx}": "prettier --write"
   }
   

ماذا يحدث الآن؟ في كل مرة يكتب فيها المبرمج git commit، ستقوم Husky بتشغيل lint-staged، والذي بدوره سيقوم بتشغيل Prettier على الملفات المعدلة فقط. النتيجة؟ لا يمكن أبدًا وصول كود غير منسق إلى المستودع (Repository). انتهت المشكلة من جذورها.

تكامل المحرر: رفيقك الدائم

للحصول على تجربة سلسة، قم بتثبيت إضافة Prettier في محرر الأكواد الذي تستخدمه (مثل VS Code). ثم، قم بتفعيل خيار “Format on Save” (التنسيق عند الحفظ). هذا يعني أنه بمجرد الضغط على Ctrl+S أو Cmd+S، سيتم تنسيق ملفك تلقائيًا أمام عينيك. إنه شعور رائع بالراحة والإنتاجية.

ما قبل وبعد Prettier: مقارنة واقعية

لنرَ الفرق على أرض الواقع. هذا كود كتبه مبرمج على عجلة من أمره:

كود غير منسق (قبل)

function    getUserData(  user,   options){
if(!user) {
console.error("No user provided!");
return null;
}
  const id=user.id;
  const allData = options.includeAllData || false;
  let data = { 'name': user.name, "id":id };
  return data;
}

نفس الكود بعد لمسة Prettier (بعد)

function getUserData(user, options) {
  if (!user) {
    console.error('No user provided!');
    return null;
  }
  const id = user.id;
  const allData = options.includeAllData || false;
  let data = { name: user.name, id: id };
  return data;
}

لاحظ كيف توحدت المسافات، علامات الاقتباس، وكل شيء آخر. الكود الثاني ليس “أفضل” من الأول من ناحية منطقية، لكنه أسهل للقراءة 100 مرة. وعندما يكون لديك فريق كامل يقرأ ويكتب الكود، تصبح هذه السهولة في القراءة عاملاً حاسمًا في الإنتاجية.

الآن تخيل مراجعة الكود (Pull Request):

• قبل Prettier: 20 تعليقًا على المسافات والفواصل، و 3 تعليقات على منطق الكود.
• بعد Prettier: صفر تعليق على التنسيق، وتركيز كامل على الـ 3 تعليقات المهمة المتعلقة بمنطق الكود وأدائه.

هذا هو الفرق الحقيقي. لقد حررنا عقولنا من التفاصيل التافهة للتركيز على ما يهم حقًا: بناء برمجيات عظيمة.

الخلاصة: وفر وقتك وطاقتك لما هو أهم 🚀

في عالم البرمجة، أكبر أعدائنا هما الوقت الضائع والقرارات غير الضرورية. Prettier يقضي على فئة كاملة من القرارات والنقاشات التي لا طائل منها. إنه لا يجعل كودك أفضل من الناحية الوظيفية، ولكنه يجعل عملية كتابة ومراجعة الكود أفضل بما لا يقاس.

نصيحتي الأخيرة لك: لا تتردد. إذا لم تكن تستخدم أداة تنسيق آلية في مشاريعك، فابدأ اليوم. اتفق مع فريقك على إعدادات بسيطة، وأتمِت العملية باستخدام خطافات Git، واستمتع بالسلام والهدوء في مراجعات الكود القادمة.

وقتك كمهندس برمجيات أثمن من أن تقضيه في جدال حول الفواصل والمسافات. دع الروبوتات تقوم بالعمل الممل، وركز أنت على الإبداع وحل المشكلات المعقدة. هذا هو جوهر الهندسة الحقيقية.

الله يعطيكم العافية.