فريق Swift بدون فوضى: أسلوب الكود والاتفاقيات التي ستنقذ مشروعك

مدرب بايثون أونلاين للمبتدئين

تعلم Python بسهولة دون إرهاق نظري. حل مهام عملية مع التحقق التلقائي واكتب الكود مباشرة في المتصفح.

ابدأ الدورة

كيف لا تغرق في كود الآخرين: مقدمة في أسلوب كود Swift

\n\n

تخيل: تفتح طلب سحب (pull request) لزميل، وتجد let userName بجانب let UserName، والمسافات البادئة تقفز من 2 إلى 8 مسافات، والأقواس المتعرجة تكون أحيانًا في نفس السطر وأحيانًا في سطر جديد. مألوف؟ إذا كان فريقك يكتب بلغة Swift، فستواجه الفوضى عاجلاً أم آجلاً. أو ربما واجهتها بالفعل.

\n\n

العمل الجماعي لا يتعلق بـ "ما هو مناسب لي"، بل بـ "ما هو واضح للجميع". أسلوب الكود والاتفاقيات لـ Swift ليست بيروقراطية، بل هي طوق نجاة. إنها توفر ساعات من مراجعة الكود، وتقلل من عدد الأخطاء، وتجعل الكود قابلاً للقراءة حتى بعد ستة أشهر. في هذه المقالة، سأشرح القواعد التي تعمل حقًا، وسأقدم أمثلة على Swift، وسأعطي قائمة مراجعة للتطبيق في فريقك. هيا بنا!

\n\n

لماذا يتحول Swift بدون أسلوب كود إلى جحيم

\n\n

Swift لغة شابة ولكنها صارمة. إنها تدفعك نحو الدقة: الخيارات (optionals)، الأدوية (generics)، البروتوكولات. ولكن بدون اتفاقيات داخل الفريق، حتى التركيب المثالي لن ينقذ. إليك ثلاثة أسباب تجعل أسلوب كود Swift ضروريًا لكل مشروع:

\n\n
    \n
  • سرعة الانضمام. المطور الجديد يقضي أيامًا في دراسة ليس المنطق، بل "أين يقع ماذا".
  • \n
  • مراجعة الكود. بدلاً من مناقشة البنية، تتجادلون حول المسافات. ألم مألوف؟
  • \n
  • الدين التقني. أسلوب مختلف يعني منطقًا مختلفًا. يومًا ما سينفجر هذا في الإنتاج.
  • \n
\n\n

الخبر السار: اتفاقيات Swift تم ابتكارها بالفعل. كل ما تبقى هو الاتفاق وأتمتة التنفيذ.

\n\n

التسمية: Swift Naming Convention

\n\n

Swift هي لغة ذات فلسفة واضحة: "الوضوح أهم من الإيجاز". هذا يعني أن getUserData() سيء، بينما fetchUserProfile() جيد. دعنا نستعرض القواعد الأساسية لـ Swift naming convention.

\n\n

المتغيرات والثوابت

\n\n

استخدم camelCase بحرف صغير. سمِّ الكيانات بحيث تكون مفهومة بدون تعليق:

\n\n
// سيء\nlet n = "Alice"\nlet u = 25\n\n// جيد\nlet userName = "Alice"\nlet userAge = 25\n\n// ممتاز (مع النوع)\nlet isActiveUser: Bool = true\n
\n\n

للمتغيرات المنطقية، أضف البادئات is، has، should - هذا من أفضل ممارسات Swift.

\n\n

الدوال والطرق

\n\n

يجب أن تُقرأ الدوال كجملة. الفعل + الاسم هي القاعدة الذهبية:

\n\n
// سيء\nfunc change() { }\nfunc processData() { }\n\n// جيد\nfunc updateUserProfile() { }\nfunc validateEmailAddress() { }\n\n// مع المعاملات - أكثر قابلية للقراءة\nfunc configureButton(withTitle title: String, color: UIColor) { }\n
\n\n

لاحظ: غالبًا ما يتم حذف المعامل الأول عند الاستدعاء، ولكن من أجل الوضوح من الأفضل ذكره صراحة. هذا جزء من دليل أسلوب كود Swift من Apple.

\n\n

الأنواع والبروتوكولات

\n\n

الفئات، الهياكل، التعدادات - PascalCase. البروتوكولات أيضًا، ولكن حاول جعلها أسماء صفات:

\n\n
class UserManager { }\nstruct UserProfile { }\nenum NetworkError { }\n\nprotocol Configurable { }\nprotocol DataPersistable { }\n
\n\n

التنسيق: تنفس بشكل متساوٍ

\n\n

موضوع الخلافات - المسافات البادئة، الأقواس، المسافات. دعنا نضع النقاط على الحروف. بالنسبة لـ أسلوب كود Swift، أوصي بالالتزام بمعيار SwiftLint (المزيد عنه لاحقًا).

\n\n

الأقواس المتعرجة

\n\n

توصي Apple بوضع القوس الافتتاحي في نفس السطر (أسلوب K&R). القوس الإغلاقي في سطر جديد:

\n\n
// صحيح\nif isLoggedIn {\n    showDashboard()\n} else {\n    showLoginScreen()\n}\n\n// غير صحيح\nif isLoggedIn\n{\n    showDashboard()\n}\n
\n\n

الاستثناء هو الإغلاقات (closures). يمكن أن تكون الأقواس في نفس السطر إذا كان الكود قصيرًا:

\n\n
let sortedUsers = users.sorted { $0.age < $1.age }\n

                
                

المدونات

توصيات الكتب