ما نوع البادئة التي تستخدمها لمتغيرات الأعضاء؟

https://stackoverflow.com/questions/111605

02-07-2019
|

سؤال

لا شك أنه من الضروري لفهم الكود إعطاء متغيرات الأعضاء بادئة بحيث يمكن تمييزها بسهولة عن المتغيرات "العادية".

ولكن ما نوع البادئة التي تستخدمها؟

لقد كنت أعمل في المشاريع التي استخدمناها م_ كبادئة، في مشاريع أخرى استخدمنا الشرطة السفلية فقط (وهو ما لا أحبه شخصيًا، لأن الشرطة السفلية فقط ليست توضيحية بدرجة كافية).

في مشروع آخر، استخدمنا نموذج بادئة طويل، يتضمن أيضًا نوع المتغير. مول_ على سبيل المثال هي البادئة ل ممتغير الجمرة من النوع شوقع لاونج.

الآن اسمحوا لي أن أعرف ما هو نوع البادئة التي تستخدمها (ويرجى تقديم سبب لذلك).

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

المحلول

لا شك أنه من الضروري لفهم الكود إعطاء متغيرات الأعضاء بادئة بحيث يمكن تمييزها بسهولة عن المتغيرات "العادية".

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

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

تعديل آخر:أعتقد أنه من هذا الطريق؛يعتبر نوع ونطاق المتغير معلومات ثانوية.ينبغي أن يكون متاحًا ويسهل اكتشافه، ولكن لا يصرخ في وجهك.إذا كنت تستخدم البادئات مثل m_ أو أنواع مثل LPCSTR, ، يصبح هذا ضجيجًا، عندما تريد فقط قراءة المعلومات الأساسية – الهدف من الكود.

التعديل الثالث:وهذا ينطبق بغض النظر عن اللغة.

نصائح أخرى

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

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

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

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

تسطير أسفله فقط.

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

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

بالنسبة لـ c++، هناك سبب آخر لتفضيل m_ على _ إلى جانب حقيقة أن _ أحيانًا تسبق الكلمات الرئيسية للمترجم.يشير m إلى متغير العضو.يمنحك هذا أيضًا القدرة على إزالة الغموض بين المتغيرات المحلية وفئات المتغيرات الأخرى، s_ للثابت وg_ للعموم (ولكن بالطبع لا تستخدم المتغيرات العالمية).

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

انا افضل استخدام this الكلمة الرئيسية.هذا يعني this.data أو this->data بدلاً من بعض الأسماء التي تعتمد على المجتمع.

لأن:

مع كتابة IDEs في الوقت الحاضر this. التحسس الذكي للنوافذ المنبثقة
من الواضح للجميع دون معرفة تسمية محددة

راجع للشغل أن بادئة المتغيرات بأحرف للإشارة إلى نوعها قد عفا عليها الزمن مع IDEs الجيدة ويذكرني بهذا مقال جويل

نستخدم m_ ثم تدوين Simonyi المعدل قليلاً، تمامًا كما قال Rob في الرد السابق.لذا، تبدو البادئة مفيدة وm_ ليست تطفلية للغاية ويمكن البحث عنها بسهولة.

لماذا التدوين على الإطلاق؟ولماذا لا نتبع فقط (بالنسبة لـ .NET) توصيات تدوين Microsoft التي تعتمد على حالة الأسماء؟

السؤال الأخير أولاً:كما تمت الإشارة إليه، فإن VB.NET لا يبالي بالغلاف.وكذلك قواعد البيانات و(خاصة) مسؤولي قواعد البيانات.عندما يتعين علي الاحتفاظ بمعرف العميل ومعرف العميل بشكل مستقيم (في لغة C# على سبيل المثال)، فإن ذلك يجعل ذهني يؤلمني.لذا فإن الغلاف هو شكل من أشكال التدوين، ولكنه ليس فعالاً للغاية.

تدوين البادئة له قيمة بعدة طرق:

يزيد من الفهم البشري للتعليمات البرمجية دون استخدام IDE.كما هو الحال في مراجعة التعليمات البرمجية - والتي ما زلت أجد أنه من الأسهل القيام بها على الورق في البداية.
هل سبق لك أن كتبت T-SQL أو غيرها من عمليات RDBMS المخزنة؟يعد استخدام تدوين البادئة في أسماء أعمدة قاعدة البيانات مفيدًا حقًا، خاصة بالنسبة لأولئك منا الذين يحبون استخدام برامج تحرير النصوص لهذا النوع من الأشياء.

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

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

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

باستخدام C#، انتقلت من البادئة 'm_' إلى مجرد الشرطة السفلية, ، بما أن "m_" هو تراث من C++.

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

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

تحديث:لا أعتقد أن C# "هذا."-البادئة يساعد "أنا". في VB ، والتي ستظل ترى "me.age" مثل "me.age".

يعتمد ذلك على الإطار الذي أستخدمه!إذا كنت أكتب رمز MFC فأنا أستخدمه م_ والتدوين المجري.بالنسبة للأشياء الأخرى (التي تميل إلى أن تكون STL/Boost) أقوم بإضافة لاحقة الشرطة السفلية إلى جميع متغيرات الأعضاء ولا أهتم بالتدوين المجري.

فئة MFC

class CFoo  
{  
private:  
    int m_nAge;  
    CString m_strAddress;  
public:  
    int GetAge() const { return m_nAge; }  
    void SetAge(int n) { m_nAge = n; }  
    CString GetAddress() const { return m_strAddress;  
    void SetAddress(LPCTSTR lpsz) { m_strAddress = lpsz; }  
};

فئة STL

class foo  
{  
private:  
    int age_;  
    std::string address_;  
public:  
    int age() const { return age_; }  
    void age(int a) { age_ = a; }  
    std::string address() const { return address_; }  
    void address(const std::string& str) { address_ = str; }  
};

الآن قد يبدو هذا غريبًا بعض الشيء - نمطان مختلفان - ولكنه يناسبني، وكتابة الكثير من أكواد MFC التي لا تستخدم نفس نمط MFC نفسه تبدو قبيحة.

أقوم ببادئة متغيرات الأعضاء بـ "m" والمعلمات (في الوظيفة) بـ "p".لذلك سيبدو الكود كالتالي:

class SomeClass {
    private int mCount;
    ...
    private void SomeFunction(string pVarName) {...}
}

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

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

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

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

إذا كانت اللغة تدعم هذا أو أنا الكلمة الرئيسية، ثم لا تستخدم أي بادئة، وبدلاً من ذلك استخدم الكلمة الرئيسية المذكورة.

خدعة أخرى هي اصطلاح التسمية:

تتم تسمية جميع متغيرات الأعضاء كالمعتاد، دون أي بادئة (أو "هذا". هو المعتاد القيام بذلك في المشروع)

ولكن سيتم تمييزها بسهولة عن المتغير المحلي لأنه في مشروعي، تتم تسمية هذه المتغيرات المحلية دائمًا:

أشئ ما:يمثل كائن واحد.
بعضاشياء كثيرة:قائمة الكائنات.
يكونالدولة أو لديهشئ ما:للحالة المنطقية.

أي متغير لا يبدأ بـ "a" أو "some" أو "is/has" هو متغير عضو.

نظرًا لأن VB.NET ليس حساسًا لحالة الأحرف، فإنني أبدأ متغيرات الأعضاء الخاصة بي بشرطة سفلية وحالة الجمل في بقية الاسم.أنا أكتب أسماء الممتلكات بالأحرف الكبيرة.

Dim _valueName As Integer

Public Property ValueName() As Integer

أنا مع الأشخاص الذين لا يستخدمون البادئات.

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

هذا بالإضافة إلى ما يمكنك الحصول عليه من سياق المتغير واصطلاحات التسمية (مثل LowerCamelCase للمتغيرات المحلية والحقول الخاصة، وUpperCamelCase للخصائص والأساليب وما إلى ذلك) وأشياء مثل "hasXXXX" و"isXX" للقيم المنطقية.

لم أستخدم البادئات لسنوات ، لكنني اعتدت أن أكون "هذا". بادئة وحش لكنني خرجت من ذلك ما لم يكن ذلك ضروريًا (شكرًا ، Resharper).

أنا غريب الأطوار وأبدأ متغيرات الأعضاء بالأحرف الأولى من اسم الفئة (وهو مكتوب على شكل جمل).

TGpHttpRequest = class(TOmniWorker)
strict private
  hrHttpClient  : THttpCli;
  hrPageContents: string;
  hrPassword    : string;
  hrPostData    : string;

معظم الأشخاص في دلفي يستخدمون F.

TGpHttpRequest = class(TOmniWorker)
strict private
  FHttpClient  : THttpCli;
  FPageContents: string;
  FPassword    : string;
  FPostData    : string;

واحد _ يستخدم فقط كمؤشر بصري.(ج #)

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

`_` بدلاً من `this.`

أنا أستعمل _ أيضا بدلا من this. لأنه مجرد أقصر (4 أحرف أقل) وهو مؤشر جيد لمتغيرات الأعضاء.علاوة على ذلك، باستخدام هذه البادئة يمكنك تجنب تعارض الأسماء.مثال:

public class Person {
  private String _name;

  public Person(String name) {
    _name = name;
  }
}

قارنها بهذا:

public class Person {
  private String name;

  public Person(String name) {
    this.name = name;
  }
}

أجد المثال الأول أقصر وأكثر وضوحا.

يعتمد الأمر نوعًا ما على اللغة التي تعمل بها.

في C# يمكنك الإشارة إلى أي عضو باستخدام البادئة "هذا"، على سبيل المثال.'this.val'، مما يعني عدم الحاجة إلى البادئات.يتمتع VB بقدرة مماثلة مع "Me".

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

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

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

لقد اعتدت على استخدام m_ perfix في C++ ولكن في C# أفضل استخدام حالة الجمل للحقل وحالة باسكال لممتلكاته.

private int fooBar;
public int FooBar
{
  get { return fooBar; }
  set { fooBar = value; }
}

أنا أحب m_ ولكن طالما تم استخدام الاتفاقية في قاعدة التعليمات البرمجية فأنا مرتاح لها.

يتجه مثالك المتعدد نحو تدوين Apps المجرية الخاص بـ Charles Simonyi.

أفضل إبقاء الأمور بسيطة ولهذا السبب أحب استخدام m_ كبادئة.

يؤدي القيام بذلك إلى تسهيل معرفة المكان الذي يتعين عليك الذهاب إليه لرؤية الإعلان الأصلي.

أميل إلى استخدام m_ في لغة C++، لكن لا أمانع في تركه بعيدًا في Java أو C#.ويعتمد ذلك على معيار الترميز.بالنسبة للكود القديم الذي يحتوي على مزيج من الشرطة السفلية وm_، سأعيد صياغة الكود وفقًا لمعيار واحد (نظرًا لحجم الكود المعقول)

أنا أستعمل @.

:D j/k - ولكن إذا كان الأمر يعتمد على اللغة.إذا كان يحتوي على حروف/مجموعات، فعادةً ما أضع _ أمام متغير العضو الخاص وسيكون لـ getter/setter نفس الاسم بدون _.بخلاف ذلك، عادةً لا أستخدم أيًا منها.

بالنسبة لمشاريعي الخاصة، أستخدم _ كلاحقة (كما أشار مارتن يورك أعلاه، _ كبادئة هي محفوظة وفقًا لمعيار C/C++ لتطبيقات المترجم) وi عند العمل على مشاريع سيمبيان.

في Java، إحدى القواعد الشائعة هي تقديم متغيرات الأعضاء بـ "my" وUseCamelCaseForTheRestOfTheVariableName.

لا شيء إذا لم يكن ذلك ضروريًا، أو شرطة سفلية واحدة بخلاف ذلك.ينطبق على بيثون.

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

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

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow

ما نوع البادئة التي تستخدمها لمتغيرات الأعضاء؟

_ بدلاً من this.

`_` بدلاً من `this.`