Kotlin في الفريق: أسلوب الكود والاتفاقيات التي يتجادل حولها الجميع

Kotlin في الفريق: كيف تتوقف عن الجدال حول التنسيق وتبدأ في كتابة الكود

هل سبق لك أن أجريت مراجعة كود (code review) حيث كان نصف التعليقات يدور حول "ضع مسافة"، "أزل مسافة" أو "لماذا تستخدم CamelCase بدلاً من snake_case"؟ إذا كان الأمر كذلك — مرحباً بك في النادي. في أي فريق، عاجلاً أم آجلاً، يطرح السؤال: أسلوب الكود واتفاقيات Kotlin. وإذا لم يتم الاتفاق مسبقاً، فسيحاول كل فرد فرض طريقته "المثالية" في وضع الأقواس.

هذه المقالة ليست قائمة جافة من القواعد. إنها دليل عملي حول كيفية جعل كود Kotlin قابلاً للقراءة، موحداً ومناسباً للفريق بأكمله. سنناقش الاتفاقيات الرئيسية، أدوات الأتمتة والحيل التي ستوفر لك ساعات من الجدال في المكالمات.

لماذا أسلوب الكود في Kotlin ليس متعلقاً بالجماليات، بل بالمال

لنكن صادقين: العمل لا يهتم إذا كنت تضع القوس المتعرج في نفس السطر أو في سطر جديد. لكن العمل يهتم بمقدار الوقت المستغرق لدمج مطور جديد في المشروع. تظهر الأبحاث أن المطورين يقضون ما يصل إلى 40% من وقتهم في قراءة الكود. إذا كان الكود مكتوباً وفق أسلوب كود Kotlin موحد، فإن هذه العملية تتسارع بشكل كبير.

عندما يستخدم المشروع نمط كود Kotlin موحد:

\n
• يفهم أعضاء الفريق الجدد هيكل المشروع بشكل أسرع.
\n
• تتم مراجعة الكود (code review) بشكل أسرع — يبحث المراجعون عن أخطاء المنطق، وليس المسافات.
\n
• ينخفض عدد الأخطاء الناتجة عن التنسيق الخاطئ (نعم، هذا يحدث أحياناً).
\n
• تصبح فروق Git (git diffs) أنظف — تقل الضوضاء الناتجة عن إعادة التنسيق.
\n

لذلك، اتفاقيات Kotlin ليست نزوة من قائد الفريق، بل أداة لزيادة الكفاءة. والآن سنشرح كيفية تطبيقها دون ألم.

الدليل الرسمي: Kotlin Coding Conventions

لنبدأ بالأساسيات: لدى JetBrains وثيقة رسمية — Kotlin coding conventions. هذا ليس قانوناً، لكن الأشخاص الحكماء يوصون بها كنقطة انطلاق. دعنا نستعرض النقاط الرئيسية التي تسبب الجدل في الغالب.

التسمية: CamelCase إلى الأبد

يستخدم Kotlin CamelCase لكل شيء: الفئات — بحرف كبير (MyAwesomeClass)، الدوال والمتغيرات — بحرف صغير (myAwesomeFunction). الثوابت على المستوى الأعلى أو داخل الكائن — SCREAMING_SNAKE_CASE. لا توجد شرطات سفلية في أسماء المتغيرات — هذا ليس Python.

// صحيح\nclass UserProfile\nval userName: String\nfun getUserData(): UserData\n\n// غير صحيح\nclass user_profile\nval user_name: String\nfun get_user_data(): UserData

الأقواس المتعرجة: نفتح في نفس السطر

يتبع Kotlin تقليد Java: القوس الافتتاحي — في نفس سطر الإعلان. هذا غير قابل للنقاش، إلا إذا كنت تريد أن تُعتبر مهرطقاً.

// طريقة Kotlin\nfun processData(data: List<String>) {\n    data.forEach { item ->\n        println(item)\n    }\n}\n\n// طريقة غير Kotlin (لكن إذا كان الفريق بأكمله يكتب هكذا — لا بأس)\nfun processData(data: List<String>)\n{\n    data.forEach { item ->\n        println(item)\n    }\n}

المسافات: لا تبخل بها

ضع مسافات بعد الكلمات المفتاحية (if, for, when)، حول العوامل الثنائية وبعد الفواصل. هذا يحسن readability.

// مقروء\nif (x > 0 && y < 10) {\n    println("Hello, World!")\n}\n\n// صعب على العين\nif(x>0&&y<10){\n    println("Hello, World!")\n}

التنسيق التلقائي: أفضل صديق لك

التحقق اليدوي من أسلوب الكود (code style) هو من الماضي. في Kotlin، يوجد مُنسق مدمج في IntelliJ IDEA: Ctrl+Alt+L (أو Cmd+Option+L على Mac). لكن إذا كان في فريقك شخص يستخدم VS Code أو محرر آخر — فالمشاكل حتمية.

الحل: ktlint و Spotless.

ktlint: الجندي العالمي

ktlint — هي أداة تتحقق وتقوم بالتنسيق تلقائياً