Swift-style-guide: اصطلاح التسمية للاختصارات

تم إنشاؤها على ٢٢ يونيو ٢٠١٥  ·  15تعليقات  ·  مصدر: raywenderlich/swift-style-guide

ربما يجب عليك إضافة قسم للاختصارات؟

التعليق الأكثر فائدة

أعتقد أنه قد يكون من الجدير ذكر اصطلاح الحالة للمختصرات ، خاصة وأن هذا يبدو أنه تم إضفاء الطابع الرسمي عليه في Swift 3. يجب ألا تكون الاختصارات مثل URL أو ID مختلطة ، ويعتمد ما إذا كانت الأحرف الكبيرة أو الصغيرة على الموضع في المعرف:

خاطئ - ظلم - يظلم:

var ID: String
var imageUrl: URL
typealias Id = String
typealias UniqueId = String

حق:

var id: String
var imageURL: URL
typealias ID = String
typealias UniqueID = String

ال 15 كومينتر

أي نوع من الاختصارات؟ (ضع في اعتبارك أن هذا هو في الأساس رمز وليس دليل كتابة.)

WingYn ،

سأغلق هذه المشكلة بناءً على ما يلي:

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

استخدم الأسماء الوصفية مع حالة الجمل للفئات والطرق والمتغيرات وما إلى ذلك.

TL ؛ DR : لا ننصح باستخدام الاختصارات لتسمية أي شيء في الكود.

اسمحوا لي أن أعرف إذا كنت تشير إلى نوع آخر من الاختصار.

أعتقد أنه قد يكون من الجدير ذكر اصطلاح الحالة للمختصرات ، خاصة وأن هذا يبدو أنه تم إضفاء الطابع الرسمي عليه في Swift 3. يجب ألا تكون الاختصارات مثل URL أو ID مختلطة ، ويعتمد ما إذا كانت الأحرف الكبيرة أو الصغيرة على الموضع في المعرف:

خاطئ - ظلم - يظلم:

var ID: String
var imageUrl: URL
typealias Id = String
typealias UniqueId = String

حق:

var id: String
var imageURL: URL
typealias ID = String
typealias UniqueID = String

اتفق مع nicklockwood هنا. هناك العديد من تفسيرات الاختصارات مقابل الاختصارات وما إلى ذلك معرف العميل أو معرف العميل؟ rawHTML أو rawHtml؟ fileIO أو fileIo؟

"المعرف" ليس اختصارًا. إنها اختصار لـ "المعرف" ويجب كتابتها فقط id (أو Id ككلمة ثانية في معرّف حالة الجمل).

أوافق ، لكنني رأيت Apple يستخدم ID على NSManagedObjectID ...

ID ليس اختصارًا ، ولكنه إما شكل نادر أو فريد من أشكال البداية. تمثل الأحرف الأولى المقطعين الأولين من "التعريف" أو "المعرف". إنها من قبيل المصادفة أن النتيجة تبدو تمامًا مثل أبوكوبيشن . إذا كان ID مثالًا على apocope ، فسيكون متماثلًا لـ "eyed" ؛ في الواقع يتم نطقها "عين دي".

تستخدم جميع الأحرف في اختصار أو بداية ، لكل اصطلاح Swift القياسي ، نفس الحالة. لذلك ، النموذجان الوحيدان اللذان يجب استخدامهما هما id و ID .

Id عبارة عن مقطع لفظي يحتوي على حرف i قصير: كلمة مختلفة عن المعرف المكون من مقطعين. لكن شكل الجمل السفلي هو تجانس مع المعرف: id لكليهما.

هناك العديد من المستودعات التي تحتوي على مساهمات من Java أو DotNet devs (في العمل على مر السنين) التي تستخدم المعرف كما هو الحال في CustomerId والأسوأ من ذلك في واجهة برمجة التطبيقات. لا أعرف القواعد النحوية الموضحة جيدًا مثل JessyCatterwaul لكنني أوافق على أنه يجب أن يكون معرف العميل ، فهو يجعل القراءة أوضح ومحددة.

لن أعيد فتح المشكلة لأنني أعتقد أن Mic كان محقًا في إغلاقها وأعتقد أن المناقشة اللاحقة تم تناولها بالفعل في الدليل الحالي:

غلاف المختصرات والاحرف الاولية بشكل موحد لأعلى أو لأسفل

في قسم التسمية . قد أسرق ~ استخدم أمثلة Nicklockwood عندما أقوم بتحديث الدليل التالي في وقت لاحق من هذا الصيف.

يبدو هذا الاصطلاح غريبًا نوعًا ما بالنسبة لي عندما يكون الاختصار في المنتصف. على سبيل المثال ، هل وظيفة تسمى parseURLScheme أو testHTTPConnection ستكون على ما يرام؟ أو حتى parseHTTPURLDomain ؟ يبدو أنه أقل قابلية للقراءة من parseUrlScheme أو testHttpConnection أو parseHttpUrlDomain . أم أن هناك أيضًا قاعدة تمنع وجود اختصارات في المنتصف أثناء التسمية؟ أم أن هذا لا يؤخذ بعين الاعتبار؟

أنا لا أختلف حول المقروئية ،dkk. في الواقع لا أعتقد أن أيًا من الخيارات جيدة. ☹️ أعتقد أن اتفاقية سويفت جاءت على الأقل إلى حد ما من سابقة تاريخية . على الأقل اختاروا واحدة !

أنا في الواقع لا أوافق على القراءة. أعتقد أنه بالإضافة إلى كوننا أقرب إلى تسمية Apple ، فإن حقيقة أنها تتطابق مع الطريقة التي يكتب بها المرء باللغة الإنجليزية - وكيف نطلب من مؤلفينا الكتابة - أمر مفيد.

rcritz لا أعتقد أنه يمكنك مقارنتها بالكتابة العادية ، لأننا لا نستخدم مسافات بيضاء. لكني أتفق مع JessyCatterwaul حول القيمة التاريخية. تكمن المشكلة في أنه من الناحية العملية ، لا تمتلك عادةً تقنيات مثل BLE و URL و HTTP مثل واجهات برمجة تطبيقات Apple. على الأقل في المشاريع التي شاركت فيها ، في كثير من الأحيان ، لديك اختصارات لخدمات الخلفية ، وقواعد بيانات محددة ، وفروع الشركة ، والبلدان ، ومناطق العالم ، وما إلى ذلك ، مما يؤدي دائمًا تقريبًا إلى متغيرات ووظائف تبدو غريبة جدًا إذا اتبعت هذه الاتفاقية. وفي تجربتي ، فإن العديد من المشاريع تجعل استثناء من هذه القاعدة. ولكن قد تكون مصادفة ، ربما يمكننا عمل إحصائية من المشاريع السريعة في جيثب لمحاولة معرفة ما إذا كان معظم الناس يعتقدون أن ذلك منطقي أم أنهم يتجاهلون ذلك. سأحاول أن أكتب محللًا وأجمع بعض البيانات عنه إذا كان لدي الوقت.

dkk تذكر أن دليل الأسلوب هذا مخصص لنا على وجه التحديد كفريق تعليمي / كتاب ، لذا لا يمكنك مقارنته بالكتابة باللغة الإنجليزية فحسب ، بل يجب عليك القيام بذلك.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات

القضايا ذات الصلة

samkim102 picture samkim102  ·  4تعليقات

Lweek picture Lweek  ·  5تعليقات

rwenderlich picture rwenderlich  ·  29تعليقات

ghost picture ghost  ·  26تعليقات

grosch picture grosch  ·  6تعليقات