استخدام SwiftLint والخطر لأفضل ممارسات Swift

ظهرت هذه المشاركة في الأصل في Swift Post ، وهي متاحة هنا.

أصبحت Apple's Swift أكثر وأكثر شعبية بين مجتمع المطورين. بدأ معظمنا بالفعل في تكييف مشاريعنا مع هذا الشعب. أثناء التبني ، قد لا نكون حذرين كما يجب أن نكون مثل Swift هي لغة مرنة للغاية ومن السهل حقًا إساءة استخدامها. إن تطبيق أفضل الممارسات ، لا سيما من ثقافة الهدف ، أصبح مهمًا جدًا.

بعد قراءة Swifty Tips من Göksel ، أدركت أنه يمكن التحقق من بعض تلميحاته تلقائيًا باستخدام SwiftLint. أيضًا ، نحن كسولون ونميل إلى نسيان التحقق من الكود لدينا قبل الاندماج لإتقان. هنا فقط ، يأتي خطر إلى المسرح بملابس لامعة ويشير إلى أننا نفعل شيئًا خطيرًا.

تبدو مثيرة للاهتمام ... ولكن ما هي هذه الأدوات ، في الواقع؟

SwiftLint

SwiftLint هي أداة مفتوحة المصدر لفرض أسلوب Swift والاتفاقيات. تم تطويره من قبل عالم. يمكنك تعيين قواعد أسلوب الترميز وإجبارها أثناء التطوير. SwiftLint لديه أداة سطر الأوامر ، البرنامج المساعد Xcode ، AppCode وتكامل Atom. لذلك ، دائما يناسب بيئة التطوير الخاصة بك. سيعرض لك تحذيرات و / أو أخطاء إذا انتهكت قواعد الفحص.

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

دعونا نلقي نظرة على نصائح Göksel. يقول ، "لا تستخدم أبدًا ضمنيًا فك الارتباطات". يوفر SwiftLint هذا افتراضيًا بالضبط كيف يصف. سوف يحذرك SwiftLint عندما تقوم بفك ضمنيًا اختياريًا إلا إذا كان IBOutlet. والآخر هو "تجنب _ سوء الاستخدام". SwiftLint ذكي بما يكفي للإشارة إلى عدم استخدامك لاختياراتك المنضمة.

إذا سمحت _ = Foo.optionalValue {} // Trigers تحذير
if case .some (let _) = self {} // مشغلات تحذير
إذا foo () {let _ = bar ()} // لا يتم تشغيل تحذير
إذا foo () {_ = bar ()} // لا يتم تشغيل تحذير

بالإضافة إلى تطبيق أفضل الممارسات بشكل فردي ، نريد أن نجعل قاعدة الشفرة متسقة. اجعله أسهل في تطبيق القواعد المخصصة. يجب أن تتناسب هذه القواعد مع أفضل الممارسات. تتم معالجة تكوين linting من ملف. swiftlint.yml. يقع هذا الملف في المسار الرئيسي للمشروع. يمكننا تمكين أو تعطيل أو كتابة القواعد المخصصة في ملف YML هذا. دعنا نلقي نظرة على بعض الأمثلة.

أول الأشياء أولاً ، كتابة وظيفة كبيرة هي عمومًا علامة سيئة. إذا كانت وظيفتك تزداد ، فهذا يعني أنه يجب عليك تقسيم المسؤولية. أضف قطعة الكود التالية إلى ملف. swiftlint.yml. يحذر هذا المطورين من أن يكون لديهم وظائف أقل من 200 سطر. إذا وصل المبرمج إلى 300 ، يقوم SwiftLint بإنشاء خطأ. تذكر أنه يمكنك تجاهل التحذيرات ولكن ليس الأخطاء.

function_body_length:
 - 200 # تحذير
 - 300 # خطأ

يحتوي كل مشروع تقريبًا على تبعيات أو أجزاء التعليمات البرمجية التي لا يمكن تغييرها. لا ينبغي أن تصطف هذه القطع رمز على الإطلاق. على سبيل المثال ، إذا كان المشروع يستخدم CocoaPods كمدير تبعية ، فسيحتوي على مجلد Pods الذي يحتفظ بجميع ملفات التبعية. نحتاج إلى استبعاد هذا المجلد من عملية الفحص. كما ترون أدناه ، الأمر سهل للغاية.

مستبعد:
  - القرون

إرشادات الشركة أو المطور الذي يعمل في المشروع لديه أسلوب ترميز. SwiftLint يساعد القادمين الجدد على تبني هذه الأنماط أثناء عملية onboarding.

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

أضف هذا التعليق لتعطيل القاعدة في الملف:

// swiftlint: تعطيل rule_name

أضف هذا التعليق لتعطيل القاعدة في السطر التالي:

// swiftlint: تعطيل: next rule_name

أضف هذا التعليق لتعطيل القاعدة في السطر السابق:

// swiftlint: تعطيل: rule_name السابق

يمكنك الحصول على قائمة بجميع القواعد عن طريق تشغيل الأمر swiftlint rules في المحطة الطرفية.

أخيرًا ، وضعنا اللمسات الأخيرة على قواعدنا ، والآن يمكننا وضع قواعد في سلام. ولكن حتى في بعض الحالات ، يجب أن تكون أكثر حذراً من مجرد تطبيق قواعد الفحص الخاصة بك. هذا هو المكان الذي يأتي الخطر في مكانه.

ملاحظة: يمكنك العثور على ملف. swiftlint.yml المحدد مسبقًا هنا in.

خطر ️

كل مشروع / قطعة من التعليمات البرمجية لها تدفق خاص بها. عندما ينمو المشروع ، تصبح صيانة وإضافة ميزات جديدة أكثر صعوبة. خطأ يزيد عرضة. إن وجود إرشادات الترميز وتطبيق أفضل الممارسات لا يكفي عمومًا. نحن بشر ، نخطئ. يمكن أن يلحق الخطر الأخطاء الأساسية ودعونا نفكر في المشكلات الصعبة. على سبيل المثال ، يمكنه التقاط أخطاء مطبعية شائعة أو تغييرات في ملفات تم إنشاؤها لا ينبغي عليك تغييرها بنفسك. يمكن أن يجبرك أيضًا على كتابة الاختبارات إذا كتبت أكثر من 20 سطرًا من التعليمات البرمجية. القواعد في يديك مثل SwiftLint.

خطر هو جوهرة روبي الذي يعمل في CI أثناء عملية طلب سحب / دمج. إنه يترك الرسائل أو التعليقات أو حتى يفشل في بناء CI عندما تنتهك قواعدك. يمكن تشغيل الخطر على العديد من أدوات CI ويمكن الدردشة على GitHub و Bitbucket و GitLab.

خطر يمكن أن يترك رسائل ، تحذيرات ، أخطاء على PR / MR. المصدر: خطر

يمكنك اتباع دليل الإعداد هنا لتثبيت Danger لعملية CI. الخطر يطبق القواعد من نص روبي المكتوب في Dangerfile. دعونا نلقي نظرة على ما يمكننا القيام به هناك.

للمسؤولية الفردية ومراجعة الكود الأسهل ، لا ينبغي للمطورين فتح طلبات السحب الكبيرة. إذا كان طلب السحب يحتوي على أكثر من 600 سطر من التعليمات البرمجية ، فيجب أن يكون هناك تحذير لتقسيم طلب السحب. يمكن أن يوفر الخطر هذا بسطر واحد من التكوين:

قم بتحذير "كبير العلاقات العامة ، والنظر في تقسيم إلى أصغر" إذا git.lines_of_code> 600

ماذا بعد؟ إذا كنت تعمل مع عملية تطوير Test-After ، فيمكنك بسهولة نسيان كتابة الاختبارات. من ناحية أخرى ، يجب أن يكون هناك طريقة تلقائية لتعليقات "لقد نسيت إضافة الاختبارات". بشكل عام ، إذا قمت بتغيير أكثر من 20 سطرًا من التعليمات البرمجية ، فيجب عليك كتابة الاختبارات. يعتمد عدد الخطوط على قرارك ، لكنك حصلت على الفكرة. دعونا نلقي نظرة على كيفية تحقيق ذلك مع Danger:

## دعونا نتحقق مما إذا كانت هناك أية تغييرات في مجلد المشروع
has_app_changes =! git.modified_files.grep (/ ProjectName /). فارغة؟
## ثم ، يجب أن نتحقق من تحديث الاختبارات
has_test_changes =! git.modified_files.grep (/ ProjectNameTests /). فارغة؟
أخيرًا ، دعنا نجمعها ونضع شروطًا إضافية
## لتغيير عدد أسطر التعليمات البرمجية
إذا كان has_app_changes &&! has_test_changes && git.lines_of_code> 20
  فشل ("لم يتم تحديث الاختبارات" ، مثبت: خطأ)
النهاية

الخطر مناسب لكل أنواع المشاريع. يوفر مجموعة واسعة من التكوينات إلى عدة لغات بواسطة الإضافات. في حالة Swift ، طور Ash Furrow مكونًا إضافيًا لـ SwiftLint. بفضل هذا المكون الإضافي ، يمكن أن نحصل على تحذيرات SwiftLint كتعليقات مضمّنة في طلب السحب. يمكنك رؤية دليل التثبيت هنا. بعد التثبيت ، ستحتاج إلى إضافة أحد الأسطر التالية إلى نهاية Dangerfile.

swiftlint.lint_files
swiftlint.lint_files inline_mode: true

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

ملاحظة: ليس عليك تكوين CI. من الممكن تشغيل ميزة Danger على جهازك المحلي باستخدام أمر محلي خطر.

بفضل استجابة Eren ، إذا لم يتم تشغيل أمر محلي بالخطر عبر آخر العلاقات العامة المفتوحة ، فيمكنك دائمًا استخدام الأمر التالي:

risk pr https: // YOUR_PR_URL --dangerfile = YOUR_DANGERFILE_PATH

ملاحظة: يمكنك أن تجد ملف Dangerfile المحدد مسبقًا هنا .

المكافأة: SwiftLint مع بوابة هوك

إذا كنت تعمل مع برامج تحرير نصية مختلفة أو معرفات بيئة تطوير متكاملة لا يدعمها SwiftLint ، فيمكنك استخدام أدوات سطر الأوامر فقط لترميز الشفرة. هذه خطوة إضافية ويسهل نسيانها. شيء جيد ، يمكننا أتمتة هذا. ميزة الخطاف في Git هي مكان آخر لأتمتة الأشياء. بشكل أساسي ، فإن خطافات Git عبارة عن نصوص يتم تنفيذها من خلالها Git قبل أو بعد أحداث مثل الالتزام والدفع والاستلام. يمكننا تشغيل SwiftLint في واحدة من هذه البرامج النصية. أنا شخصياً أستخدم SwiftLint في خطاف الالتزام المسبق أثناء كتابة Swift في نص Sublime.

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

النهاية

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

شكرا للقراءة! ساعد في نشر الكلمة .

هل لديك أسئلة أو اقتراحات أو تعليقات أو أفكار لمشاركات المدونات القادمة؟ الاتصال بي على تويتر أو كتابة تعليق! also يمكنك أيضًا متابعتني على GitHub.

مشاركاتي الأخرى:

  • استخدام Firebase Cloud Messaging للإشعارات عن بُعد في iOS
  • أول الخبرات من جانب الخادم في سويفت - أساليب HTTP وعمليات قاعدة البيانات
  • جعل Swift Backend API Testable - اختبارات الوحدة في تطبيق سويفت من جانب الخادم