لماذا لا يجب أن أقوم بإضافة بادئة لحقولي؟[مغلق]

Question

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

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

ال اصطلاحات التسمية لصفحة الحقول في MSDN يقول لا ينبغي لي، لكنه لا يذكر السبب (الطريقة على سبيل المثال:تميل اتفاقيات Google عمومًا إلى ترشيد وصفاتها).

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

Answer 1

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

Answer 2

متى يجب عليك:

• عندما تنص إرشادات ترميز مشروعك على ضرورة ذلك

عندما لا ينبغي عليك:

• عندما تقول إرشادات ترميز مشروعك أنه لا ينبغي عليك ذلك

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

باختصار، لا أعتقد أن هناك طريقًا "صحيحًا" وطريقًا "خاطئًا".

Answer 3

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

string m_name;
public string Name { get { return m_name; } }

أو

string _Name;
public string Name { get { return _Name; } }

و(أو أي اتفاقية أخرى)، يمكنك الآن كتابة

public string Name { get; private set; }

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

من الواضح، لا تنطبق هذه المقولة عندما كنت حقا بحاجة متجر دعم صريح مثل لإجراء التحقق من الصحة.

Answer 4

وأما البعض ألمح إلى وتقول المبادئ التوجيهية MS:

<اقتباس فقرة>   

لا تستخدم بادئة لأسماء الحقول.   على سبيل المثال، لا تستخدم G_ أو S_ ل   التمييز ثابت مقابل غير ثابت   المجالات.

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

Answer 5

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

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

int foo;
public int Foo
{
  get { return foo; }
}

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

Answer 6

وأنا أحاول أن اتبع المبادئ التوجيهية مكتبة MSDN. NET . وهي تشمل تسمية القسم المبادئ التوجيهية .

ومن الواضح أن هذه هي الثانوية للمبادئ التوجيهية المشروع.

Answer 7

وأنا أفضل للاحتفال مجالات دعم الملكية (على الرغم كما سبق ذكره 3.0+ الصافي يقلل من الحاجة وذلك بفضل خصائص تلقائي) مع سفلية ولكن ليس "م". لأحد أن يضعهم في أعلى القائمة InteliSense عندما جئت لاستخدامها.

وأنا لن أعترف أنني بحاجة إلى فرشاة المتابعة على المبادئ التوجيهية بشأن MSDN، يمكن أن تتغير الأمور بسرعة في هذه الأيام.

Answer 8

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

Answer 9

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

يستخدم معظم الأشخاص الذين أعمل معهم البادئة m_/s_.لا أعتقد حقًا أن ما تستخدمه يهم كثيرًا، طالما أنك متسق.

Answer 10

وأنا أبدا استخدامها. وتشجع الترميز قذرة. وMSDN الترميز المبادئ التوجيهية، وهذا حيث انه في.

Answer 11

وفيما يلي بعض الأسباب لاستخدام _ (وليس م _).

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

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

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

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

Answer 12

وهناك فارق واحد مهم بين C ++ و C #: دعم أداة. عند اتباع المبادئ التوجيهية الموضوعة (أو الاختلافات الشائعة)، سوف تحصل على المستوى العميق للدعم الأداة التي C ++ لم يكن. وفق معايير تسمح أدوات للقيام إعادة بيع ديون أعمق / إعادة تسمية العمليات من تريد ان تكون قادرة على خلاف ذلك. Resharper يفعل هذا. حتى عصا مع واحد من المعايير المعمول بها.

Answer 13

وكما يذكرJohn كرافت، لا يوجد "الصحيحة" الجواب. MattJ هو الأقرب - يجب أن تتبع دائما المبادئ التوجيهية الخاصة بالشركة الاسلوب. عندما تكون في روما، وجميع ذلك.

وأما عن رأيي الشخصي، نظرا لأنه دعا إلى هنا، وأنا التصويت الذي قمت بإسقاط m_ تماما.

وأعتقد أن أفضل أسلوب هو واحد حيث جميع الأعضاء PascalCased، بغض النظر عن الرؤية (وهذا يعني حتى أعضاء private)، وجميع الحجج وcamelCased. أنا لا كسر هذا النمط.

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

وبدلا من m_MyProperty (أو حتى _MyProperty، الذي رأيت وحتى الترويج ذات مرة)، استخدم MyPropertyValue. انها أسهل في القراءة والفهم و- الأهم من ذلك - انها قريبة من اسم الخاصية الأصلي في التحسس.

وأخيرا، وهذا هو السبب في أنني أفضل أن يكون لواحق. إذا كنت ترغب في الوصول إلى MyPropertyValue باستخدام التحسس التي (عادة) اكتب "My <down-arrow> <tab>"، منذ ذلك الحين كنت قريبة بما فيه الكفاية فقط MyProperty وMyPropertyValue هي على القائمة. إذا كنت ترغب في الوصول m_MyProperty باستخدام التحسس، سيكون لديك لكتابة "m_My <tab>".

ولقد حان الاقتصاد المفاتيح، في رأيي.

Answer 14

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

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

وعلى أية حال، هذا هو بلدي اثنين سنتا.

Answer 15

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

وشخص ما، من فضلك، شرح أسلوب. NET من I-بادئة على واجهات. :)

Answer 16

وماذا أنا اعتدت على أن الممتلكات الخاصة حصلت صغير underscone f.ex "_name السلسلة". واحد العام حصلت "الاسم". والمتغيرات الإدخال في أساليب حصلت إلكتروني صغير "MyMethod باطل (اسم سلسلة)".

وإذا كنت حصلت على CONST ثابت وغالبا ما تكون مكتوبة بأحرف كبيرة. static const MYCONST = "hmpf".

Answer 17

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

Answer 18

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

وماذا اخترنا لمستوى نظامنا هو استخدام _ كما البادئة للمتغيرات الأعضاء. كان واحدا من الأسباب التي يجعل من السهل العثور على المتغيرات المحلية في التحسس.

وقبل اتفقنا على أن معيار اعتدت بعضها البعض. لم أكن استخدام أي اختصار في كل شيء، وكتب this.memberVariable في رمز لاظهار ان كنت تستخدم متغير عضو.

ومع الاختزال العقارات في C # 3، أجد أنني استخدام المتغيرات عضو أقل كثيرا صريحة.

Answer 19

أقرب شيء إلى المبادئ التوجيهية الرسمية هو StyleCop, ، وهي أداة من Microsoft يمكنها تحليل ملفات المصدر الخاصة بك تلقائيًا واكتشاف الانتهاكات من نمط الترميز الموصى به، ويمكن تشغيلها من داخل Visual Studio و/أو الإصدارات التلقائية مثل MSBuild.

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

للإجابة على سؤالك - لا يسمح بأي تدوين مجري أو أي بادئات مثل m_ (في الواقع، لا يسمح باستخدام الشرطات السفلية على الإطلاق).

Answer 20

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

Answer 21

قد يكون هناك أيضًا بعض الأفكار التي يمكن استخلاصها منها معايير الترميز C++ (سوتر، هيرب و ألكسندرسكوم أندريه, ، 2004).البند رقم 0 بعنوان "لا تهتم بصغائر الأمور.(أو:تعرف على ما لا ينبغي توحيده.)".

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

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

Answer 22

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

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

Answer 23

أنا متأكد من أنني سأشتعل بسبب هذا ولكن فليكن.

يُطلق عليها اسم إرشادات مكتبة .NET الخاصة بـ Microsoft ولكنها في الواقع براد أبرامز الآراء (وثيقة هنا) - هناك آراء أخرى لها أسباب وجيهة.

يميل الناس إلى اتباع وجهة نظر الأغلبية بدلاً من وجود أسباب قوية وجيدة لأسلوب معين.

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

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

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

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

اتفاقية التسمية المتغيرة

لدينا جميعًا وجهة نظرنا بشأن اصطلاحات التسمية المتغيرة.هناك العديد من الأنماط المختلفة التي ستساعد في إنتاج تعليمات برمجية عالية الجودة يمكن صيانتها بسهولة - أي نمط يدعم المعلومات الأساسية الأساسية حول المتغير مقبول.يجب أن تكون معايير اصطلاح التسمية المحدد هي أنها تساعد في إنتاج تعليمات برمجية موثوقة ويمكن صيانتها بسهولة.المعايير التي لا ينبغي استخدامها هي:إنها Microsoft القبيحة (أيبراد أبرامز) يقول لا تستخدم هذا الأسلوب - لا تنتج Microsoft دائمًا التعليمات البرمجية الأكثر موثوقية، ما عليك سوى إلقاء نظرة على الأخطاء الموجودة في Expression Blend.من المهم جدًا عند قراءة التعليمات البرمجية أن ينقل اسم المتغير على الفور ثلاث حقائق أساسية حول المتغير:إنه نطاق ، إنه نوع A يفهم بوضوح حول ما يستخدم للنطاق:توصي Microsoft بالاعتماد بشكل كامل على IntelliSense.IntelliSense رائع.ومع ذلك، لا يمكن للمرء ببساطة تمرير الماوس فوق كل متغير لمعرفة نطاقه ونوعه.بافتراض وجود متغير في نطاق غير موجود فيه، يمكن أن يسبب أخطاء كبيرة.على سبيل المثال، إذا تم تمرير متغير مرجعي كمعلمة وتم تغييره في النطاق المحلي، فسيظل هذا التغيير بعد إرجاع الطريقة وهو ما قد لا يكون مرغوبًا فيه.إذا تم تعديل حقل أو متغير ثابت في النطاق المحلي ولكن يعتقد المرء أنه متغير محلي فقد يؤدي ذلك إلى سلوك غير متوقع.لذلك من المهم للغاية أن تكون قادرًا على مجرد إلقاء نظرة على المتغير (وليس فوقه بالماوس) ومعرفة نطاقه على الفور.

يُقترح النمط التالي للإشارة إلى النطاق؛ومع ذلك، فإن أي نمط مقبول تمامًا طالما أنه يشير بشكل واضح ومتسق إلى نطاق المتغير:تم تمرير متغير حقل M_ P_ إلى طريقة S_ متغير متغير محلي النوع:يمكن أن تحدث أخطاء جسيمة إذا اعتقد المرء أنه يعمل مع نوع معين في حين أنه يعمل بالفعل مع نوع مختلف - مرة أخرى، نحن ببساطة لا نمرر الماوس فوق أي متغير لتحديد نوعه، بل نفترض فقط أننا نعرف نوعه ونعرفه. هذه هي الطريقة التي يتم بها إنشاء الأخطاء.

الاختصارات:الاختصارات شريرة لأنها يمكن أن تعني أشياء مختلفة لمطورين مختلفين.قد يعتقد أحد المطورين أن الأحرف الصغيرة الرائدة "s" تعني سلسلة بينما قد يعتقد آخر أنها تعني عددًا صحيحًا موقّعًا.الاختصارات هي علامة على الترميز البطيء - خذ بعض الوقت الإضافي واكتب الاسم الكامل لتوضيح للمطور الذي يتعين عليه الحفاظ على الكود.على سبيل المثال، الفرق بين "str" ​​و"string" هو ثلاثة أحرف فقط - ولا يتطلب الأمر الكثير من الجهد لتسهيل صيانة التعليمات البرمجية.

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

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

ترتيب أجزاء الاسم المتغير:الترتيب الموصى به هو وصف نوع النطاق للأسباب التالية:سوف يقوم Intellisense بتجميع جميع النطاقات المماثلة ، وفي كل نطاق سيقوم Intellisense بتجميع جميع الأنواع المماثلة مما يجعل عمليات البحث سهلة - حاول العثور على متغير في الطريقة الأخرى التي تجعل من السهل جدًا رؤية النطاق وفهمه ورؤية وفهم النوع الشائع إلى حد ما الأسلوب وسهل الفهم أنه سوف يمر FXCOP

أمثلة:وفيما يلي بعض الأمثلة على ذلك:M_StringCustomerName p_stringCustomerDatabasEconnectionString intnumberofCustomerRecords أو inumberofcustomerrecords أو integernumberofCustomerRecords سوف تحسن هذه القواعد البسيطة بشكل كبير موثوقية الكود والصيانة.

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

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

المسافة الفارغةالمسافة البادئة ليست قضية رئيسية؛ومع ذلك، يُقترح أربع مسافات وعدم استخدام علامات التبويب.إذا تمت طباعة التعليمات البرمجية، فعادةً ما تكون علامة تبويب الطابعة الأولى افتراضية 8 مسافات.يميل المطورون المختلفون إلى استخدام أحجام علامات تبويب مختلفة.عادةً ما يتم وضع مسافة بادئة لرمز Microsoft بأربع مسافات، لذا إذا استخدم أحد أي كود Microsoft واستخدم غير 4 مسافات، فسوف يحتاج الرمز إلى إعادة التنسيق.أربع مسافات تجعل الأمر سهلاً ومتسقًا.

Answer 24

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

Answer 25

كن وظيفيا.

• لا تستخدم المتغيرات العالمية.
• لا تستخدم المتغيرات الثابتة.
• لا تستخدم متغيرات الأعضاء.

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