ما هي اتفاقية التسمية المناسبة لعقار "معرف": معرف أو معرف؟

Question

سؤال بسيط جدًا: عندما يكون لدي كائن مستمر ، فإنه عادة ما يكون له خاصية تسمى المعرف (للفصول التجريدية).

إذن .. هل معرف اتفاقية التسمية أم معرف؟

على سبيل المثال.

public int ID { get; set; }

أو

public int Id { get; set; }

في صحتك :)

ملاحظة. هذا هو .NET راجع للشغل. سيكون FXCOP المطابق مكافأة.

Answer 1

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

ال .NET Framework Thailing Guidelines قل هذا:

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

الاختصاران اللذان يمكن استخدامهما في المعرفات هوية وموافق. في معرفات Pascal التي يجب أن تظهر كمعرف ، وموافق. إذا تم استخدامها ككلمة أولى في معرف جمل ، فيجب أن تظهر كمعرف وموافق ، على التوالي.

Answer 2

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

getResourceURL

أو

getResourceUrl

في الواقع يمكن العثور على كلاهما في استخدام أطر مختلفة. آخر شعبية ABBR. مع مشكلة مماثلة هو UTF8.

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

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

getResourceURL
urlOfResource
compareUrlToString

لماذا ا؟ أنا أحب ABBR. أن تكون ذات رسمية. معظم الناس يتوقعون أن يتم رسملة URL أو UTF. ومع ذلك ، إذا كان في منتصف الاسم ، فإنه يدمر ميزة تدوين الجمل. ميزة تدوين الجمل هي أنك ترى أين تبدأ كلمة جديدة بالرحمة. لذلك قارن:

compareURLToString
compareUrlToString

في الحالة الأولى ، لا أرى على الفور أن عنوان URL هو كلمة واحدة وأنه هو الكلمة التالية. قد يكون T جزءًا من URL (urlt) ويكون ABBR مختلفًا ، وبالتالي سأستخدم النموذج الثاني. ومع ذلك ، إذا كان الأمر في النهاية ، فلن يلعب دورًا ، فلا توجد كلمة أخرى تتبعها ، وبالتالي فأنا أفضل النموذج الراقعي. أنا متمسك بهذه الاتفاقية في جميع الكود الخاص بي.

Answer 3

الإرشادات تقول "معرف".

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

في متجري ، نستخدم "ID" حتى لو كانت الإرشادات تقول "ID" ، لكن لا أحد ، يشعر حقًا بالذنب حيال ذلك.

Answer 4

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

لا أعرف ما هو محتوى مجالك (الأرقام ، الأرقام ، GUIDS) ، ولكن إذا كنت ترغب في تخطي المشكلة ، فيمكنك ببساطة استخدام اتفاقية .NET أخرى لمعرفات الكائنات: اسم

Answer 5

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

نضع سمة مثبتة على خاصية ID ، والجميع سعداء.

Answer 6

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

<Dictionary>
<Acronyms>
   <CasingExceptions>
        <Acronym>ID</Acronym>
  </CasingExceptions>
</Acronyms>
</Dictionary>

عملت مع FXCOP 1.36. PS بشكل عام ، أعتقد أن "ID" هو بديل أفضل ، لكن في بعض الأحيان يكون من المستحيل تغيير الاسم إذا تم إنشاؤه على أساس ملفات XML (أو خدمات الويب) التي لا نتحكم فيها

Answer 7

أفضل المعرف ، أيضًا بالاقتران مع كلمات أخرى (على سبيل المثال CustomerId) ، ولكن بالمعنى الدقيق للكلمة ، فإن ذلك يعارض اتفاقيات التسمية العادية.

Answer 8

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

لكن خلاصة القول هي: اختر ما هو الاتفاقية أكثر راحة لفريق المطورين والأشخاص الآخرين الذين ينظرون إلى الكود المصدري والتمسك به.

Answer 9

http://en.wiktionary.org/wiki/id#abbreviation

لماذا محاربه؟