Swift-style-guide: استخدام الذات

أوافق ، وأوافق أيضًا على أنه سيكون صعبًا بعض الشيء في البداية :)

أنا أتفق مع هاتين الاتفاقيتين.

لذا ، تسقط النفس إلا إذا اشتكى المترجم من ذلك!

مرسل من الايفون الخاص بي

في 10 حزيران (يونيو) 2014 ، الساعة 5:48 صباحًا ، كتب Cesare [email protected] :

أوافق ، وأوافق أيضًا على أنه سيكون صعبًا بعض الشيء في البداية :)

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

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

لا تتفقون يا رفاق؟

في يوم الثلاثاء ، 10 يونيو 2014 ، كتب elephantronic [email protected] :

أنا أتفق مع كل من هاتين الاتفاقيتين.

لذا ، تسقط النفس إلا إذا اشتكى المترجم من ذلك!

مرسل من الايفون الخاص بي

في 10 حزيران (يونيو) 2014 ، الساعة 5:48 صباحًا ، سيزار < [email protected]
<_e i = "16">

أوافق ، وأوافق أيضًا على أنه سيكون صعبًا بعض الشيء في البداية :)

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/raywenderlich/swift-style-guide/issues/7#issuecomment -45607945
.

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

العديد من المحررين الذين استخدمتهم يسلطون الضوء على الاثنين بشكل مختلف. نأمل أن يتبع Xcode هذه الميزة.

سأستخدم فقط self لإزالة الغموض.

ألا يستهدف الدليل كتبنا ودروسنا؟ ما زلت أفكر في استخدام الذات
أكثر قابلية للقراءة (لكنني أعلم أن Apple لا تستخدمه ، لذا سنقوم بذلك في النهاية
لا تستخدمه سواء) ...

في يوم الثلاثاء ، 10 يونيو 2014 ، كتب ColinEberhardt [email protected] :

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

العديد من المحررين الذين استخدمتهم يسلطون الضوء على الاثنين بشكل مختلف. أملا
سيتبع Xcode مع هذه الميزة.

سأستخدم نفسي فقط لتوضيح الغموض.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/raywenderlich/swift-style-guide/issues/7#issuecomment -45625271
.

متفق عليه أنه يجب علينا التخلي self

Apple لا تستخدمها ، لذلك لا أعتقد أنه ينبغي لنا ذلك أيضًا. لست سعيدًا حقًا بهذا القرار من جانب Apple ، لكنني أعتقد أننا يجب أن نتبع اتفاقياتهم.

أعلم أنني قلت ذلك بنفسي ، وأعتقد أنني ما زلت أعتقد ذلك ، لكنني نظرت للتو إلى الكود في قالب لعبة Swift Sprite Kit. إنه GameViewController يستخدم self.view و self.classForKeyedUnarchiver. هذا مثال على خاصية وطريقة قياسية ، كلاهما يستخدم self.

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

لن أؤمن كثيرًا بقوالب Apple أو نموذج التعليمات البرمجية. عادة لا يكون هذا هو أفضل مثال على كيفية القيام بالأشياء ... هذا القالب نفسه ينتهي أيضًا بالسطور بفاصلة منقوطة ، على سبيل المثال. :-)

نقطة جيدة. ربما يجب أن نضيف فاصلة منقوطة في كل مكان أيضًا. ؛)

--------- الرسالة الأصلية --------- الموضوع: Re: [swift-style-guide] Using self (# 7)
من: "Matthijs Hollemans" [email protected]
التاريخ: 6/11/14 3:19 صباحًا
إلى: "raywenderlich / swift-style-guide" [email protected]
نسخة إلى: "elephantronic" [email protected]

لن أؤمن كثيرًا بقوالب Apple أو نموذج التعليمات البرمجية. عادة لا يكون هذا هو أفضل مثال على كيفية القيام بالأشياء ... هذا القالب نفسه ينتهي أيضًا بالسطور بفاصلة منقوطة ، على سبيل المثال. :-)
-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

أعتقد أن الذات تجعل الكود أكثر وضوحًا. إنه يجعل من السهل جدًا معرفة ما إذا كانت خاصية أو متغير حالة. نفس السبب الذي يجعلني أصوت دائمًا لاستخدام self في objc للخصائص بدلاً من استخدام متغير المثيل _propertyName.

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

إذا قمت بكتابة التعليمات البرمجية التي يتم تجميعها ، فسيتم تجميعها. لا يسمح لك Swift بتجميع التعليمات البرمجية التي تخفي ضمنيًا متغيرًا / func آخر من نطاق مختلف ، لذلك لا نحتاج إلى قول self لأنه إذا كانت الطريقة هي الوحيدة في النطاق ، فسيتم تجميعها. إذا كان على كائن آخر _and_ هذا الكائن ، فسوف يفشل في التحويل البرمجي حتى تحدد العنصر الذي تريده (باستخدام self ، إذا لزم الأمر)

Obj-C هي اللغة الوحيدة التي رأيتها على الإطلاق والتي تطلب من الناس تحديد أنهم يمتلكون ما يمتلكونه بوضوح ، لذلك من الجيد أن Swift قد تخلصت من ذلك.

إذا كنت تكتب عملية ، فلن يكون من الصعب معرفة المتغيرات المحلية لتلك الطريقة. خارج هذه الطريقة ، النطاق مهم فقط للمترجم.

--------- الرسالة الأصلية --------- الموضوع: Re: [swift-style-guide] Using self (# 7)
من: "ecerney" [email protected]
التاريخ: 6/12/14 1:17 مساءً
إلى: "raywenderlich / swift-style-guide" [email protected]
نسخة إلى: "elephantronic" [email protected]

أعتقد أن النفس تجعل الكود أكثر وضوحًا. إنه يجعل من السهل جدًا معرفة ما إذا كانت خاصية أو متغير حالة. نفس السبب الذي يجعلني أصوت دائمًا لاستخدام self في objc للخصائص بدلاً من استخدام متغير المثيل _propertyName.
-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

ما زلت لا أتفق مع هذا الموضوع.

من المفترض أن يكون هذا النمط مخصصًا للدرس التعليمي وليس لمؤلفي الكتب
دليل النمط العام حول Swift.

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

في يوم الخميس ، 12 يونيو 2014 ، كتب elephantronic [email protected] :

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

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

Obj-C هي اللغة الوحيدة التي رأيتها والتي تطلب من الناس تحديد ذلك
إنهم يمتلكون ما يمتلكونه بوضوح ، لذلك من الجيد أن Swift قد تخلصت منه
هو - هي.

إذا كنت تكتب طريقة ، فلن يكون من الصعب معرفة المتغيرات
محلية لتلك الطريقة. خارج هذه الطريقة ، النطاق يهم فقط
مترجم.

--------- الرسالة الأصلية --------- الموضوع: Re: [swift-style-guide]
باستخدام الذات (# 7)
من: "ecerney" < [email protected]
<_e i = "31" /> التاريخ: 6/12/14 1:17 مساءً
إلى: "raywenderlich / swift-style-guide" <
[email protected]
<_e i = "36" /> نسخة إلى: "elephantronic" < [email protected]
<_e i = "39">

أعتقد أن الذات تجعل الكود أكثر وضوحًا. يجعل من السهل جدا معرفة
سواء كانت خاصية أو متغير حالة. نفس سبب تصويتي دائما
استخدم self في objc للخصائص بدلاً من استخدام متغير المثيل الخاص بهم

_اسم الخاصية.

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/raywenderlich/swift-style-guide/issues/7#issuecomment -45927747
.

لقد كتبت تعليميًا شائعًا جدًا للوحدة. يستخدم C # ولا نفساني. لم أسمع شكاوى من أن الناس لم يفهموا من أين أتت المتغيرات.

--------- الرسالة الأصلية --------- الموضوع: Re: [swift-style-guide] Using self (# 7)
من: "مارين تودوروف" [email protected]
التاريخ: 6/12/14 2:16 مساءً
إلى: "raywenderlich / swift-style-guide" [email protected]
نسخة إلى: "elephantronic" [email protected]

ما زلت لا أتفق مع هذا الموضوع.

من المفترض أن يكون هذا النمط مخصصًا للدرس التعليمي وليس لمؤلفي الكتب
دليل النمط العام حول Swift.

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

في يوم الخميس ، 12 يونيو 2014 ، كتب elephantronic [email protected] :

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

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

Obj-C هي اللغة الوحيدة التي رأيتها والتي تطلب من الناس تحديد ذلك
إنهم يمتلكون ما يمتلكونه بوضوح ، لذلك من الجيد أن Swift قد تخلصت منه
هو - هي.

إذا كنت تكتب طريقة ، فلن يكون من الصعب معرفة المتغيرات
محلية لتلك الطريقة. خارج هذه الطريقة ، النطاق يهم فقط
مترجم.

--------- الرسالة الأصلية --------- الموضوع: Re: [swift-style-guide]
باستخدام الذات (# 7)
من: "ecerney" < [email protected]
<_e i = "40" /> التاريخ: 6/12/14 1:17 مساءً
إلى: "raywenderlich / swift-style-guide" <
[email protected]
<_e i = "45" /> نسخة إلى: "elephantronic" < [email protected]
<_e i = "48">

أعتقد أن الذات تجعل الكود أكثر وضوحًا. يجعل من السهل جدا معرفة
سواء كانت خاصية أو متغير حالة. نفس سبب تصويتي دائما
استخدم self في objc للخصائص بدلاً من استخدام متغير المثيل الخاص بهم

_اسم الخاصية.

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

• 
  قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
  https://github.com/raywenderlich/swift-style-guide/issues/7#issuecomment -45927747
  .
  -
  قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

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

نعم !!! سيزار على جانب القراءة! نحن نستطيع فعلها!

4 سنوات أخرى! 4 سنوات أخرى!

أعني - استخدام الذات لمتغيرات الطبقة!

في يوم الخميس ، 12 يونيو 2014 ، كتب Cesare [email protected] :

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

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/raywenderlich/swift-style-guide/issues/7#issuecomment -45931720
.

طيب ماذا عن هذه الحجة؟

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

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

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

تخلص من أغلال الماضي واحتضن المستقبل. سوف تشعر بتحسن.

--------- الرسالة الأصلية --------- الموضوع: Re: [swift-style-guide] Using self (# 7)
من: "Cesare" [email protected]
التاريخ: 6/12/14 2:44 مساءً
إلى: "raywenderlich / swift-style-guide" [email protected]
نسخة إلى: "elephantronic" [email protected]

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

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

أصوت لعدم استخدام self . أتفق مع funkyboy أنه صعب في البداية. لكنني أفكر أيضًا في سبب استخدام نفس الاسم لكل من المثال var و var المحلي ، ثم محاولة حل الغموض؟ إن فهمي لما ذكرتهhollance ( self.propertyName ) لا يتعلق بحل الغموض أو قابلية القراءة ؛ يتعلق الأمر بالعادة التي لدينا من ObjC ويبدو أنها لم تعد ضرورية بعد الآن في Swift. أرى self في Swift كحل أخير: أي يشتكي المترجم.

هل يعقل أن يطرح هذا للتصويت؟ أعتقد أنه كانت هناك بعض الحجج المدروسة جيدًا من كل جانب.

أنا أقوم بإجراء +1 لعدم استخدام self حيث لا يكون ذلك مطلوبًا.

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

رأيت Go عندما نظرت إلى Swift لأول مرة ، ولكن كلما نظرت لفترة أطول وأصعب ، كلما رأيت Java أكثر.

+1 نكران الذات

عادل بما يكفي أنا أقبل الحكم الديمقراطي :)
اسمحوا لي أن أشير إلى عدم الاتساق. من خلال عدم استخدام الذات قد أستنتج أن أحد المبادئ التي يستند إليها الدليل الإرشادي هو "لا تكتبها إذا لم تكن هناك حاجة". قد لا يعجبني ذلك ولكن طالما أنه متسق في جميع أنحاء المبدأ التوجيهي ، فأنا أقبله. ما زلت أعتقد أنه يؤثر سلبًا على قابلية القراءة.
يتماشى المبدأ نفسه مع قرارنا بشأن الاستدلال بالنوع ، فلا تكتب النوع "لأنه غير مطلوب".
إذا طبقنا نفس المبدأ على المُبدِعين ، فعلينا منع الأسماء الخارجية للمُبدِعين. احزر لما؟ لأن "ليست هناك حاجة إليها". إذا "ذهبنا إلى الحد الأدنى" ، فلنقم بذلك ، ولكن تمامًا.

اتفقنا على عدم كتابة النوع لأنه لا داعي له.

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

--------- الرسالة الأصلية --------- الموضوع: Re: [swift-style-guide] Using self (# 7)
من: "Cesare" [email protected]
التاريخ: 6/12/14 6:30 مساءً
إلى: "raywenderlich / swift-style-guide" [email protected]
نسخة إلى: "elephantronic" [email protected]

عادل بما يكفي أنا أقبل الحكم الديمقراطي :)
اسمحوا لي أن أشير إلى عدم الاتساق. من خلال عدم استخدام الذات قد أستنتج أن أحد المبادئ التي يستند إليها الدليل الإرشادي هو "لا تكتبها إذا لم تكن هناك حاجة". قد لا يعجبني ذلك ولكن طالما أنه متسق في جميع أنحاء المبدأ التوجيهي ، فأنا أقبله. ما زلت أعتقد أنه يؤثر سلبًا على قابلية القراءة.
يتماشى المبدأ نفسه مع قرارنا بشأن الاستدلال بالنوع ، فلا تكتب النوع "لأنه غير مطلوب".
إذا طبقنا نفس المبدأ على المُبدِعين ، فعلينا منع الأسماء الخارجية للمُبدِعين. احزر لما؟ لأن "ليست هناك حاجة إليها". إذا "ذهبنا إلى الحد الأدنى" ، فلنقم بذلك ، ولكن تمامًا.
-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

self هو مجرد ضوضاء في Swift ، اقتله. سوف نتكيف.

مرحبًا ، آسف لإعادة إحياء الخيط الميت.

أود أن أعرف كيف تشعرون الآن يا رفاق بعد التخلي self ؟ هل انت بخير الان؟ هل كانت هناك أي مشاكل خاصة في القراءة؟

لقد تخلت عنه ولم أنظر إلى الوراء أبدًا. :)

كانت الكتب والبرامج التعليمية الخاصة بموقع raywenderlich.com نكران الذات لمدة 4 سنوات حتى الآن ولم يكن لدى أي شخص أي شكاوى محددة.