هل هناك أي اقتراحات لتطوير وثيقة معايير ترميز C#/أفضل الممارسات؟[مغلق]

Question

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

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

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

لذلك هنا يذهب ....أي اقتراحات؟أي على الإطلاق؟

Answer 1

نبدأ مع

• إرشادات Microsoft .NET: http://msdn.microsoft.com/en-us/library/ms229042.aspx (تم تحديث الرابط لـ .NET 4.5)
• إرشادات Microsoft C#: http://blogs.msdn.com/brada/articles/361363.aspx.

ثم قم بتوثيق الاختلافات والإضافات إلى خط الأساس هذا.

Answer 2

انا اصمم يحتوي على مستند معايير ترميز C# الشائع الاستخدام.انظر أيضا إرشادات تصميم الإطار الطبعة الثانية.

Answer 3

ومن المفارقات أن وضع المعايير الفعلية من المرجح أن يكون الجزء السهل.

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

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

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

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

Answer 4

لقد استخدمت دائمًا Juval Lowy's بي دي إف كمرجع عند تطبيق معايير الترميز/أفضل الممارسات داخليًا.ويتبع قريبة جدا من FxCop/تحليل المصدر, ، وهي أداة أخرى لا تقدر بثمن للتأكد من اتباع المعيار.ومن بين هذه الأدوات والمراجع، يجب أن تكون قادرًا على التوصل إلى معيار جيد لن يمانع جميع المطورين لديك في اتباعه ويكونون قادرين على تنفيذه.

Answer 5

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

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

أوافق على أن FxCop هي أداة جيدة ولكن الكثير من هذا يمكن أن يأخذ كل المتعة من البرمجة، لذا كن حذرًا.

Answer 6

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

1. الإغلاق جيد بما فيه الكفاية - يعد تغيير التعليمات البرمجية لاتباع معايير الترميز حرفيًا مضيعة للوقت طالما أن التعليمات البرمجية قريبة بدرجة كافية.
2. إذا كنت تقوم بتغيير التعليمات البرمجية التي لم تكتبها، فاتبع "معايير الترميز المحلية"، أي.اجعل الكود الجديد الخاص بك يشبه الكود المحيط.

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

Answer 7

لقد وجدت الوثائق التالية مفيدة وموجزة للغاية.إنه يأتي من موقع idesign.net وهو من تأليف جوفال لوي

معيار الترميز C#

ملحوظة:الرابط أعلاه ميت الآن.للحصول على ملف .zip، يتعين عليك منحهم عنوان بريدك الإلكتروني (لكنهم لن يستخدموه للتسويق...بصراحة) حاول هنا

Answer 8

لقد بدأت للتو في مكان تفرض فيه معايير الترميز استخدام m_ لمتغيرات الأعضاء، وp_ للمعلمات والبادئات للأنواع، مثل "str" ​​للسلاسل.لذا، قد يكون لديك شيء مثل هذا في نص الطريقة:

m_strName = p_strName;

فظيع.فظيع حقا.

Answer 9

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

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

إنه يستحق التدقيق ;)

Answer 10

تعتبر قواعد Microsoft الخاصة نقطة انطلاق ممتازة.يمكنك فرضها باستخدام FxCop.

Answer 11

سأميل إلى فرض StyleCop من Microsoft كمعيار.يمكن تنفيذه في وقت البناء.ولكن إذا كان لديك كود قديم، فما عليك سوى فرض استخدام StyleCop على الكود الجديد.

http://code.msdn.microsoft.com/sourceanalogy

في النهاية سيكون لديه خيار إعادة البناء لتنظيف التعليمات البرمجية.

http://blogs.msdn.com/sourceanalogy/

Answer 12

أنا شخصياً أحب ذلك انا اصمم وقد وضعت معا.لكن هذا ليس سبب نشري...

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

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

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

Answer 13

كما كتبت كلاً من المنشور المنشور لصالح شركة Philips Medical Systems والذي كتبه http://csharpguidelines.codeplex.com قد أكون متحيزًا بعض الشيء، لكن لدي أكثر من 10 سنوات في الكتابة والصيانة والترويج لمعايير الترميز.لقد حاولت كتابة CodePlex مع أخذ الاختلافات في الآراء في الاعتبار وأمضيت معظم المقدمة في كيفية التعامل مع ذلك في مؤسستك الخاصة.إقرأها وأعطيني رأيك .....

Answer 14

قواعد SSW

يتضمن بعض معايير C# + الكثير...تركز بشكل أساسي على مطوري Microsoft

Answer 15

على الأرجح يتم إعدادك للفشل.مرحبا بكم في هذه الصناعة.

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

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

Answer 16

لقد وجدت مؤخرا كتيب التشفير C#, ، والذي يتضمن أفكارًا من العديد من المصادر الأخرى (IDesign، Philips، MSDN).

قد يكون مصدر آخر إرشادات الترميز الاحترافية لـ C#/VB .NET.

Answer 17

أنا من أشد المعجبين بكتاب فرانشيسكو بالينا "إرشادات عملية وأفضل الممارسات لمطوري VB وC#".

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

Answer 18

يقرأ معيار الترميز بأكمله تقريبًا، "استخدم StyleCop".

Answer 19

انظر الى هذا:http://www.noesispedia.com/post/2008/11/28/C-Coding-Guidelines-and-Best-Practices.aspx.

Answer 20

لا بد لي من اقتراح dotnetspider.com وثيقة.
إنها وثيقة رائعة ومفصلة ومفيدة في أي مكان.

Answer 21

لقد استخدمت Juval من قبل، وهذا إن لم يكن مبالغًا فيه، لكنني كسول والآن أتوافق مع إرادة ريشاربر.

Answer 22

يمكنك الاطلاع على أفضل 7 معايير للترميز ومستندات توجيهية لمطوري C#/.NET http://www.amazedsaint.com/2010/11/top-6-coding-standards-guideline.html أتمنى أن يساعدك هذا

Answer 23

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

وهو أمر مثير للاهتمام لأن مديري أخبرني في الماضي أنه ليس مهتمًا بهم كثيرًا:D

لديك مهمة ممتعة أمامك يا صديقي.حظا سعيدا، ويرجى السؤال إذا كنت بحاجة إلى أي شيء آخر :)

Answer 24

إن المعيار الذي وضعته شركة Philips Medical Systems مكتوب بشكل جيد، ويتبع في الغالب إرشادات Microsoft:www.tiobe.com/content/paperinfo/gemrcsharpcs.pdf

تعتمد معاييري على هذا مع بعض التعديلات وبعض التحديثات لـ .NET 2.0 (معيار Philips مكتوب لـ .NET 1.x لذا فهو قديم بعض الشيء).

Answer 25

أنا أتابع أيضًا Resharper.كما تم ذكر السطر الإرشادي في مدونة سكوت جوثريhttp://weblogs.asp.net/scottgu/archive/2007/10/08/october-8th-links-asp-net-asp-net-ajax-silverlight-and-net.aspxوhttp://csharpguidelines.codeplex.com/releases/view/46280

Answer 26

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

أنا أكره كيف يهدر كود Microsoft المساحة:

try
{
    if (condition)
    {
        Something(new delegate
        {
            SomeCall(a, b);
        });
    }
    else
    {
        SomethingElse();
        Foobar(foo, bar);
    }
}
catch (Exception ex)
{
    Console.WriteLine("Okay, you got me");
}

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

أنا أيضًا أحب الطريقة التي يضعون بها مسافة قبل فتح القوس.

try {
        if (condition) {
                Something (new delegate {
                        SomeCall (a, b);
                });
        } else {
                SomethingElse ();
                Foobar (foo, bar);
        }
} catch (Exception ex) {
        Console.WriteLine ("Okay, you got me");
}

ولكن من فضلك، لا تفرض أي شيء من هذا القبيل إذا لم يعجب زملائك في العمل (إلا إذا كنت على استعداد للمساهمة في Mono؛-)