Có bất kỳ đề xuất nào để phát triển một tài liệu tiêu chuẩn / thực hành tốt nhất về mã hóa C # không? [đóng cửa]

Tôi mới tốt nghiệp AI gần đây (khoảng 2 năm) làm việc cho một hoạt động khiêm tốn. Nó đã thuộc về tôi (chủ yếu là tôi là 'người áp dụng' đầu tiên trong bộ phận) để tạo ra một tài liệu tiêu chuẩn mã hóa C # cơ bản (đọc có hữu ích không?).

Tôi nghĩ tôi nên giải thích rằng có lẽ tôi là kỹ sư phần mềm cơ sở nhất, nhưng tôi đang mong đợi nhiệm vụ này vì hy vọng tôi thực sự có thể tạo ra thứ gì đó có thể sử dụng được một nửa. Tôi đã thực hiện một tìm kiếm khá rộng rãi trên Internet và đọc các bài viết về những gì một tài liệu tiêu chuẩn mã hóa nên / không nên chứa. Điều này có vẻ như là một nơi tốt như bất kỳ để yêu cầu một số gợi ý.

Tôi nhận ra rằng tôi có khả năng mở ra một cánh cửa cho cả một thế giới bất đồng về 'cách tốt nhất để làm mọi việc'. Tôi đều hiểu và tôn trọng một thực tế không thể phủ nhận rằng mỗi lập trình viên có một phương pháp giải quyết từng nhiệm vụ riêng biệt, kết quả là tôi không muốn viết bất cứ điều gì có tính thuyết phục đến mức để bóp nghẹt sự tinh tế của cá nhân mà chỉ để thử và có được một phương pháp chung và đồng ý các tiêu chuẩn (ví dụ: quy ước đặt tên) để giúp làm cho mã cá nhân dễ đọc hơn.

Vì vậy, ở đây đi .... bất kỳ đề nghị? Bất kỳ ở tất cả?

Chúng tôi bắt đầu với

• Hướng dẫn .NET của Microsoft: http://msdn.microsoft.com/en-us/l Library / ms229042.aspx (liên kết được cập nhật cho .NET 4.5)
• Hướng dẫn sử dụng C # của Microsoft: http://bloss.msdn.com/brada/articles/361363.aspx .

và sau đó ghi lại sự khác biệt từ và bổ sung vào đường cơ sở đó.

IDesign có một tài liệu tiêu chuẩn mã hóa C # thường được sử dụng. Cũng xem Hướng dẫn thiết kế khung thứ 2 Ed .

Trớ trêu thay các tiêu chuẩn thực tế có thể là phần dễ dàng.

Đề nghị đầu tiên của tôi sẽ là gợi ra những gợi ý từ các kỹ sư khác về những gì họ cảm thấy nên được đề cập và những hướng dẫn nào họ cảm thấy quan trọng. Thực thi bất kỳ loại hướng dẫn nào cũng đòi hỏi một mức độ mua từ người dân. Nếu bạn đột nhiên thả một tài liệu về chúng chỉ định cách viết mã bạn sẽ gặp phải sự kháng cự, cho dù bạn là người đàn ông hay đàn em nhất.

Sau khi bạn có một bộ đề xuất, sau đó gửi chúng cho nhóm để phản hồi và xem xét. Một lần nữa, khiến mọi người mua tất cả vào chúng.

Có thể đã có các thực hành mã hóa không chính thức được thông qua (ví dụ: tiền tố biến thành viên, tên hàm camelcase). Nếu điều này tồn tại và hầu hết các mã phù hợp với nó, thì nó sẽ trả tiền để chính thức hóa việc sử dụng nó. Việc chấp nhận một tiêu chuẩn trái ngược sẽ gây ra nhiều đau buồn hơn giá trị của nó, ngay cả khi đó là điều thường được khuyến nghị.

Cũng đáng xem xét tái cấu trúc mã hiện có để đáp ứng các tiêu chuẩn mã hóa mới. Điều này có vẻ như lãng phí thời gian, nhưng có mã không đáp ứng các tiêu chuẩn có thể phản tác dụng vì bạn sẽ có một mớ hỗn độn của các phong cách khác nhau. Nó cũng khiến mọi người rơi vào tình huống khó xử cho dù mã trong một mô-đun nhất định phải tuân theo tiêu chuẩn mới hoặc tuân theo kiểu mã hiện có.

Tôi đã luôn sử dụng pdf của Juval Low làm tài liệu tham khảo khi thực hiện các tiêu chuẩn mã hóa / thực tiễn tốt nhất trong nội bộ. Nó rất gần với Phân tích Nguồn / FxCop , một công cụ vô giá khác để đảm bảo rằng tiêu chuẩn đang được tuân theo. Giữa các công cụ và tài liệu tham khảo này, bạn sẽ có thể đưa ra một tiêu chuẩn đẹp mà tất cả các nhà phát triển của bạn sẽ không tuân theo và có thể thực thi chúng.

Các áp phích khác đã chỉ cho bạn về đường cơ sở, tất cả những gì tôi muốn nói là làm cho tài liệu của bạn ngắn gọn, ngọt ngào và đến mức, sử dụng một liều nặng của Strunk và White để phân biệt "phải có" từ "nó sẽ rất tuyệt nếu ".

Vấn đề với các tài liệu tiêu chuẩn mã hóa là không ai thực sự đọc chúng như họ nên và khi họ đọc chúng, họ không tuân theo chúng. Khả năng của một tài liệu như vậy được đọc và theo dõi thay đổi ngược với độ dài của nó.

Tôi đồng ý FxCop là một công cụ tốt nhưng quá nhiều thứ này có thể mang lại tất cả những điều thú vị ngay lập tức, vì vậy hãy cẩn thận.

Không bao giờ viết các tiêu chuẩn mã hóa của riêng bạn sử dụng các tiêu chuẩn MS (hoặc Mặt trời hoặc ... phù hợp với ngôn ngữ của bạn). Manh mối nằm trong tiêu chuẩn từ, thế giới sẽ là nơi dễ mã hóa hơn nhiều nếu mỗi tổ chức không quyết định tự viết. Ai thực sự nghĩ rằng việc học một bộ 'tiêu chuẩn' mới mỗi khi bạn thay đổi nhóm / dự án / vai trò là cách sử dụng tốt thời gian của bất kỳ ai. Việc bạn nên làm nhất là tóm tắt những điểm quan trọng nhưng tôi khuyên bạn không nên làm điều đó bởi vì điều quan trọng khác nhau ở mỗi người. Hai điểm khác tôi muốn thực hiện trên các tiêu chuẩn mã hóa

1. Đóng là đủ tốt - Thay đổi mã để tuân theo các tiêu chuẩn mã hóa thành chữ cái là một sự lãng phí thời gian miễn là mã đó đủ gần.
2. Nếu bạn đang thay đổi mã, bạn đã không viết theo 'tiêu chuẩn mã hóa cục bộ', nghĩa là làm cho mã mới của bạn trông giống như mã xung quanh.

Hai điểm này là thực tế với mong muốn của tôi rằng mọi người sẽ viết mã trông giống nhau.

Tôi tìm thấy các tài liệu sau đây rất hữu ích và súc tích. Nó xuất phát từ trang web idesign.net và nó được tác giả bởi Juval Lowy

Tiêu chuẩn mã hóa C #

NB: liên kết trên bây giờ đã chết. Để có được tệp .zip, bạn cần cung cấp cho họ địa chỉ email của bạn (nhưng họ sẽ không sử dụng nó để tiếp thị ... một cách trung thực) Hãy thử tại đây

Tôi mới chỉ bắt đầu ở một nơi mà các tiêu chuẩn mã hóa bắt buộc sử dụng m_ cho các biến thành viên, p_ cho các tham số và tiền tố cho các loại, chẳng hạn như 'str' cho chuỗi. Vì vậy, bạn có thể có một cái gì đó như thế này trong cơ thể của một phương thức:

m_strName = p_strName;

Kinh khủng. Thật kinh khủng.

Tôi sẽ thêm Code Complete 2 vào danh sách (Tôi biết Jeff là một người hâm mộ ở đây) ... Nếu bạn là một nhà phát triển cơ sở, cuốn sách có ích để thiết lập tâm trí của bạn theo cách đặt nền tảng tốt nhất thực hành viết mã và xây dựng phần mềm có.

Tôi phải nói rằng tôi đến với nó một chút muộn trong sự nghiệp của mình, nhưng nó quy định rất nhiều cách tôi nghĩ về mã hóa và phát triển khung trong cuộc sống chuyên nghiệp của tôi.

Thật đáng để kiểm tra;)

Các quy tắc riêng của Microsoft là một điểm khởi đầu tuyệt vời. Bạn có thể thực thi chúng với FxCop.

Tôi sẽ cố gắng thực thi StyleCop của Microsoft làm tiêu chuẩn. Nó có thể được thi hành tại thời điểm xây dựng. nhưng nếu bạn có mã kế thừa thì chỉ cần thực thi bằng StyleCop trên mã mới.

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

Cuối cùng, nó sẽ có một tùy chọn cấu trúc lại để dọn mã.

http://bloss.msdn.com/sourceanalysis/

Cá nhân tôi thích cái mà IDesign đã đặt cùng nhau. Nhưng đó không phải là lý do tại sao tôi đăng ...

Một chút khó khăn tại công ty của tôi là đưa tất cả các ngôn ngữ khác nhau vào tài khoản. Và tôi biết công ty của tôi không đơn độc trong việc này. Chúng tôi sử dụng C #, C, lắp ráp (chúng tôi tạo ra các thiết bị), SQL, XAML, v.v. Mặc dù sẽ có một số điểm tương đồng trong các tiêu chuẩn, mỗi loại thường được xử lý khác nhau.

Ngoài ra, tôi tin rằng các tiêu chuẩn cấp cao hơn có tác động lớn hơn đến chất lượng của sản phẩm cuối cùng. Ví dụ: cách thức và thời điểm sử dụng nhận xét, khi ngoại lệ là bắt buộc (ví dụ: sự kiện do người dùng khởi tạo), cho dù (hoặc khi nào) sử dụng ngoại lệ so với giá trị trả về, cách khách quan để xác định mã điều khiển nên so với mã trình bày là gì, v.v. Đừng hiểu sai ý tôi, các tiêu chuẩn cấp thấp cũng rất cần thiết (định dạng rất quan trọng đối với khả năng đọc!) Tôi chỉ thiên về cấu trúc tổng thể.

Một phần khác cần ghi nhớ là mua và thực thi. Tiêu chuẩn mã hóa là tuyệt vời. Nhưng nếu không ai đồng ý với họ và (có lẽ quan trọng hơn) không ai thi hành chúng thì tất cả chỉ vì vô ích.

Khi tôi viết cả hai bản được xuất bản cho Philips Medical Systems và một trên http://csharpguferences.codeplex.com tôi có thể hơi thiên vị, nhưng tôi đã có hơn 10 năm để viết, duy trì và thúc đẩy các tiêu chuẩn mã hóa. Tôi đã cố gắng viết một CodePlex với những ý kiến ​​khác nhau và dành phần lớn phần giới thiệu về cách đối phó với điều đó trong tổ chức cụ thể của bạn. Đọc nó và cung cấp cho tôi thông tin phản hồi .....

Quy tắc SSW

Nó bao gồm một số tiêu chuẩn C # + nhiều hơn nữa .... chủ yếu tập trung vào các nhà phát triển của Microsoft

Bạn rất có thể được thiết lập để thất bại. Chào mừng đến với ngành công nghiệp.

Tôi không đồng ý - miễn là anh ta tạo ra tài liệu, điều tồi tệ nhất có thể xảy ra là nó bị mọi người lãng quên.

Nếu người khác có vấn đề với nội dung, thì bạn có thể yêu cầu họ cập nhật nội dung đó để hiển thị những gì họ thích. Bằng cách đó, nó ra khỏi đĩa của bạn và những người khác có trách nhiệm biện minh cho những thay đổi của họ.

Gần đây tôi đã tìm thấy Cẩm nang Encodo C # , bao gồm các ý tưởng từ nhiều nguồn khác (IDesign, Philips, MSDN).

Một nguồn khác có thể là Nguyên tắc mã hóa C # / VB .NET chuyên nghiệp .

Tôi là một fan hâm mộ lớn của cuốn sách Francesco Balena " Nguyên tắc thực hành và thực tiễn tốt nhất cho các nhà phát triển VB và C # ".

Nó rất chi tiết và bao gồm tất cả các chủ đề thiết yếu, Nó không chỉ cung cấp cho bạn quy tắc, mà còn giải thích lý do đằng sau quy tắc, và thậm chí cung cấp một quy tắc chống lại việc có thể có hai thực tiễn tốt nhất đối lập. Nhược điểm duy nhất là nó được viết cho các nhà phát triển .NET 1.1.

Toàn bộ tiêu chuẩn mã hóa của chúng tôi đọc đại khái, "Sử dụng StyleCop."

Xem điều này: http://www.noesispedia.com/post/2008/11/11/C-Coding-Guiances-and-Best-Practices.aspx .

Tôi phải đề xuất tài liệu dotnetspider.com .
Đó là một tài liệu tuyệt vời và chi tiết hữu ích ở bất cứ đâu.

Tôi đã sử dụng Juval trước đây và điều đó thông qua nếu không quá mức, nhưng tôi lười biếng và bây giờ chỉ tuân theo ý muốn của Resharper .

Bạn có thể kiểm tra điều này, 7 tài liệu hướng dẫn và tiêu chuẩn mã hóa hàng đầu cho các nhà phát triển C # /. NET http://www.amazedsaint.com/2010/11/top-6-coding-stiterias-guideline.html hy vọng điều này sẽ giúp

Tôi nghĩ rằng tôi lặp lại các ý kiến ​​khác ở đây rằng các hướng dẫn MS đã được liên kết là một điểm khởi đầu tuyệt vời. Tôi mô hình mã của tôi chủ yếu vào những người đó.

Điều này thật thú vị bởi vì người quản lý của tôi đã nói với tôi trong quá khứ rằng anh ấy không quá quan tâm đến họ: D

Bạn có một nhiệm vụ thú vị trước bạn của tôi. Tốt nhất của may mắn, và xin hỏi nếu bạn cần thêm gì nữa :)

Tiêu chuẩn từ Philips Medical Systems được viết tốt và chủ yếu tuân theo các nguyên tắc của Microsoft: www.tiobe.com/content/apersinfo/gemrcsharpcs.pdf

Các tiêu chuẩn của tôi dựa trên điều này với một vài điều chỉnh và một số cập nhật cho .NET 2.0 (tiêu chuẩn Philips được viết cho .NET 1.x nên có một chút ngày tháng).

Tôi cũng theo dõi Resharper. Ngoài ra, dòng hướng dẫn được đề cập trên blog scott guthrie http://weblogs.asp.net/scottgu/archive/2007/10/08/oc/10-8th-links-asp-net-asp-net-ajax-silverlight-and-net .aspx Và http://csharpguferences.codeplex.com/release/view/46280

Trong mã tôi viết, tôi thường tuân theo Nguyên tắc thiết kế .NET Framework cho các API được hiển thị công khai và Nguyên tắc mã hóa đơn sắc cho vỏ và thành viên riêng tư . Mono là một triển khai mã nguồn mở của .NET và tôi nghĩ những người đó biết doanh nghiệp của họ.

Tôi ghét cách mã Microsoft lãng phí không gian:

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

Điều bạn có thể thấy lạ trong hướng dẫn của Mono, là họ sử dụng các tab 8 không gian. Tuy nhiên, sau một số thực hành, tôi thấy rằng nó thực sự giúp tôi viết mã ít bị rối hơn bằng cách thực thi một loại giới hạn thụt lề.

Tôi cũng thích cách họ đặt một khoảng trắng trước khi mở dấu ngoặc đơn.

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

Nhưng làm ơn, đừng thi hành bất cứ điều gì như thế nếu đồng nghiệp của bạn không thích nó (trừ khi bạn sẵn sàng đóng góp cho Mono ;-)