سؤال

هل هناك اتفاقية رسمية لتسمية الحقول الخاصة في VB.NET؟على سبيل المثال، إذا كانت لدي خاصية تسمى "Foo"، فعادةً ما أسمي الحقل الخاص "_Foo".ويبدو أن هذا أمر مستهجن في المبادئ التوجيهية الرسمية:

"لا تستخدم بادئة لأسماء الحقول.على سبيل المثال، لا تستخدم g_ أو s_ للتمييز بين الحقول الثابتة وغير الثابتة."

في C#، يمكنك استدعاء الحقل الخاص "foo"، الخاصية "Foo"، والإشارة إلى الحقل الخاص باسم "this.foo" في المُنشئ.نظرًا لأن VB.NET غير حساس لحالة الأحرف، فلا يمكنك القيام بذلك - أي اقتراحات؟

هل كانت مفيدة؟

المحلول

ما زلت أستخدم البادئة _ في VB للحقول الخاصة، لذا سيكون لدي _foo كحقل خاص وFoo كخاصية.أفعل هذا من أجل C# أيضًا وأي كود أكتبه تقريبًا.بشكل عام، لن أنشغل كثيرًا بـ "ما هي الطريقة الصحيحة للقيام بذلك" لأنه لا توجد طريقة "صحيحة" حقًا (على الرغم من وجود بعض الطرق السيئة للغاية) ولكن بدلاً من ذلك سأهتم بالقيام بذلك باستمرار.

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

نصائح أخرى

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

جيف بروسيس يقول

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

من .إرشادات تصميم NET Framework الطبعة الثانية صفحة 73.

جيفري ريختر يقول

أجعل جميع حقولي خاصة وأبدأ حقول المثيلات الخاصة بي بـ "m_" وحقولي الثابتة بـ "s_" [في C#]

من .إرشادات تصميم NET Framework الطبعة الثانية صفحة 47.أنتوني مور (فريق بي سي ال) يعتقد أيضًا أن استخدام "m_" و"s_" يستحق الاهتمام، الصفحة 48.

المبادئ التوجيهية الرسمية هي مجرد مبادئ توجيهية.يمكنك دائما الالتفاف حولهم.ومع ذلك، فإننا عادةً ما نسبق الحقول بشرطة سفلية كلاهما لغة البرمجة C# و VB.NET.هذه الاتفاقية شائعة جدًا (ومن الواضح أنه تم تجاهل المبادئ التوجيهية الرسمية).

يمكن بعد ذلك الرجوع إلى الحقول الخاصة بدون الكلمة الأساسية "me" (الكلمة الأساسية "this" مخصصة لـ C# :)

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

ومع ذلك، سأضيف إلى غرفة الصدى وأشير إلى أنه مهما كان ما تفعله، فمن المهم أن تكون متسقًا.يفرض صاحب العمل أن تكون الحقول الخاصة في كل من C# وVB مسبوقة بـ _، ولأننا جميعًا نتبع هذا العرف، فمن السهل استخدام التعليمات البرمجية المكتوبة بواسطة شخص آخر.

في VB.NET 4.0، ربما يعرف معظمكم أنك لا تحتاج إلى كتابة حروف الحروف والمحددات بشكل صريح لإعلانات الخاصية الخاصة بك على النحو التالي:

Public Property Foo As String
Public Property Foo2 As String

يقوم VB تلقائيًا بإنشاء متغيرات أعضاء خاصة تسمى _Foo و _Foo2.يبدو كما لو أن Microsoft وفريق VS قد اعتمدوا الاتفاقية _، لذلك لا أرى مشكلة فيها.

لا أعتقد أن هناك اصطلاح تسمية رسميًا، لكنني رأيت أن Microsoft تستخدم m_ في ملف Microsoft.VisualBasic dll (عبر العاكس).

ما زلت أستخدم البادئة _ في VB للحقول الخاصة ، لذلك سيكون لدي _foo كحقل خاص و foo كممتلكات.أفعل هذا لـ C# أيضًا وأي رمز أكتب.عمومًا ، لن أتعامل مع "ما هي الطريقة الصحيحة للقيام بذلك" لأنه لا يوجد حقًا طريقة "صحيحة" (على الرغم من أن هناك بعض الطرق السيئة للغاية) ولكن بدلاً من ذلك مهتم بالقيام بذلك باستمرار.

لم أجد أي شيء أفضل من "_" للتوضيح والاتساق.تشمل السلبيات ما يلي:

أتجاوز السطور عن طريق إيقاف تشغيلها في المحرر، وأحاول ألا أفكر كثيرًا في الامتثال لـ CLS.

أنا أتفق مع @lomaxx، من المهم أن تكون متسقًا في جميع أنحاء الفريق بدلاً من أن يكون لديك يمين مؤتمر.

ومع ذلك، إليك العديد من الأماكن الجيدة للحصول على أفكار وإرشادات حول اتفاقيات البرمجة:

  1. إرشادات عملية وأفضل الممارسات لـ Microsoft Visual Basic وVisual C# يعد كتاب "المطورون" من تأليف Francesco Balena كتابًا رائعًا يتناول العديد من هذه المشكلات.
  2. معايير ترميز آي ديزاين (لـ C# وWCF)
  3. إطار عمل .NET مصدر الرمز (في VS2008)

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

Public Class Class1

    Private _foo As String
    Public Property Foo() As String
        Get
            Return _foo
        End Get
        Set(ByVal value As String)
            _foo = value
        End Set
    End Property

    Public Sub New(ByVal foo As String)
        _foo = foo
    End Sub

End Class

باستخدام هذا النمط، لن يكون لديك أي تعارض في التسمية مع الحقل الخاص ومعلمة المنشئ الخاصة بك في C# أو VB.NET.

أوافق على أن الأهم ليس الأسلوب الذي يستخدمه المرء، بل أن يكون متسقًا.

مع ذلك، فإن تصميم MS/.NET الجديد للحقول الخاصة يميل إلى أن يكون _fooVar (شرطة سفلية متبوعة باسم CamelCased)

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top