Swift-style-guide: تصفيف بيان الحرس

يعجبني هذا الاقتراح .... مسافة بادئة 2-space 4-space:]

بدأت في الحصول على أفكار ثانية حول هذا واحد. لقد رأيت الكثير من التعليمات البرمجية السريعة ، من مؤلفي المكتبات الذين أحبهم حقًا القيام بالحراس كبطانة واحدة. أي أفكار @ JRG - Developereskerberjawwadgregheo ؟

حل وسط محتمل: اعرض جميع الأمثلة باستخدام التنسيق أعلاه ولكن دون تشريع بشأنه.

ها هي أفكاري:

• أولاً وقبل كل شيء ، اجعل النص يبدو جيدًا في الطباعة / الويب / أيًا كان التنسيق المقصود. في كثير من الأحيان ، يعني هذا إضافة المرتجعات حيث ربما _ لا_ تتضمن المرتجعات في Xcode.

• بالنسبة للحراس أحادي البيان ، أنا أفضل هذا في الواقع:

guard let strongSelf = self else { return nil }

المنطق الذي أراه هو أنه _ليس _ عادةً ما يكون بالغ الأهمية لأي غرض رئيسي من هذه الطريقة. بالتأكيد ، من الضروري بالتأكيد التواجد هناك ، لكنني لا أعتقد أنه من المجدي إضاعة ثلاثة أسطر على حراس بسيطين مثل هذا.

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

• بالنسبة للحراس متعددي العبارات ، أفضل هذا:

guard let name = json["name"] as? String,
  let coordinatesJSON = json["coordinates"] as? [String: Double],
  let latitude = coordinatesJSON["lat"],
  let longitude = coordinatesJSON["lng"],
  let mealsJSON = json["meals"] as? [String] else { return nil }

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

لقد اقترضت التنسيق الأولي من Apple ولكن بعد ذلك قمت بتغيير نمط الكود الخاص بي أيضًا. من المعقول استخدام خط واحد إذا كنت ستعود على الفور.

ها هو الإصدار الجديد:

أعزب:

guard let name = json["name"] as? String else { return nil }

متعددة:

guard let name = json["name"] as? String,
    let coordinatesJSON = json["coordinates"] as? [String: Double],
    let latitude = coordinatesJSON["lat"],
    let longitude = coordinatesJSON["lng"],
    let mealsJSON = json["meals"] as? [String]
else { return nil }

أعتقد أن else يستحق السطر الخاص به عندما يكون هناك العديد من let s.

وجوده في سطر واحد يمنعك من وضع نقطة توقف على حالة الفشل لا؟

rayfix yeap ، لا يمكنك فعل ذلك ... ¯_ (ツ) _ / ¯

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

أستطيع أن أرى من أين يأتي الأشخاص الذين يختلفون. بخلاف مشكلة rayfix المذكورة ، أرى سلبيين آخرين.

في بعض الأحيان ينتهي بهم الأمر إلى أن تكون طويلة نسبيًا ، مما يجعلها أقل قابلية للقراءة. (أنا متأكد من أنه يمكنني العثور على أمثلة أكثر تطرفًا):

خطوط متعددة:

guard let meal = Meal(rawValue: string) else {
    throw SerializationError.invalid("meals", string)
}

خط واحد:

guard let meal = Meal(rawValue: string) else { throw SerializationError.invalid("meals", string) }

المشكلة الأخرى هي مجرد الاتساق. لن أفعل أبدًا حالة سطر واحد if على سبيل المثال.

لكن مرة أخرى ، ما زلت أفضل استخدام سطر واحد. فقط أحاول قلب القليل من الصخور.

أملي هو أنه لا توجد قاعدة صارمة وسريعة في هذا الشأن. ربما يجب أن نكون صريحين بشأن ذلك بالطريقة التي كنا بها مع سلسلة الإغلاق.

تُترك قرارات التباعد وفواصل الأسطر ووقت استخدام الوسائط المسماة مقابل الحجج المجهولة لتقدير المؤلف.

لقد أجريت مسحًا غير رسمي لبعض مكتبات Swift ذات النجوم العالية بما في ذلك Swift Standard Library و Almofire و Unbox و SwiftyJSON و Spring. لا يوجد إجماع حقيقي يمكنني أن أجده. كلهم يبدون جيدًا بالنسبة لي في سياقهم الخاص.

حتى في مثال Apple JSON من https://developer.apple.com/swift/blog/؟id=37 وضعوا else في أماكن مختلفة في نفس الوظيفة! هذا لا يعني أنها تبدو سيئة. في الواقع تبدو جيدة لعيني.

لذلك أعتقد أنني أقع في معسكر الرغبة في تبني المرونة التي تسمح بها اللغة. أعتقد أن هذا يفضل قابلية القراءة (الوضوح) على حساب بعض الاتساق.

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

بغض النظر ، أود أن أشكرك على طرح هذه المسألة لأنها أعطتني وضوحًا أفضل وأثارت بعض المناقشات والأفكار المفيدة.