Quy ước đặt tên tốt cho các loại chung trong C # là gì? [đóng cửa]

Tôi quyết định đặt câu hỏi này ở đây thay vì trên stack stack vì nó khá chủ quan.

Trong C #, thông thường tôi thấy các loại chung có tên rất kém. Cụ thể, "T" thường được sử dụng nhưng bản thân nó không phải là một tên có ý nghĩa. Ví dụ:

class Fruit<T>
{
    T fruit;
}

Trong khi đây là cách tiếp cận điển hình, bất cứ ai sẽ đề nghị chống lại điều này? Và nếu vậy, một quy ước đặt tên hợp lý sẽ là gì đối với các kiểu chung trong ngữ cảnh của C # cho các hàm và các lớp chung?

Trong ví dụ trước của tôi, hãy giả sử rằng loại chung Tphải luôn là một loại trái cây, chẳng hạn như Applehoặc Orange. Loại Tcần phải làm rõ rằng đó là một loại trái cây, vì vậy có lẽ một cái tên tốt hơn sẽ là FruitType, vì vậy chúng tôi kết thúc với:

class Fruit<FruitType>
{
    FruitType fruit;
}

Đây chỉ là để cung cấp cho các bạn một ý tưởng về những gì tôi đang tìm kiếm. "Quy tắc ngón tay cái" nào được chấp nhận cho vấn đề này?

Nó thực sự chủ quan ... ish .
Vì một số người tìm thấy ilà hoàn toàn hợp lệ cho một biến vòng lặp for, một số người cho rằng Thoàn toàn hợp lệ đối với một người giữ chỗ kiểu trong một lớp chung.

Cá nhân tôi tán thành cách tiếp cận này, đó là một quy ước chung và mọi người thường biết ý của bạn là gì.

Trường hợp loại có ý nghĩa Tôi sử dụng một tên có ý nghĩa, nhưng thường bắt đầu bằng T. Tôi gần đây đã phát triển một lớp từ điển chung (không hỏi) và khai báo là

public class Dictionary<TKey, TValue>

Tuy nhiên, đối với một cái gì đó như Tuple, trong đó các loại về cơ bản là vô nghĩa, tôi xem xét những điều sau đây là hoàn toàn chấp nhận được.

public class Tuple<T1, T2, T3>

Tôi nghĩ bạn đã đúng, mặc dù T đã trở thành một tiêu chuẩn. Nó có lẽ bắt nguồn từ thời C ++ cũ và từ "loại T". Tôi coi đó là một thực hành tốt để được mô tả càng tốt, nhưng đó là chủ quan.

Bạn có thể chọn T làm tiền tố, giống như nhiều người chọn I cho giao diện. Như vậy

class Juice<TFruit> where TFruit...

sẽ là một cái tên tốt trong quan điểm khiêm tốn của tôi. Tôi thích tiền tố hơn hậu tố trong hầu hết các trường hợp, vì nó ngay lập tức rõ ràng những gì bạn đang thấy khi bạn vấp phải nó và dễ dàng tìm kiếm những thứ như Intellisense. Đó cũng là một cách thực hành tốt cho Điều khiển giao diện người dùng, khi bạn rất có thể luôn biết loại (ví dụ TextBox) nhưng không chắc chắn 100% về tên mô tả mà bạn đã đặt cho nó.

Mặt tiêu cực của nó là, nó trông tệ khi loại chính nó bắt đầu bằng T. Vì vậy, tôi nghĩ rằng sẽ là một điều tốt để bổ sung cho loại chung trong các trường hợp đặc biệt, như kiểu dưới đây.

class SomeAlgorithm<TypeT> where TypeT : Type

Xin lưu ý rằng đây chỉ là ý kiến ​​của tôi và rất chủ quan. Nhưng tôi nghĩ rằng tôi đã có một điểm nhỏ với việc thích tiền tố hơn là hậu tố.

Microsoft có một hướng dẫn chính thức liên quan đến khái quát: Tên của các lớp, cấu trúc và giao diện (được trích dẫn ở đây và ở dạng sách: Nguyên tắc thiết kế khung ).

Về câu hỏi cụ thể của bạn, nó nói:

Đặt tên tham số loại chung với tên mô tả, trừ khi tên một chữ cái hoàn toàn tự giải thích và tên mô tả sẽ không thêm giá trị.

IDictionary<TKey, TValue> 

là một ví dụ về giao diện tuân theo hướng dẫn này.

Xem xét sử dụng chữ T làm tên tham số loại cho các loại có một tham số loại một chữ cái.

Làm tên tham số loại mô tả tiền tố với chữ T.

Xem xét chỉ ra các ràng buộc được đặt trên một tham số loại trong tên của tham số. Ví dụ: một tham số bị ràng buộc với ISession có thể được gọi là TSession.

Toàn bộ quan điểm của khái quát là ủy thác chức năng - lớp chung làm một việc, đối số của nó làm một việc khác. Ví dụ trong sách giáo khoa là một bộ sưu tập chung: bộ sưu tập lưu trữ 'những thứ', nhưng nó không quan tâm những thứ này là gì. Do đó, một tên chung (sic!) Có một logic nhất định - chúng tôi không muốn nó được mô tả, bởi vì không có gì để mô tả ngoài "đó là đối số kiểu chung", mà tên này Tbao hàm một cách triệt để (xem xét quy ước). Được mô tả là tốt, nhưng mô tả quá mức cho thấy những hạn chế không có ở đó.

Tuy nhiên, đôi khi, một lớp hoặc phương thức chung có nhiều hơn một tham số loại và tại thời điểm này, việc đặt cho chúng các tên mô tả nhiều hơn để vai trò của chúng trở nên rõ ràng. Một ví dụ điển hình sẽ là loại thu thập khóa-giá trị, trong đó cả khóa và giá trị đều chung chung; gọi họ Tvà S(hoặc Qbất cứ điều gì) sẽ ít hữu ích hơn so với gọi họ, nói, KeyTypevà ValueType, TKeyvà TVal.

Câu trả lời thực sự là chủ quan. Tuy nhiên, nó có giá trị như một câu hỏi, vì mã nên tự viết tài liệu và tất cả chúng ta có thể học một số cách tốt hơn để làm điều đó.

Sau đây là những quy ước tôi đã học và làm theo:

• Các tham số loại chung sẽ không bao giờ có thể bị nhầm lẫn với các lớp cụ thể. Điều này thường khuyến khích một lời nói đầu Tbất kể điều gì xảy ra sau đó, giống như các giao diện thường được mở đầu bằng I.

• Một tham số loại chung duy nhất trên một lớp hoặc phương thức thường phải được dán nhãn T. Đây là quy ước được hiểu gần như phổ biến từ các mẫu C ++.

• Nhiều tham số kiểu chung trên cùng một khai báo lớp hoặc phương thức nên bắt đầu bằng T, nhưng được phân biệt bằng một số phương tiện ngắn gọn nhưng dễ hiểu. TInvà TOut, ví dụ, là các GTP phổ biến và được hiểu rõ cho một phương thức chấp nhận đầu vào chung được gõ mạnh và tạo ra đầu ra chung được gõ mạnh.

• Nhiều loại khác biệt nhưng không đáng chú ý, chẳng hạn như đối với một lớp có chứa như. Tuple của Net hoặc các loại đại biểu như Func, Dự đoán và Hành động, có thể được gắn nhãn T1, T2, T3, v.v. Tuy nhiên, khai báo GTP "đáng chú ý" (có mục đích xác định và / hoặc hạn chế loại rất cụ thể) nên có một cái gì đó mô tả hơn.

• Một kiểu chung duy nhất trên một phương thức, khác với kiểu chung của một lớp chứa, có thể theo quy tắc trước đó liên quan đến nhiều loại trong một lớp hoặc phương thức, HOẶC nếu loại này không đáng chú ý khác với loại khác thì nó có thể được cung cấp khác thư đơn, thường Uhoặc V. Đây là một lần nữa quy ước có từ các mẫu C ++.

• Dù bạn chọn làm gì, hãy giữ nó nhất quán; không gắn nhãn GTP cho một lớp Tvà lớp tiếp theo TParam, trừ khi lớp thứ hai được lồng trong lớp thứ nhất Tkhông có sẵn để sử dụng trong lớp thứ hai.