Swift-style-guide: يمكن أن يؤدي التظليل المتغير إلى صعوبة قراءة التعليمات البرمجية.

بالنسبة لي ، فإن رؤية ! أثناء مراجعة الكود هو العلم الأحمر. هذا عندما بدأت أسأل "لماذا لم نربط هذا الشيء اختياريًا؟"

أنا قلق من أن تكون "غير مغلفة" طويلة جدًا لبادئة الكتب ، فمن الصعب جدًا الحفاظ على التفاف السطر إلى الحد الأدنى ، وهذا هو الكثير من المساحة الأفقية المستخدمة. يمكن القول إن التفاف الأسطر في الكود في الكتب أسوأ فيما يتعلق بالقراءة من IMO. بالطبع لن يعاني هذا المثال من التفاف السطر ، ولكنه سيتسبب في استدعاء Cocoa API وستكون قصة مختلفة.

من المحتمل أن يختلف موقفي من التظليل من حالة إلى أخرى ويومًا بعد يوم على الرغم من:]

بدون تجميع هذا الرمز ، كيف أعرف أن متغير الاسم الذي يتم تعيينه هو المتغير غير المغلف بدلاً من المتغير الاختياري الذي تم تمريره؟

لأن هذه هي الطريقة التي يعمل بها Swift. إذا كنت داخل نطاق if let ، فإنه يستخدم الإصدار غير المغلف. لا يوجد غموض هنا.

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

cwagdev ربما بادئة بـ u فقط بدلاً من غير مغلفة؟ في العمل ، تتطلب معايير كود Android الخاصة بنا تمرير أي متغير كوسيطة ليكون البادئة a ، وقد كان هذا بمثابة حل وسط قوي بين الوضوح والطول المتغير.

أعتقد أن هذا هو المكان الذي يكون فيه إبراز الشفرة الدلالية مفيدًا. ؛-)

بالمناسبة ، هل تعلم أن if var يعمل أيضًا في فك التغليف؟

  if var name = name {
    name += ", Esq."
    person.name = name
  }

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

بالنسبة إلى if var : https://www.youtube.com/watch؟v=Cd7tEsAuspA - شكرًا!

إن الشيء الذي يميز التمييز الدلالي مقابل إبراز البنية العادية هو أنه يعطي كل متغير لونه الخاص. لذلك يمكنك أن ترى في لمحة أن name غير المغلف يختلف عن المعلمة name .

هناك مكون إضافي لـ Xcode لهذا ، لكنني لا أعرف ما إذا كان يعمل مع Swift. https://github.com/kolinkrewinkel/Polychromatic

أنا أعارض بشدة إدخال أي متغير جديد أو بادئات ثابتة. أوشك التدوين الهنغاري على الانقراض ، ولا يوجد سبب وجيه لإحيائه!

أوافق على أننا يجب أن نعتمد على أدوات التطوير لإعطاء تلميحات بشأن النطاق والسياق.

لدي بالتأكيد الحجة القائلة بأن هذا ليس ضروريًا في بيئة مترجمة - ولهذا السبب تم اعتماد هذه القاعدة في المقام الأول.

تكمن المشكلة في أن الكود الخاص بنا غالبًا ما يُقرأ خارج بيئة مُجمَّعة ، سواء على الموقع الإلكتروني أو في الكتب. تصبح هذه العملية أقل وضوحًا بدون مساعدة المحول البرمجي إذا حاولت استخدام الخطأ غير الاختياري مقابل اختياري var أو let .

ColinEberhardt و hollance : هل لديك أي اقتراحات أخرى حول كيفية تقديم سياق أفضل لهذه الأشياء في بيئة للقراءة فقط دون اللجوء إلى بادئة متغيرة؟ أم يجب أن نقول فقط ، "تبا له ، اكتبه في ساحة اللعب إذا لم تحصل عليه"؟

+1 لاستخدام نفس الاسم. بشكل عام ، سأعارض التظليل المتغير ولكن في هذه الحالة أعتقد أنه منطقي. إنه يجعل الأمور أبسط لأنه لا يلزم استخدام الأسماء الإبداعية أو البادئات. كما يشير المتغير المظلل حقًا إلى نفس المتغير ، فقط النسخة غير المغلفة منه ، أي أنه لا يقوم بالفعل بتظليل أي متغير آخر ، بل يقوم بتظليله بنفسه.

أحب تفسير jawwad بأن التظليل هو حقًا "تظليل نفسه" ، لذا فإن استخدام نفس الاسم أمر منطقي.

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

في كلتا الحالتين ، سنحتاج إلى الاعتماد على الأشخاص في "الحصول عليها" في النهاية ، وإذا كان الأمر كذلك - فأنا أفضل تحسين احتمالية فهم الأشخاص الاختيارية.

دعنا نواصل المناقشة رغم ذلك! ربما يمكننا التغلب على عدد المنشورات في مناقشة دليل أسلوب Objective-C حول ivars مقابل الخصائص!

عاصفة محتملة تختمر من الله نفسه https://devforums.apple.com/message/1127586#1127586

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

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

ما يعود لي هو هذا الكستناء القديم :

Programs must be written for people to read, 
and only incidentally for machines to execute.

نعم ، سيخبرك المترجم عندما تخطئ عندما تكتب الكود بالفعل. لكن قراءة الكود الخاص بالآخرين (أو حتى الشفرة الخاصة بي) يصبح أكثر صعوبة بالنسبة لي مع التظليل المتغير. أجد صعوبة أكبر في تحديد مكان وصول شخص ما إلى القيمة غير المغلفة مقابل القيمة المغلفة عندما أقرأ التعليمات البرمجية المظللة.

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

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

وأنا أعلم أنه سيجعل سماعColinEberhardt حزينًا للغاية ، لكنني اعتمدت البادئة u في الكود الشخصي الخاص بي ووجدت أنها تساعد بشكل كبير.

لا أعتقد أن لاتينر يقدم النصيحة بطريقة أو بأخرى هنا ... إنه يقول فقط لن يكون هناك تحذير.

يبدو أنه يقول لي "افعل ذلك إذا كنت تريد حقًا" ...:]

متفق عليه ، كنت ساخرًا في المقام الأول وذكّرني الخيط بهذا: ابتسم:

ما زلت في معسكر الظل ولكن يمكنني رؤية نقطة designatednerd .

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

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

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

تُستخدم هذه المجموعة من معايير الكود كمرجع للعديد من أماكن العمل التي لا تزال تطور معايير كود Swift الخاصة بها (بما في ذلك المعايير الخاصة بي) ، ولكن في النهاية ، هذه هي لموقعنا وكتبنا. وأعتقد أن الحصان قد غادر الحظيرة وركض عبر نصف البلاد في هذه المرحلة لتغيير الدروس والكتب. :سباق الخيل:

FWIW لقد كتبت قدرًا كبيرًا من Swift منذ ظهور ذلك وأود أن أقول إنني ظللت 90 ٪ من الوقت ، وأتخطى التظليل عندما يكون المتغير مطولًا للغاية.

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

func compute(a: Int?, b: Int?) -> {
   unwrap a, b else { return }
   // compute with a and b Ints
}

يعمل برنامج Unwrap أيضًا مع النوع الأسطوري Result .

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

guard let cache = config.persistentCache else { return }

في أحيان أخرى يكون مجرد ظلال.

أعتقد أن cwagdev يصل إلى. استخدمت بعض المشاريع الأخرى التي راجعتها مزيجًا من التظليل وعدم التظليل بما في ذلك Almofire ، وتنفيذ Apple مفتوح المصدر لـ Foundation. ومع ذلك ، لم يستخدم أي من هذه المشاريع الترميز الهنغاري.

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

rayfix 👍 أنا أيضًا لأغلق هذه المشكلة.

ومع ذلك ، بخصوص

سأحكم أنه في الوقت الحالي لا ينبغي وضع معيار حول الظل أو عدم التظليل.

في الواقع ، دليل الأسلوب له بالفعل حكم في هذا:

للربط الاختياري ، قم بوضع الظل على الاسم الأصلي عندما يكون ذلك مناسبًا بدلاً من استخدام أسماء مثل unsrappedView أو realLabel.

عندما تم فتح هذه المشكلة ، لم يكن هناك الكثير من التعليمات البرمجية أو البرامج التعليمية التي تستخدم "التظليل".

الآن ، مع ذلك ، قصة مختلفة:

• لقد استخدمناه في العديد من الدروس المكتوبة والفيديو.
• استخدمناها وشرحناها في RWDevCon 2015 و 2016.
• الكل في الكل ، لقد دعمنا بشكل أساسي فكرة "حجب" الاسم الأصلي.

في هذه المرحلة ، أعتقد أننا ملتزمون بذلك ... شخصيًا ، لقد نمت لأحبها أيضًا ...

مثل بخير 🍷 ، ينمو عليك؟ 😉

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

guard let json = content as? NSDictionary else { throw InvalidJSON }

FWIW ، توقفت عن استخدام u وانتهى بي الأمر باستخدام أسماء متغيرة مختلفة ، لكنني أدرك أنني خسرت هذه المعركة. :ابتسامة:

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