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

Question

Tôi là một sinh viên 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ó đã rơi vào tôi (chủ yếu là tôi là người đầu tiên 'chấp nhận' trong bộ phận) để tạo ra một tài liệu tiêu chuẩn C# mã hóa cơ bản (đọc hữu ích?).

Tôi nghĩ tôi nên giải thích rằng tôi có lẽ là kỹ sư phần mềm cơ sở nhất, nhưng tôi mong chờ nhiệm vụ này vì hy vọng tôi có thể sản xuất được một nửa có thể sử dụng được. Tôi đã thực hiện tìm kiếm khá rộng rãi trên Internet và đọc các bài viết về 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 cánh cửa cho cả một thế giới bất đồng về 'cách tốt nhất để làm việc'. Tôi hiểu và tôn trọng 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 thích hợp để giải quyết từng công việc riêng lẻ, kết quả là tôi không tìm cách viết bất cứ điều gì để giải thích về sự tinh tế cá nhân nhưng để thử và nhận đượ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 các cá nhân mã dễ đọc hơn.

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

Answer 1

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

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

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

Answer 2

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.

Answer 3

Tôi luôn sử dụng số điện thoại pdf của Juval Lowy làm tham chiếu 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ó sau rất gần với FxCop/Source Analysis, một công cụ vô giá khác để đảm bảo rằng tiêu chuẩn đang được theo dõi. 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 tốt đẹp mà tất cả các nhà phát triển của bạn sẽ không bận tâm theo dõi và có thể thực thi chúng.

Answer 4

IDesign có tài liệu tiêu chuẩn mã hóa C# thường được sử dụng. Xem thêm Framework Design Guidelines 2nd Ed.

Answer 5

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

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ư chúng nên, và khi chúng đọc chúng, chúng không theo chúng. Khả năng đọc và theo dõi tài liệu như vậy thay đổi ngược chiều dài.

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

Answer 6

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

Đề xuất đầu tiên của tôi là gợi ý các kỹ sư khác về những gì họ cảm thấy cần được đề cập và những hướng dẫn nào họ cảm thấy là quan trọng.Việc thực thi bất kỳ loại nguyên tắc nào yêu cầu mức độ mua vào từ mọi người. Nếu bạn đột nhiên thả một tài liệu trên đó chỉ định làm thế nào để viết mã bạn sẽ gặp phải kháng chiến, cho dù bạn là người đàn ông cao cấp nhất hoặc cao cấp.

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

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

Cũng đáng xem xét việc 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ư một sự 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 mash-mash của các phong cách khác nhau. Nó cũng để lại cho mọi người trong tình thế tiến thoái lưỡng nan cho dù mã trong một mô-đun nhất định phải phù hợp với tiêu chuẩn mới hay tuân theo kiểu mã hiện có.

Answer 7

Tôi nghĩ rằng tôi lặp lại các nhận xét 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 phần lớn vào những người.

Đó là thú vị bởi vì quản lý của tôi đã nói với tôi trong quá khứ mà ông không phải là quá quan tâm về họ: D

Bạn có một nhiệm vụ vui vẻ trước bạn bè của tôi. Chúc bạn may mắn và hãy hỏi xem bạn có cần thêm gì không :)

Answer 8

Bạn có nhiều khả năng sẽ bị thất bại. Chào mừng đến với ngành.

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

Nếu người khác gặp sự cố với nội dung, bạn có thể yêu cầu họ cập nhật nội dung để hiển thị nội dung họ muốn. 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ọ.

Answer 9

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 mã hóa của MS (hoặc các mặt trời) hoặc ... phù hợp với ngôn ngữ của bạn). Các đầu mối là trong tiêu chuẩn từ, thế giới sẽ là một nơi dễ dàng hơn nhiều để mã trong nếu mỗi tổ chức đã không quyết định viết riêng của họ. Ai thực sự nghĩ rằng học một tập hợp mới của 'tiêu chuẩn' mỗi khi bạn thay đổi đội/dự án/vai trò là một sử dụng tốt thời gian của bất cứ ai. Điều quan trọng nhất bạn nên làm là tóm tắt các điểm quan trọng nhưng tôi khuyên bạn không nên làm ngay cả điều đó bởi vì điều gì là quan trọng thay đổi từ người này sang người khác. 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 đủ để thay đổi mã tuân theo tiêu chuẩn mã hóa là 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ộ', tức 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.

Answer 10

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

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

Answer 11

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

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

Cuối cùng nó sẽ có một lựa chọn cấu trúc lại để mã ngẫu nhiên.

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

Answer 12

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

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

Đó là giá trị kiểm tra ra;)

Answer 13

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

Một nguồn khác có thể là Professional C#/VB .NET Coding Guidelines.

Answer 14

Tôi thấy tài liệu sau rất hữu ích và súc tích. Nó xuất phát từ trang web idesign.net và nó là tác giả của Juval Lowy

C# Coding Standard

NB: liên kết ở trên bây giờ đã chết. Để lấy 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 địa chỉ này để tiếp thị ... trung thực) Hãy thử here

Answer 15

Tôi là một người hâm mộ lớn của cuốn sách Francesco Balena "Practical Guidelines and Best Practices for VB and C# Developers".

Nó rất chi tiết và bao gồm tất cả các chủ đề cần thiết, 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 quy tắc chống nơi 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.

Answer 16

Xem nội dung này: http://www.noesispedia.com/post/2008/11/28/C-Coding-Guidelines-and-Best-Practices.aspx.

Answer 17

Tôi vừa mới bắt đầu tại một nơi mà các tiêu chuẩn mã hóa ủy quyền sử dụng m_ cho biến thành viên, p_ cho 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ó nội dung như thế này trong phần thân của phương thức:

m_strName = p_strName;

Rất tệ. Thực sự khủng khiếp.

Answer 18

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

Lỗi khó hiểu tại công ty của tôi là sử dụng tất cả các ngôn ngữ khác nhau. Và tôi biết công ty của tôi không đơn độc về điều này. Chúng tôi sử dụng C#, C, assembly (chúng tôi tạo ra thiết bị), SQL, XAML, v.v.Mặc dù sẽ có một số điểm tương đồng về tiêu chuẩn, mỗi tiêu chuẩn 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 bắt đầu), 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 so với mã trình bày là gì, vv Đừng hiểu lầm tôi, các tiêu chuẩn mức thấp cũng là cần thiết (định dạng là quan trọng để dễ đọc!) Tôi chỉ có một sự thiên vị đối với 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 rất tuyệt. 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 họ thì tất cả đều vô ích.

Answer 19

Toàn bộ chuẩn mã hóa của chúng tôi đọc gần như "Sử dụng StyleCop".

Answer 20

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

Answer 21

Tôi đã sử dụng của Juval trước đó và đó là thông qua nếu không overkill, nhưng tôi lười biếng và bây giờ chỉ phù hợp với ý chí của Resharper.

Answer 22

Tôi cũng theo dõi Resharper. Cũng hướng dẫn đường được đề cập trên blog của Scott Guthrie http://weblogs.asp.net/scottgu/archive/2007/10/08/october-8th-links-asp-net-asp-net-ajax-silverlight-and-net.aspx Và http://csharpguidelines.codeplex.com/releases/view/46280

Answer 23

Trong đoạn code tôi viết tôi thường làm theo .NET Framework Design Guidelines cho API tiếp xúc công khai và Mono Coding Guidelines cho vỏ thành viên tư nhân và thụt đầu dòng. Mono là một triển khai mã nguồn mở của .NET, và tôi nghĩ những kẻ đó biết công việc kinh doanh của họ.

Tôi ghét cách Microsoft chất thải đang 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"); 
} 

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

Tôi cũng thích cách họ đặ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 ;-)

Answer 24

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

Answer 25

Như tôi đã viết cả hai được xuất bản cho Hệ thống Y tế Philips và một trên http://csharpguidelines.codeplex.com Tôi có thể hơi thiên vị, nhưng tôi có hơn 10 năm viết, bảo trì và quảng bá các tiêu chuẩn mã hóa. Tôi đã cố gắng viết một CodePlex với sự khác biệt trong ý kiến ​​trong tâm trí và dành phần lớ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 với thông tin phản hồi .....

Answer 26

SSW Rules

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