Đề xuất tiêu chuẩn mã hóa .NET / C #? [đóng cửa]

Những tiêu chuẩn mã hóa nào bạn nghĩ là quan trọng cho các dự án .NET / C #? Đây có thể là bất cứ điều gì từ việc đối phó với niềng răng xoăn và khoảng cách và phương pháp sư phạm như thế. Hoặc có thể là những câu hỏi cơ bản hơn như không gian tên nào trong .NET Framework để tránh, cách thực hành tốt nhất với các tệp cấu hình, v.v.

Cố gắng tránh tạo một bài đăng đơn giản là hệ quả của người khác. Ví dụ, sẽ rất ổn nếu có một bài đăng tập trung vào dấu ngoặc nhọn. Chúng tôi không cần hai để hỗ trợ một phong cách so với phong cách khác. Ý tưởng không phải là bỏ phiếu cho tiêu chuẩn thú cưng của bạn, mà là để xác định những gì nên nghĩ về khi tạo ra các tiêu chuẩn.

Dưới đây là Hướng dẫn chính thức của Microsoft về các tiêu chuẩn mã hóa cho .NET framework Phiên bản 4.0.

Nếu bạn muốn phiên bản cũ hơn cho 1.1, hãy thử ở đây .

Tôi không nhất thiết phải làm theo điều này đến một chữ 'T', như họ nói. Tuy nhiên, khi nghi ngờ, đây là nơi tốt nhất để bắt đầu phù hợp với khung .NET hiện tại, giúp mọi người dễ dàng hơn, bất kể họ có mới với dự án cụ thể của bạn hay không.

Có thể muốn xem qua StyleCop . Bạn thậm chí có thể kết hợp nó vào một số hệ thống xây dựng để các lỗi kiểu sẽ phá vỡ bản dựng. Các cài đặt mặc định hầu hết phù hợp với những gì MS gợi ý cho các hướng dẫn (như được đăng bởi những người khác).

Bạn cũng có thể thay đổi các quy tắc mà nó đi kèm theo mặc định.

Nguyên tắc từ Microsoft:

• .NET - http://msdn.microsoft.com/en-us/l Library / csefa0ke.aspx
• C # - http://bloss.msdn.com/brada/articles/361363.aspx

Chúng tôi đã thông qua điều này trong văn phòng của chúng tôi. Nó được viết bởi Lance Hunt, và nó khá toàn diện:

http://weblogs.asp.net/lhunt/pages/CSharp-Coding-St Chuẩns-document.aspx

Bắt đầu với FxCop . Nó sẽ cho bạn biết về các vi phạm thực tiễn tốt nhất trong mã hiện tại của bạn.

Tôi cố gắng chọn một bộ phong cách chung từ nhiều nguồn khác nhau. Một số điều chưa được đề cập trước đây:

• tài liệu từ Nguyên tắc mã hóa C # - cập nhật lần cuối năm 2010
• Tiêu chuẩn mã hóa IDesign C # - cập nhật lần cuối năm 2008
• Philips Health - Tiêu chuẩn mã hóa C # - cập nhật lần cuối năm 2009
• Cẩm nang Encodo C # - cập nhật lần cuối năm 2009

Tôi phải giới thiệu các tiêu chuẩn được cung cấp bởi SSW (một công ty tư vấn Úc).

Không chỉ mã hóa, mà Quản lý dự án, v.v ... Một nguồn tài nguyên vô cùng quý giá.

http://www.ssw.com.au/ssw/stiterias/default.aspx

Phương pháp nên ngắn gọn

Hầu hết các phương thức nên sử dụng hầu hết các trường trong một lớp.

Chọn tên của bạn tốt.

Ví dụ như đọc Mã sạch cuốn sách

Tôi đang sử dụng các ứng dụng sau để duy trì tiêu chuẩn mã hóa bên cạnh các quy tắc lạc đà, tên phương thức, v.v.

GhostDoc - Thêm một nhận xét được tạo tự động trên đầu mỗi phương thức. Ứng dụng này cung cấp tóm tắt tốt về phương pháp. (miễn phí)

http://submain.com/products/ghostdoc.aspx

Chia sẻ lại - phân tích mã và tái cấu trúc http://www.jetbrains.com/resharper/

StyleCop - Là lần dọn dẹp cuối cùng trước khi tôi đăng ký TFS. (miễn phí)

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

Tôi ghét các tiêu chuẩn mã hóa được thiết lập, tất cả họ đều quan tâm đến việc bảo bạn đừng phạm một vài lỗi ngớ ngẩn, hoặc nói cho bạn biết cách định dạng mã theo cách này hay cách khác. Tất cả đều là tầm thường.

Ý tôi là, họ sẽ cho bạn biết có bao nhiêu khoảng trống để đặt giữa các toán tử, cách xử lý các biến của bạn, sử dụng tiền tố 'kiểu kiểu' nào (ví dụ _ cho các thành viên), lời khuyên mâu thuẫn (ví dụ: bạn không thể gọi một lớp Cxyz nhưng bạn phải gọi một giao diện Ixyz), cách bố trí mã của bạn (đặt biến của bạn ở đầu lớp hoặc ở dưới cùng)

Tất cả đều vô dụng trong bức tranh lớn.

Những gì quan trọng để viết mã hiệu quả, có thể duy trì và có thể đọc được không bao giờ được đề cập trong các tiêu chuẩn này.

Ví dụ: bạn đặt các biến của bạn ở đầu hoặc cuối lớp? Chà, ai quan tâm - vấn đề là gì nếu bạn nhóm các biến của mình lại với nhau theo khu vực chức năng. Đó là vấn đề (bạn sẽ biết điều này nếu bạn từng thấy 20 biến rải rác về địa điểm).

Họ nói với bạn để đặt dấu ngoặc nhọn của bạn ở những nơi nhất định. Thỏa thuận lớn! Tôi có thể đọc mã trong cả hai kiểu khung K & R và ANSI, điều đó không thành vấn đề. Vấn đề là nếu tất cả các lớp Window được phân biệt bằng cách nào đó (như được thêm vào với Form hoặc Dlg hoặc bất cứ thứ gì) để bạn có thể xem tệp nào chứa mã cửa sổ và đối tượng bình thường.

Những thứ như thế này quan trọng hơn nhiều so với những điểm nhỏ mà tiêu chuẩn thường có. Tôi không biết tại sao họ lại phát triển như thế này, nhưng thường thì họ chỉ là một tấn quy tắc cản trở việc mã hóa hiệu quả, hiệu quả.

Các tiêu chuẩn của tôi cố gắng tập trung nhiều hơn vào tổ chức mã và tệp. Chúng tôi có các tiêu chuẩn nhất định đề cập đến nơi các tập tin sẽ được tìm thấy. Ví dụ, đối với những người không phải là nhà phát triển có thể xem một trong các dự án của chúng tôi và ngay lập tức lấy các tệp tài liệu họ cần. Tương tự, chúng tôi cố gắng bố trí mã dự án theo cách tương tự như các dự án khác là thực tế (lưu ý: là thực tế, không theo cách bị cấm nhiều có thể không phù hợp mọi lúc) và về cơ bản chúng tôi cố gắng đưa ra các hướng dẫn tiêu chuẩn có thể được sửa đổi khi cần thiết.

Nói tóm lại - họ ở đó để giúp chúng tôi làm việc cùng nhau, không phải là một bộ quy tắc hạn chế luôn phải tuân theo.

Cảnh báo: Chủ nghĩa thực dụng dưới đây - Câu hỏi dường như được đặt ra để gợi ra cuộc tranh luận về phong cách niềng răng "phù hợp", v.v. Tôi không bỏ phí thời gian cho điều vô lý đó.

1. Cài đặt ReSharper , để mặc định, làm bất cứ điều gì nó nói.

2. Lợi nhuận - Mọi người trong nhóm của bạn sẽ có cùng một phong cách gần với hướng dẫn của Microsoft, chỉ sai lệch ở một vài điểm trong đó các tiêu chuẩn Resharper phản ánh những gì thực sự được sử dụng rộng rãi hơn trong công nghiệp và được cho là cải tiến.

Càng ít thời gian nhóm của bạn dành cho việc tạo và tham khảo một số tài liệu hoặc cuốn sách hài hước, hoặc tinh ranh về những điều không curly braceshay khác, họ sẽ càng mã hóa nhiều hơn. ReSharper sẽ thực thi đặt tên và kiểu khi họ gõ. Làm xong. Kết thúc cuộc tranh luận. Không còn gì để tranh cãi. Tiến lên.

Điều đó nói rằng, việc đọc Mã hoàn chỉnh cổ điển , sẽ giúp họ hiểu lý do căn bản đằng sau các tiêu chuẩn mã hóa và đưa ra nhiều gợi ý tuyệt vời về việc truyền đạt ý nghĩa thông qua mã - điều mà một tài liệu tiêu chuẩn hoặc chương trình kiểm tra không thể làm được.

Nếu bạn muốn cải tiến những gì mà trình chia sẻ lại có thể làm cho bạn, hãy thêm StyleCop với bổ trợ StyleCop cho ReSharper. Như đã đề cập, sẽ có một vài xung đột nhỏ giữa hướng dẫn của MS và mặc định của ReSharper. Tôi sẽ chỉ đi với ReSharper trên những. Nhưng bất cứ bên nào bạn thực hiện chỉ cần lưu kết quả vào tệp cấu hình ReSharper, chia sẻ nó trên nhóm của bạn và được thực hiện.

(Không, tôi không phải là người thích trả tiền cho ReSharper, chỉ là một khách hàng hài lòng. Ngoài nhiều tính năng khác, nó xử lý các vấn đề về phong cách cơ bản hiệu quả hơn bất kỳ tài liệu tiêu chuẩn hoặc hệ thống đánh giá mã nào - để lại năng lực cho những vấn đề quan trọng .)