Thứ tự các mục trong các lớp: Trường, Thuộc tính, Trình xây dựng, Phương thức

Có hướng dẫn chính thức về C # cho thứ tự các mặt hàng theo cấu trúc lớp không?

Nó có đi không

• Lĩnh vực công cộng
• Lĩnh vực tư nhân
• Tính chất
• Người xây dựng
• Phương pháp
  nào?

Tôi tò mò liệu có một quy tắc cứng và nhanh về thứ tự của các mặt hàng không? Tôi là loại ở khắp mọi nơi. Tôi muốn gắn bó với một tiêu chuẩn cụ thể để tôi có thể làm điều đó ở mọi nơi.

Vấn đề thực sự là các thuộc tính phức tạp hơn của tôi cuối cùng trông rất giống các phương thức và chúng cảm thấy lạc lõng ở phía trên trước khi xây dựng.

Bất kỳ lời khuyên / đề nghị?

Theo Tài liệu quy tắc StyleCop, việc đặt hàng như sau.

Trong một lớp, cấu trúc hoặc giao diện: (SA1201 và SA1203)

• Trường không đổi
• Lĩnh vực
• Người xây dựng
• Người hoàn thiện (Kẻ hủy diệt)
• Đại biểu
• Sự kiện
• Enums
• Giao diện ( triển khai giao diện )
• Tính chất
• Người lập chỉ mục
• Phương pháp
• Cấu trúc
• Các lớp học

Trong mỗi nhóm này, thứ tự truy cập: (SA1202)

• công cộng
• nội bộ
• bảo vệ nội bộ
• bảo vệ
• riêng tư

Trong mỗi nhóm truy cập, sắp xếp theo thứ tự tĩnh, sau đó không tĩnh: (SA1204)

• tĩnh
• không tĩnh

Trong mỗi nhóm trường tĩnh / không tĩnh, sắp xếp theo thứ tự chỉ đọc, sau đó không chỉ đọc: (SA1214 và SA1215)

• chỉ đọc
• không đọc

Một danh sách không được kiểm soát dài 130 dòng, vì vậy tôi sẽ không hủy đăng ký ở đây. Các phương thức không được kiểm soát là:

• phương pháp tĩnh công cộng
• phương pháp công cộng
• phương pháp tĩnh bên trong
• phương pháp nội bộ
• phương pháp tĩnh bên trong được bảo vệ
• phương pháp nội bộ được bảo vệ
• phương pháp tĩnh được bảo vệ
• phương pháp bảo vệ
• phương pháp tĩnh riêng
• phương pháp riêng tư

Tài liệu lưu ý rằng nếu thứ tự quy định không phù hợp - giả sử, nhiều giao diện đang được triển khai và các phương thức và thuộc tính giao diện nên được nhóm lại với nhau - sau đó sử dụng một lớp một phần để nhóm các phương thức và thuộc tính liên quan lại với nhau.

Thay vì nhóm theo khả năng hiển thị hoặc theo loại mặt hàng (trường, thuộc tính, phương thức, v.v.), làm thế nào về nhóm theo chức năng?

Đây là một câu hỏi cũ nhưng vẫn rất phù hợp, vì vậy tôi sẽ thêm câu hỏi này: Điều đầu tiên bạn tìm kiếm khi mở tệp lớp mà bạn có thể hoặc chưa từng đọc trước đây là gì? Lĩnh vực? Tính chất? Tôi đã nhận ra từ kinh nghiệm rằng hầu như tôi luôn đi săn các nhà xây dựng, bởi vì điều cơ bản nhất để hiểu là cách vật thể này được xây dựng.

Do đó, tôi đã bắt đầu đặt các nhà xây dựng lên hàng đầu trong các tệp lớp và kết quả rất tốt về mặt tâm lý. Các khuyến nghị tiêu chuẩn của việc đặt các nhà xây dựng sau một loạt các điều khác cảm thấy không phù hợp.

Tính năng hàm tạo chính sắp tới trong C # 6 cung cấp bằng chứng cho thấy vị trí tự nhiên của hàm tạo nằm ở trên cùng của lớp - trên thực tế các hàm tạo chính được chỉ định ngay cả trước dấu ngoặc mở.

Thật buồn cười khi một sự khác biệt sắp xếp lại như thế này. Nó nhắc nhở tôi về cách các usingcâu lệnh được sử dụng để sắp xếp thứ tự - với không gian tên Hệ thống trước tiên. Lệnh "Organize Usings" của Visual Studio đã sử dụng thứ tự này. Bây giờ usings chỉ được sắp xếp theo thứ tự abc, không có xử lý đặc biệt cho không gian tên hệ thống. Kết quả chỉ cảm thấy đơn giản và sạch sẽ hơn.

Tôi không biết về ngôn ngữ hoặc tiêu chuẩn ngành, nhưng tôi có xu hướng sắp xếp mọi thứ theo thứ tự này với mỗi phần được gói trong một #region:

sử dụng Tuyên bố

Không gian tên

Lớp học

Thành viên tư nhân

Tài sản công cộng

Người xây dựng

Phương pháp công cộng

Phương pháp riêng tư

Tôi sẽ khuyên bạn nên sử dụng các tiêu chuẩn mã hóa từ IDesign hoặc các tiêu chuẩn được liệt kê trên trang web của Brad Abram . Đó là hai cái tốt nhất mà tôi đã tìm thấy.

Brad sẽ nói ...

Thành viên của lớp nên được sắp xếp theo thứ tự và được nhóm thành các phần (Trường, Trình xây dựng, Thuộc tính, Sự kiện, Phương thức, Triển khai giao diện riêng, Các kiểu lồng nhau)

Như đã đề cập trước đây, không có gì trong ngôn ngữ C # chỉ ra bố cục, cá nhân tôi sử dụng các vùng và tôi làm một cái gì đó như thế này cho một lớp trung bình.

public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

Dù sao nó cũng có ý nghĩa với tôi

Từ StyleCop

lĩnh vực riêng tư, lĩnh vực công cộng, nhà xây dựng, thuộc tính, phương thức công cộng, phương thức riêng tư

Vì StyleCop là một phần của quy trình xây dựng MS, bạn có thể xem đó là một tiêu chuẩn thực tế

Thông thường tôi cố gắng làm theo mô hình tiếp theo:

• thành viên tĩnh (thường có bối cảnh khác, phải an toàn cho chuỗi, v.v.)
• thành viên thể hiện

Mỗi phần (tĩnh và thể hiện) bao gồm các loại thành viên sau:

• toán tử (luôn luôn tĩnh)
• các trường (khởi tạo trước khi xây dựng)
• nhà xây dựng
• hàm hủy ( là một truyền thống để theo các nhà xây dựng )
• tính chất
• phương pháp
• sự kiện

Sau đó, các thành viên được sắp xếp theo mức độ hiển thị (từ ít đến dễ thấy hơn):

• riêng tư
• nội bộ
• bảo vệ nội bộ
• bảo vệ
• công cộng

Thứ tự không phải là một giáo điều: các lớp đơn giản dễ đọc hơn, tuy nhiên, các lớp phức tạp hơn cần nhóm theo ngữ cảnh cụ thể.

Sở thích của tôi là đặt hàng theo loại và sau đó giảm khả năng hiển thị như sau

public methods
public events
public properties

protected methods
protected events
protected properties

private methods
private events
private properties
private fields

public delegates
public interfaces
public classes
public structs

protected delegates
protected interfaces
protected classes
protected structs

private delegates
private interfaces
private classes
private structs

Tôi biết điều này vi phạm Style Cop và nếu ai đó có thể cho tôi một lý do chính đáng tại sao tôi nên đặt chi tiết triển khai của một loại trước giao diện của nó, tôi sẵn sàng thay đổi. Hiện tại, tôi có một ưu tiên mạnh mẽ để đưa các thành viên tư nhân cuối cùng.

Lưu ý: Tôi không sử dụng các lĩnh vực công cộng hoặc được bảo vệ.

Gần nhất bạn có thể tìm thấy là "Nguyên tắc thiết kế, mã được quản lý và .NET Framework" ( http://bloss.msdn.com/brada/articles/361363.aspx ) của Brad Abrams

Nhiều tiêu chuẩn được nêu ra ở đây. Phần liên quan là 2,8 tôi nghĩ.

hướng dẫn mã hóa duy nhất mà tôi thấy được đề xuất cho việc này là đặt các trường ở đầu định nghĩa lớp.

tôi có xu hướng đặt các nhà xây dựng bên cạnh.

Nhận xét chung của tôi là bạn nên bám vào một lớp trên mỗi tệp và nếu lớp đó đủ lớn để tổ chức các thuộc tính so với các phương thức là mối quan tâm lớn, thì lớp đó lớn đến mức nào và bạn có nên tái cấu trúc nó không? nó đại diện cho nhiều mối quan tâm?

Tôi thích đặt các trường riêng lên trên cùng cùng với (các) hàm tạo, sau đó đặt các bit giao diện công cộng sau đó, sau đó là các bit giao diện riêng.

Ngoài ra, nếu định nghĩa lớp của bạn đủ dài để việc sắp xếp các mục trở nên quan trọng, thì đó có lẽ là mùi mã cho thấy lớp của bạn quá cồng kềnh và phức tạp và bạn nên cấu trúc lại.

Tôi giữ nó đơn giản nhất có thể (ít nhất là đối với tôi)

Khai báo
khai báo Trình
xây dựng
ghi đè
phương thức
Thuộc tính Trình xử
lý sự kiện

Chắc chắn không có gì trong ngôn ngữ thực thi nó theo bất kỳ cách nào. Tôi có xu hướng nhóm các thứ theo khả năng hiển thị (công khai, sau đó được bảo vệ, sau đó riêng tư) và sử dụng #regions để nhóm các thứ liên quan theo chức năng, bất kể đó là tài sản, phương thức hay bất cứ điều gì. Các phương pháp xây dựng (cho dù các công cụ thực tế hoặc các chức năng tĩnh của nhà máy) thường ở ngay trên đầu vì chúng là điều đầu tiên khách hàng cần biết.

Tôi biết điều này là cũ nhưng thứ tự của tôi là như sau:

theo thứ tự công cộng, được bảo vệ, riêng tư, nội bộ, trừu tượng

• Hằng số
• Biến tĩnh
• Lĩnh vực
• Sự kiện
• Người xây dựng
• Phương pháp
• Tính chất
• Đại biểu

Tôi cũng thích viết ra các thuộc tính như thế này (thay vì cách tiếp cận tốc ký)

// Some where in the fields section
private int someVariable;

// I also refrain from
// declaring variables outside of the constructor

// and some where in the properties section I do
public int SomeVariable
{
    get { return someVariable; }
    set { someVariable = value; }
}