มีข้อเสนอแนะใด ๆ สำหรับการพัฒนามาตรฐานการเข้ารหัส C # / แนวทางปฏิบัติที่ดีที่สุดหรือไม่? [ปิด]

ฉันเป็นบัณฑิต AI ล่าสุด (ประมาณ 2 ปี) ที่ทำงานเพื่อการดำเนินงานที่เรียบง่าย มันทำให้ฉันตกหลุม (โดยเฉพาะอย่างยิ่งฉันเป็น 'ผู้รับบุตรบุญธรรม' คนแรกในแผนก) เพื่อสร้างพื้นฐาน (อ่านมีประโยชน์?) C # เอกสารมาตรฐานการเข้ารหัส

ฉันคิดว่าฉันควรอธิบายว่าฉันน่าจะเป็นวิศวกรซอฟต์แวร์รุ่นต่อไป แต่ฉันหวังว่าจะทำงานนี้เพราะหวังว่าฉันจะสามารถใช้งานได้ครึ่งหนึ่ง ฉันได้ทำการค้นหาอย่างกว้างขวางเกี่ยวกับอินเทอร์เน็ตและอ่านบทความเกี่ยวกับเอกสารมาตรฐานการเข้ารหัสที่ควร / ไม่ควรมี ดูเหมือนว่าจะเป็นสถานที่ที่ดีสำหรับการขอคำแนะนำ

ฉันตระหนักว่าฉันอาจเปิดประตูสู่โลกทั้งโลกที่ไม่เห็นด้วยเกี่ยวกับ 'วิธีที่ดีที่สุดในการทำสิ่งต่าง ๆ ' ฉันเข้าใจและเคารพในความจริงที่ปฏิเสธไม่ได้ว่าโปรแกรมเมอร์แต่ละคนมีวิธีการที่เหมาะสมในการแก้ปัญหาแต่ละงานดังนั้นฉันจึงไม่ต้องการเขียนอะไรเลยดังนั้นจึงอธิบายได้อย่างไร้เหตุผลว่าจะยับยั้งไหวพริบส่วนบุคคล แต่พยายามหาวิธีทั่วไป มาตรฐาน (เช่นการตั้งชื่อการประชุม) เพื่อช่วยให้รหัสบุคคลอ่านง่ายขึ้น

ดังนั้นที่นี่ไป .... ข้อเสนอแนะใด ๆ อะไรบ้าง?

เราเริ่มต้นด้วย

• หลักเกณฑ์. NET ของ Microsoft: http://msdn.microsoft.com/en-us/library/ms229042.aspx (ลิงก์ที่อัพเดตสำหรับ. NET 4.5)
• ไมโครซอฟท์ C # แนวทาง: http://blogs.msdn.com/brada/articles/361363.aspx

จากนั้นจัดทำเอกสารความแตกต่างจากและส่วนเพิ่มเติมไปยังข้อมูลพื้นฐานนั้น

IDesignมีเอกสารมาตรฐานการเข้ารหัส C # ที่ใช้กันทั่วไป ยังเห็นกรอบแนวทางการออกแบบที่ 2 เอ็ด

การกำหนดมาตรฐานที่แท้จริงอย่างน่าขันว่าน่าจะเป็นส่วนที่ง่าย

คำแนะนำแรกของฉันคือการดึงคำแนะนำจากวิศวกรคนอื่นเกี่ยวกับสิ่งที่พวกเขารู้สึกว่าควรได้รับการคุ้มครองและแนวทางที่พวกเขารู้สึกว่ามีความสำคัญ การบังคับใช้แนวทางใด ๆ จำเป็นต้องมีระดับการซื้อจากผู้คน หากคุณวางเอกสารลงบนเอกสารที่ระบุวิธีการเขียนโค้ดคุณจะพบกับการต่อต้านไม่ว่าคุณจะเป็นรุ่นน้องหรือรุ่นอาวุโส

หลังจากที่คุณมีข้อเสนอชุดหนึ่งแล้วส่งพวกเขาออกไปยังทีมเพื่อรับคำติชมและตรวจสอบ อีกครั้งรับคนซื้อทั้งหมดลงในพวกเขา

อาจมีวิธีการเข้ารหัสที่ไม่เป็นทางการซึ่งนำมาใช้แล้ว (เช่นตัวแปรสมาชิกนำหน้าชื่อฟังก์ชัน camelcase) หากสิ่งนี้มีอยู่และรหัสส่วนใหญ่เป็นไปตามนั้นมันจะจ่ายเงินให้เป็นทางการใช้งาน การนำมาตรฐานที่ตรงกันข้ามมาใช้จะทำให้เกิดความเศร้าโศกมากกว่ามูลค่าแม้ว่าจะเป็นสิ่งที่แนะนำโดยทั่วไปก็ตาม

นอกจากนี้ยังควรพิจารณาการปรับเปลี่ยนรหัสที่มีอยู่เพื่อให้ตรงกับมาตรฐานการเข้ารหัสใหม่ สิ่งนี้อาจดูเหมือนเป็นการเสียเวลา แต่การมีโค้ดที่ไม่ตรงตามมาตรฐานสามารถตอบโต้ได้เพราะคุณจะมีรูปแบบที่แตกต่างกันไป นอกจากนี้ยังทำให้ผู้คนตกอยู่ในภาวะที่กลืนไม่เข้าคายไม่ออกไม่ว่าจะเป็นรหัสในโมดูลที่แน่นอนควรเป็นไปตามมาตรฐานใหม่หรือตามสไตล์รหัสที่มีอยู่

ฉันใช้PDFของ Juval Lowy เป็นข้อมูลอ้างอิงเสมอเมื่อทำการเข้ารหัสมาตรฐาน / แนวปฏิบัติที่ดีที่สุดภายใน มันติดตามอย่างใกล้ชิดกับFxCop / การวิเคราะห์แหล่งที่มาซึ่งเป็นอีกเครื่องมือหนึ่งที่ประเมินค่าไม่ได้เพื่อให้แน่ใจว่ามีการปฏิบัติตามมาตรฐาน ระหว่างเครื่องมือและการอ้างอิงเหล่านี้คุณควรจะได้รับมาตรฐานที่ดีที่นักพัฒนาซอฟต์แวร์ของคุณจะไม่สนใจติดตามและสามารถบังคับใช้พวกเขาได้

โปสเตอร์อื่น ๆ ได้ชี้ให้คุณเห็นที่พื้นฐานสิ่งที่ฉันเพิ่มคือทำให้เอกสารของคุณสั้นหวานและตรงประเด็นใช้ Strunk และ White ปริมาณมากเพื่อแยกความแตกต่างของ "ต้องมี" จาก "มันคงจะดีถ้า "

ปัญหาเกี่ยวกับเอกสารมาตรฐานการเข้ารหัสคือไม่มีใครอ่านพวกเขาอย่างที่ควรจะเป็นและเมื่อพวกเขาอ่านพวกเขาพวกเขาจะไม่ติดตามพวกเขา ความน่าจะเป็นของเอกสารที่กำลังอ่านและติดตามนั้นแตกต่างกันไปตามความยาวของเอกสาร

ฉันเห็นด้วย FxCop เป็นเครื่องมือที่ดี แต่สิ่งนี้มากเกินไปที่จะทำให้ความสนุกหมดไปจากการเขียนโปรแกรมดังนั้นควรระมัดระวัง

อย่าเขียนมาตรฐานการเข้ารหัสของคุณเองใช้ MS (หรือ Sun หรือ ... ตามความเหมาะสมกับภาษาของคุณ) เบาะแสอยู่ในมาตรฐานของคำว่าโลกจะเป็นสถานที่ที่ง่ายกว่าในการเขียนโค้ดหากแต่ละองค์กรไม่ได้ตัดสินใจเขียนเอง ใครที่คิดว่าการเรียนรู้ 'มาตรฐาน' ชุดใหม่ทุกครั้งที่คุณเปลี่ยนทีม / โครงการ / บทบาทคือการใช้เวลาของทุกคนให้เป็นประโยชน์ สิ่งที่คุณควรทำมากที่สุดคือสรุปประเด็นสำคัญ แต่ฉันขอแนะนำไม่ให้ทำเช่นนั้นเพราะสิ่งที่สำคัญแตกต่างกันไปในแต่ละบุคคล อีกสองประเด็นที่ฉันต้องการสร้างมาตรฐานการเข้ารหัส

1. การปิดดีพอ - การเปลี่ยนรหัสให้เป็นไปตามมาตรฐานการเข้ารหัสเป็นตัวอักษรเสียเวลาตราบรหัสใกล้พอ
2. หากคุณเปลี่ยนรหัสคุณไม่ได้เขียนตาม 'มาตรฐานการเข้ารหัสในพื้นที่' เช่นทำให้รหัสใหม่ของคุณดูเหมือนรหัสโดยรอบ

จุดสองจุดนี้เป็นความจริงของความปรารถนาของฉันที่ทุกคนจะเขียนโค้ดที่ดูเหมือนกัน

ฉันพบเอกสารดังต่อไปนี้มีประโยชน์มากและกระชับ มันมาจากเว็บไซต์ idesign.net และเขียนโดย Juval Lowy

มาตรฐานการเข้ารหัส C #

NB: ลิงค์ด้านบนตอนนี้ตายแล้ว ในการรับไฟล์. zip คุณจะต้องให้ที่อยู่อีเมลแก่คุณ (แต่พวกเขาจะไม่ใช้เพื่อการตลาด ... โดยสุจริต) ลองที่นี่

ฉันเพิ่งเริ่มต้นในสถานที่ที่มาตรฐานการเข้ารหัสมอบอำนาจให้ใช้ m_ สำหรับตัวแปรสมาชิก, p_ สำหรับพารามิเตอร์และส่วนนำหน้าสำหรับประเภทเช่น 'str' สำหรับสตริง ดังนั้นคุณอาจมีบางอย่างเช่นนี้ในร่างกายของวิธีการ:

m_strName = p_strName;

น่ากลัว น่ากลัวจริงๆ

ฉันจะเพิ่มCode Complete 2ในรายการ (ฉันรู้ว่า Jeff เป็นแฟนของที่นี่) ... หากคุณเป็นนักพัฒนารุ่นน้องหนังสือเล่มนี้จะมีประโยชน์ในการตั้งค่าความคิดของคุณในแบบที่เป็นรากฐานที่ดีที่สุด การเขียนโค้ดและการสร้างซอฟต์แวร์มี

ฉันต้องบอกว่าฉันมาสายในอาชีพของฉันได้บ้าง แต่มันก็มีกฎหลายวิธีที่ฉันคิดเกี่ยวกับการเขียนโปรแกรมและการพัฒนากรอบในชีวิตการทำงานของฉัน

มันคุ้มค่าที่จะเช็คเอาท์;)

กฎของ Microsoft เป็นจุดเริ่มต้นที่ยอดเยี่ยม คุณสามารถบังคับใช้กับ FxCop

ฉันจะถูกล่อลวงให้บังคับใช้ StyleCop ของ Microsoft เป็นมาตรฐาน มันสามารถบังคับใช้ในเวลาที่สร้าง แต่ถ้าคุณมีรหัสดั้งเดิมให้บังคับใช้ StyleCop กับรหัสใหม่

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

ในที่สุดมันจะมีตัวเลือก refactor เพื่อล้างรหัส

http://blogs.msdn.com/sourceanalysis/

โดยส่วนตัวแล้วฉันชอบสิ่งที่IDesignรวบรวมเข้าด้วยกัน แต่นั่นไม่ใช่เหตุผลที่ฉันโพสต์ ...

บริษัท ของฉันมีเล่ห์เหลี่ยมเล็กน้อยก็คือการคำนึงถึงภาษาต่าง ๆ ทั้งหมด และฉันรู้ว่า บริษัท ของฉันไม่ได้อยู่คนเดียวในเรื่องนี้ เราใช้ C #, C, แอสเซมบลี (เราสร้างอุปกรณ์), SQL, XAML และอื่น ๆ ถึงแม้ว่าจะมีความคล้ายคลึงกันในมาตรฐาน แต่ก็มักจะจัดการแตกต่างกัน

นอกจากนี้ฉันเชื่อว่ามาตรฐานระดับสูงขึ้นมีผลกระทบมากขึ้นกับคุณภาพของผลิตภัณฑ์ขั้นสุดท้าย ตัวอย่างเช่น: วิธีการและเวลาที่จะใช้ความคิดเห็นเมื่อข้อยกเว้นมีผลบังคับใช้ (เช่นเหตุการณ์ที่เริ่มโดยผู้ใช้) ไม่ว่าจะ (หรือเมื่อใด) ที่จะใช้ข้อยกเว้นเทียบกับค่าส่งคืนเป็นวิธีที่วัตถุประสงค์เพื่อกำหนดว่า ฯลฯ อย่าเข้าใจฉันผิดมาตรฐานระดับต่ำก็จำเป็นเช่นกัน (การจัดรูปแบบสำคัญต่อการอ่าน!) ฉันมีอคติต่อโครงสร้างโดยรวม

สิ่งที่ควรทราบอีกอย่างคือการซื้อและการบังคับใช้ มาตรฐานการเข้ารหัสที่ยอดเยี่ยม แต่ถ้าไม่มีใครเห็นด้วยกับพวกเขาและ (อาจสำคัญกว่า) ไม่มีใครบังคับพวกเขานั่นคือทั้งหมดที่ไร้ค่า

ในขณะที่ฉันเขียนทั้งสองฉบับที่ตีพิมพ์สำหรับ Philips Medical Systems และอีกเรื่องในhttp://csharpguidelines.codeplex.comฉันอาจจะลำเอียงเล็กน้อย แต่ฉันมีมากกว่า 10 ปีในการเขียนการบำรุงรักษาและการส่งเสริมมาตรฐานการเข้ารหัส ฉันได้พยายามเขียน CodePlex หนึ่งฉบับที่มีความคิดเห็นต่างกันในใจและใช้เวลาส่วนใหญ่ในการแนะนำวิธีจัดการกับสิ่งนั้นในองค์กรของคุณ อ่านและให้ข้อเสนอแนะกับฉัน .....

กฎ SSW

มันประกอบไปด้วยมาตรฐาน C # บางส่วนและอื่น ๆ อีกมากมาย .... มุ่งเน้นที่นักพัฒนาของ Microsoft เป็นหลัก

คุณมักถูกตั้งค่าให้ล้มเหลว ยินดีต้อนรับสู่อุตสาหกรรม

ฉันไม่เห็นด้วย - ตราบใดที่เขาสร้างเอกสารสิ่งที่แย่ที่สุดที่สามารถเกิดขึ้นได้คือทุกคนจะถูกลืม

หากคนอื่นมีปัญหากับเนื้อหาคุณสามารถขอให้พวกเขาอัปเดตเนื้อหาเพื่อแสดงสิ่งที่พวกเขาต้องการ ด้วยวิธีนี้มันไม่ได้อยู่ในจานของคุณและคนอื่น ๆ มีความรับผิดชอบในการพิสูจน์การเปลี่ยนแปลงของพวกเขา

ฉันเพิ่งพบEncodo C # Handbookซึ่งรวมถึงความคิดจากแหล่งอื่น ๆ (IDesign, Philips, MSDN)

แหล่งอื่นอาจจะเป็นมืออาชีพ C # / VB .NET Coding แนวทาง

ฉันเป็นแฟนตัวยงของหนังสือ Francesco Balena " แนวทางปฏิบัติและแนวทางปฏิบัติที่ดีที่สุดสำหรับนักพัฒนา VB และ C # "

มันมีรายละเอียดมากและครอบคลุมหัวข้อที่สำคัญทั้งหมดมันไม่เพียง แต่ให้กฎ แต่ยังอธิบายถึงเหตุผลที่อยู่เบื้องหลังกฎและยังให้การต่อต้านกฎซึ่งอาจมีแนวทางปฏิบัติที่ดีที่สุดสองข้อ ข้อเสียเพียงอย่างเดียวคือมันถูกเขียนขึ้นสำหรับนักพัฒนา. NET 1.1

มาตรฐานการเข้ารหัสทั้งหมดของเราอ่านอย่างคร่าว ๆ ว่า "ใช้ StyleCop"

เห็นนี้: http://www.noesispedia.com/post/2008/11/28/C-Coding-Guidelines-and-Best-Practices.aspx

ฉันต้องแนะนำเอกสารdotnetspider.com
มันเป็นเอกสารที่ยอดเยี่ยมและมีรายละเอียดที่มีประโยชน์ทุกที่

ผมเคยใช้ Juval ก่อนและที่ผ่านหากไม่ overkill แต่ฉันขี้เกียจและตอนนี้ก็เป็นไปตามความประสงค์ของResharper

คุณสามารถตรวจสอบนี้ Top 7 มาตรฐานการเข้ารหัสและแนวทางเอกสารสำหรับ C # /. NET นักพัฒนาhttp://www.amazedsaint.com/2010/11/top-6-coding-standards-guideline.html หวังว่านี้จะช่วยให้

ฉันคิดว่าฉันสะท้อนความคิดเห็นอื่น ๆ ที่นี่ว่า MS guidlines ที่เชื่อมโยงแล้วเป็นจุดเริ่มต้นที่ยอดเยี่ยม ฉันจำลองโค้ดของฉันเป็นส่วนใหญ่

ซึ่งน่าสนใจเพราะผู้จัดการของฉันบอกกับฉันในอดีตว่าเขาไม่กระตือรือร้นกับพวกเขามากเกินไป: D

คุณมีงานที่สนุกไปข้างหน้าเพื่อนของฉัน ขอให้โชคดีและขอให้คุณต้องการอะไรอีก :)

มาตรฐานจาก Philips Medical Systems ได้รับการเขียนเป็นอย่างดีและส่วนใหญ่เป็นไปตามแนวทางของ Microsoft: www.tiobe.com/content/paperinfo/gemrcsharpcs.pdf

มาตรฐานของฉันใช้สิ่งนี้ด้วยการปรับแต่งเล็กน้อยและอัพเดตบางอย่างสำหรับ. NET 2.0 (มาตรฐานฟิลิปส์เขียนขึ้นสำหรับ. NET 1.x ดังนั้นจึงล้าสมัยเล็กน้อย)

ฉันยังติดตาม Resharper ด้วย นอกจากนี้แนวทางดังกล่าวต่อ Scott Guthrie บล็อก 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

ในรหัสฉันเขียนฉันมักจะทำตาม.NET Framework แนวทางการออกแบบสำหรับ API เปิดเผยต่อสาธารณะและโมโน Coding แนวทางสำหรับสมาชิกปลอกส่วนตัวและเยื้อง 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");
}

สิ่งที่คุณอาจพบว่าแปลกในแนวทางเดียวคือใช้แท็บ 8 ช่องว่าง อย่างไรก็ตามหลังจากการฝึกฝนฉันพบว่าจริง ๆ แล้วมันช่วยฉันในการเขียนโค้ดที่ยุ่งเหยิงน้อยลงด้วยการบังคับใช้การ จำกัด การเยื้อง

ฉันชอบวิธีที่พวกเขาวางช่องว่างก่อนเปิดวงเล็บ

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

แต่โปรดอย่าบังคับอะไรเช่นนั้นถ้าเพื่อนร่วมงานของคุณไม่ชอบมัน (เว้นแต่คุณจะเต็มใจช่วยเหลือโมโน ;-)