C # (.NET) Design Flaws [đã đóng]

Một số lỗi thiết kế lớn nhất trong C # hoặc .NET Framework nói chung là gì?

Ví dụ: không có kiểu chuỗi không thể null và bạn phải kiểm tra DBNull khi tìm nạp các giá trị từ IDataReader.

Tôi hoàn toàn đồng ý với bài đăng này (đối với những người đang phân vân vì thiếu ToString, có một thuộc tính trình gỡ lỗi để cung cấp định dạng tùy chỉnh cho lớp của bạn).

Trên đầu danh sách trên, tôi cũng sẽ thêm các yêu cầu hợp lý sau:

1. loại tham chiếu không thể nullable như một bổ sung cho các loại giá trị có thể null,
2. cho phép ghi đè phương thức khởi tạo trống của cấu trúc,
3. cho phép các ràng buộc kiểu chung để chỉ định các lớp được niêm phong,
4. Tôi đồng ý với một người đăng khác ở đây đã yêu cầu chữ ký hàm tạo tùy ý khi được sử dụng làm ràng buộc, tức là. ở đâu T : new(string), hoặc ở đâuT : new(string, int)
5. Tôi cũng đồng ý với một người đăng khác ở đây về việc sửa chữa các sự kiện, cho cả danh sách sự kiện trống và trong cài đặt đồng thời (mặc dù sau này rất phức tạp),
6. toán tử phải được định nghĩa là phương thức mở rộng và không phải là phương thức tĩnh của lớp (hoặc ít nhất không chỉ là phương thức tĩnh),
7. cho phép các thuộc tính và phương thức tĩnh cho các giao diện (Java có điều này, nhưng C # thì không),
8. cho phép khởi tạo sự kiện trong trình khởi tạo đối tượng (hiện chỉ cho phép các trường và thuộc tính),
9. tại sao cú pháp "đối tượng khởi tạo" chỉ có thể sử dụng được khi tạo một đối tượng? Tại sao không làm cho nó có sẵn bất cứ lúc nào, tức là.var e = new Foo(); e { Bar = baz };
10. sửa chữa hành vi liệt kê bậc hai ,
11. tất cả các bộ sưu tập phải có ảnh chụp nhanh không thể thay đổi để lặp lại (nghĩa là. việc thay đổi bộ sưu tập sẽ không làm mất hiệu lực của trình lặp),
12. các bộ giá trị rất dễ thêm vào, nhưng kiểu đại số đóng hiệu quả như " Either<T>" thì không, vì vậy tôi muốn có một số cách để khai báo một kiểu đại số đóng và thực thi đối sánh mẫu đầy đủ trên nó (về cơ bản hỗ trợ hạng nhất cho mẫu khách truy cập, nhưng hiệu quả hơn nhiều); vì vậy chỉ cần lấy enums, mở rộng chúng với hỗ trợ khớp mẫu đầy đủ và không cho phép các trường hợp không hợp lệ,
13. Tôi muốn hỗ trợ cho việc đối sánh mẫu nói chung, nhưng ít nhất là cho kiểm tra loại đối tượng; Tôi cũng thích cú pháp chuyển đổi được đề xuất trong một bài đăng khác ở đây,
14. Tôi đồng ý với một bài đăng khác rằng các System.IOlớp, giống như Stream, được thiết kế hơi kém; bất kỳ giao diện nào yêu cầu một số triển khai sẽ NotSupportedExceptionlà một thiết kế tồi,
15. IListnên đơn giản hơn nhiều so với hiện tại; trên thực tế, điều này có thể đúng đối với nhiều các giao diện bộ sưu tập bê tông, như ICollection,
16. quá nhiều phương thức tạo ra các ngoại lệ, chẳng hạn như IDictionary,
17. Tôi muốn một dạng ngoại lệ được kiểm tra tốt hơn dạng có sẵn trong Java (xem phần nghiên cứu về hệ thống kiểu và hiệu ứng để biết cách thực hiện điều này),
18. sửa các trường hợp góc khó chịu khác nhau trong giải quyết quá tải phương pháp chung; chẳng hạn, hãy thử cung cấp hai phương thức mở rộng được nạp chồng, một phương thức hoạt động trên các kiểu tham chiếu và phương thức kia hoạt động trên các kiểu cấu trúc có thể nullable và xem cách suy luận kiểu của bạn thích điều đó
19. cung cấp một cách để phản ánh an toàn về trường và tên thành viên cho các giao diện như INotifyPropertyChangedlấy tên trường dưới dạng một chuỗi; bạn có thể làm điều này bằng cách sử dụng một phương thức mở rộng nhận lambda với MemberExpression, tức là. () => Foo, nhưng điều đó không hiệu quả lắm,
    • Cập nhật: C # 6.0 đã thêm nameof()toán tử cho các tên thành viên đơn lẻ, nhưng nó không hoạt động ở dạng chung ( nameof(T) == "T"thay vì tên của đối số kiểu thực tế: bạn vẫn cần làm typeof(T).Name)) - cũng như không cho phép bạn nhận chuỗi "đường dẫn" , ví dụ như nameof(this.ComplexProperty.Value) == "Value"hạn chế các ứng dụng có thể có của nó.
20. cho phép các toán tử trong các giao diện và thực hiện tất cả các loại số lõi IArithmetic ; các giao diện điều hành được chia sẻ hữu ích khác cũng có thể,
21. làm cho việc thay đổi các trường / thuộc tính của đối tượng trở nên khó khăn hơn, hoặc ít nhất, cho phép chú thích các trường bất biến và làm cho trình kiểm tra kiểu thực thi nó (chỉ cần coi nó như thuộc tính getter-only fer chrissakes, nó không khó!); trên thực tế, hợp nhất các trường và thuộc tính theo cách hợp lý hơn vì chẳng ích gì khi có cả hai; Các thuộc tính tự động của C # 3.0 là bước đầu tiên theo hướng này, nhưng chúng không đi đủ xa,
    • Cập nhật: Mặc dù C # có readonlytừ khóa và C # 6.0 đã thêm thuộc tính tự động chỉ đọc, mặc dù nó không nghiêm ngặt như hỗ trợ ngôn ngữ thực cho các loại và giá trị bất biến.
22. đơn giản hóa việc khai báo các hàm tạo; Tôi thích cách tiếp cận của F #, nhưng bài đăng khác ở đây yêu cầu đơn giản là "mới" thay vì tên lớp ít nhất thì tốt hơn,

Bây giờ tôi cho là đủ rồi. Đây là tất cả những khó chịu mà tôi đã gặp phải trong tuần qua. Tôi có lẽ có thể tiếp tục hàng giờ đồng hồ nếu tôi thực sự dành tâm trí cho nó. C # 4.0 đã thêm các đối số được đặt tên, tùy chọn và mặc định, mà tôi thực sự chấp thuận.

Bây giờ cho một yêu cầu không hợp lý:

1. sẽ thực sự tuyệt vời nếu C # / CLR có thể hỗ trợ tính đa hình của hàm tạo kiểu, tức là. generics hơn generic,

Đẹp không? :-)

• các Reset()phương pháp trên IEnumerator<T>là một sai lầm (đối với khối iterator, spec ngôn ngữ thậm chí đòi hỏi rằng điều này ném một ngoại lệ)
• Theo quan điểm của Eric, các phương thức phản chiếu trả về mảng là một sai lầm
• hiệp phương sai của mảng đã và vẫn là một sự kỳ lạ
  • Cập nhật: C # 4.0 với .NET 4.0 đã thêm hỗ trợ hiệp phương sai / tương phản cho các giao diện chung (như IEnumerable<out T>và Func<in T, out TResult>, nhưng không phải các kiểu cụ thể (như List<T>).
• ApplicationException khá thất vọng - đó có phải là một sai lầm?
• các bộ sưu tập được đồng bộ hóa - một ý tưởng hay, nhưng không nhất thiết phải hữu ích trong thực tế: bạn thường cần phải đồng bộ hóa nhiều hoạt động ( Containssau đó Add), vì vậy một bộ sưu tập đồng bộ hóa các hoạt động riêng biệt không phải là tất cả đều hữu ích
  • Cập nhật: Các System.Collections.Concurrentloại , với TryAdd, GetOrAdd, TryRemove, vv đã được thêm vào trong .NET Framework 4.0 - mặc dù phương pháp mà chấp nhận một đại biểu nhà máy không đảm bảo nhà máy sẽ chỉ được gọi một lần cho mỗi khoá.
• có thể sử dụng nhiều hơn đối với using/ lockpattern - có lẽ cho phép chúng chia sẻ cú pháp có thể sử dụng lại (có thể mở rộng?); bạn có thể mô phỏng điều này bằng cách quay lại IDisposablevà sử dụng using, nhưng nó có thể rõ ràng hơn
• khối lặp: không có cách nào đơn giản để kiểm tra các đối số trước thời hạn (thay vì lười biếng). Chắc chắn, bạn có thể viết hai phương thức chuỗi, nhưng điều đó thật tệ
• bất biến đơn giản hơn sẽ là tốt; C # 4.0 giúp được một chút , nhưng chưa đủ
• không hỗ trợ "tham số ref-type này không thể là null" - mặc dù các hợp đồng (trong 4.0) giúp giải quyết phần nào điều này. Nhưng cú pháp như Foo(SqlConnection! connection)(chèn một dấu kiểm / throw) sẽ rất hay (trái ngược vớiint? v.v.)
  • Cập nhật: Điều này đã được sửa trong C # 8.0 .
• thiếu sự hỗ trợ của các toán tử và các nhà xây dựng không mặc định với generic; C # 4.0 giải quyết vấn đề này một chút với dynamichoặc bạn có thể bật nó như thế này
• biến trình lặp được khai báo bên ngoài while trongforeach mở rộng, có nghĩa là anon-method / lambdas nắm bắt biến duy nhất, thay vì một biến trên mỗi lần lặp (khó khăn với luồng / async / etc)
  • Cập nhật: Điều này đã được sửa trong C # 5.0 .

TextWriter là một cơ sở lớp của StreamWriter. wtf?

Điều đó luôn khiến tôi hoang mang đến tột cùng.

Một peev nhỏ C # pet - các hàm tạo sử dụng cú pháp C ++ / Java để hàm tạo trùng tên với lớp.

New() hoặc là ctor() sẽ đẹp hơn nhiều.

Và chắc chắn, các công cụ như coderush làm cho việc đổi tên các lớp ít gặp vấn đề hơn, nhưng từ một POV có thể đọc được, New () cung cấp sự rõ ràng tuyệt vời.

Tôi không hiểu rằng bạn không thể làm

trong đó T: mới (U)

Vì vậy, bạn khai báo rằng kiểu chung T có một phương thức khởi tạo không mặc định.

biên tập:

Tôi muốn làm điều này:

public class A 
{
    public A(string text) 
    {

    }
}


public class Gen<T> where T : new(string text) 
{

}

Tôi thực sự ngạc nhiên khi tôi là người đầu tiên đề cập đến vấn đề này:

Tập dữ liệu được nhập ADO.NET không hiển thị các cột có thể làm trống dưới dạng thuộc tính của các kiểu có thể vô hiệu. Bạn sẽ có thể viết điều này:

int? i = myRec.Field;
myRec.Field = null;

Thay vào đó, bạn phải viết điều này, điều này thật ngu ngốc:

int? i = (int?)myRec.IsFieldNull() ? (int?)null : myRec.Field;
myRec.SetFieldNull();

Điều này đã gây khó chịu trong .NET 2.0 và thậm chí còn khó chịu hơn khi bạn phải sử dụng jiggery-pokery như trên trong các truy vấn LINQ gọn gàng đẹp mắt của mình.

Nó cũng gây khó chịu khi Add<TableName>Rowphương thức được tạo ra tương tự như không thể hiểu được với khái niệm về kiểu nullable. Hơn thế nữa kể từ khi tạoTableAdapter phương thức không phải như vậy.

Không có nhiều thứ trong .NET khiến tôi cảm thấy như nhóm nhà phát triển đã nói "Được rồi, các chàng trai, chúng ta đủ gần rồi - hãy giao hàng đi!" Nhưng điều này chắc chắn có.

1. Tôi không phải là một fan hâm mộ lớn của các lớp Stream, StringWriter, StringReader, TextReader, TextWriter ... nó chỉ là không trực quan là gì.
2. IEnumerable.Reset ném một ngoại lệ cho các trình vòng lặp. Tôi có một số thành phần của bên thứ ba luôn gọi đặt lại khi lập dữ liệu, yêu cầu tôi truyền đến một danh sách trước tiên để sử dụng chúng.
3. Xml Serializer phải có các phần tử IDictionary được tuần tự hóa
4. Tôi hoàn toàn quên mất API HttpWebRequest & FTP là một nỗi đau trong .... của tôi (cảm ơn vì đã nhận xét Nicholas nhắc tôi về điều này :-)

Chỉnh sửa
5. Một điều khó chịu khác của tôi là cách System.Reflection.BindingFlags, có các cách sử dụng khác nhau tùy thuộc vào phương pháp bạn sử dụng. Ví dụ trong FindField, CreateInstance hoặc SetField nghĩa là gì? Đây là một trường hợp mà họ đã quá tải ý nghĩa đằng sau cách liệt kê này gây nhầm lẫn.

Tôi không biết rằng tôi muốn nói rằng đó là một lỗi thiết kế, nhưng sẽ thực sự tuyệt vời nếu bạn có thể suy ra một biểu thức lambda theo cách giống như bạn có thể làm trong VB:

VB:

Dim a = Function(x) x * (x - 1)

C #

Thật tuyệt nếu có thể làm được điều này:

var a = x => x * (x - 1);

Thay vì phải làm điều này:

Func<int, int> a = x => x * (x - 1);

Tôi nhận ra không còn bao lâu nữa, nhưng trong Code Golf mọi nhân vật đều được tính là chết tiệt! Họ không tính đến điều đó khi thiết kế các ngôn ngữ lập trình này sao? :)

1. Lớp System.Object :

   • Equals và GetHashCode - không phải tất cả các lớp đều có thể so sánh được hoặc có thể băm, nên được chuyển sang một giao diện. IEquatable hoặc ICompABLE (hoặc tương tự) xuất hiện trong tâm trí.

   • ToString - không phải tất cả các lớp đều có thể được chuyển đổi thành chuỗi, nên được chuyển sang một giao diện. IFormattable (hoặc tương tự) xuất hiện trong tâm trí.

2. Các ICollection.SyncRoot bất động sản:

   • Khuyến khích thiết kế kém, một ổ khóa bên ngoài hầu như luôn hữu ích hơn.

3. Generics đáng lẽ phải có ngay từ đầu:

   • Không gian tên System.Collections chứa rất nhiều lớp và giao diện đã lỗi thời.

Một trong những điều làm tôi khó chịu là Predicate<T> != Func<T, bool>nghịch lý. Cả hai đều thuộc loại đại biểu T -> boolnhưng chúng không tương thích với nhiệm vụ.

Một số người (ISV) muốn rằng bạn có thể biên dịch nó thành mã máy tại thời điểm xây dựng và liên kết nó, để tạo một tệp thực thi gốc không cần thời gian chạy dotNet.

Chúng tôi biết rất nhiều về các kỹ thuật OO phù hợp . Tách rời, lập trình theo hợp đồng, tránh kế thừa không đúng, sử dụng thích hợp các ngoại lệ, chính mở / đóng, khả năng thay thế Liskov, v.v. Tuy nhiên, các khung .Net không sử dụng các phương pháp hay nhất.

Đối với tôi, khuyết điểm lớn nhất trong thiết kế của .Net là không đứng trên vai của những người khổng lồ; quảng bá các mô hình lập trình ít hơn lý tưởng cho nhiều lập trình viên sử dụng khuôn khổ của họ .

Nếu MS chú ý đến điều này, thế giới kỹ thuật phần mềm có thể đã có những bước tiến nhảy vọt về chất lượng, độ ổn định và khả năng mở rộng trong thập kỷ này, nhưng than ôi, nó dường như đang thoái trào.

Tôi không thích câu lệnh switch C #.

Tôi muốn một cái gì đó như thế này

switch (a) {
  1    : do_something;
  2    : do_something_else;
  3,4  : do_something_different;
  else : do_something_weird; 
}

Vì vậy, không còn dấu ngắt (dễ quên) và khả năng phân tách các giá trị khác nhau bằng dấu phẩy.

Sự kiện trong C #, nơi bạn phải kiểm tra rõ ràng người nghe. Đó chẳng phải là điểm của các sự kiện, để phát sóng cho bất cứ ai tình cờ có mặt ở đó? Ngay cả khi không có bất kỳ?

Hành vi khủng khiếp (và khá vô hình đối với hầu hết mọi người) O (N ^ 2) của các trình lặp đệ quy / đệ quy lồng nhau .

Tôi khá buồn khi họ biết về nó, biết cách sửa chữa nó nhưng nó không được coi là có đủ ưu tiên để đưa vào danh sách.

Tôi luôn làm việc với các cấu trúc dạng cây và phải sửa lại mã của những người thông minh khi họ vô tình đưa ra các hoạt động đắt tiền theo cách này.

Cái hay của "gain foreach" là cú pháp đơn giản hơn, dễ dàng hơn khuyến khích mã chính xác, hiệu quả. Đây là "hố sâu thành công" mà tôi nghĩ họ nên khao khát trước khi thêm các tính năng mới cho thành công lâu dài của nền tảng.

Một số lớp triển khai giao diện nhưng chúng không triển khai nhiều phương thức của giao diện đó, ví dụ: Mảng thực hiện IList nhưng 4 trong số 9 phương thức ném NotSupportedException http://msdn.microsoft.com/en-us/library/system.array_members .aspx

Các thành viên tĩnh và các kiểu lồng nhau trong giao diện.

Điều này đặc biệt hữu ích khi một thành viên giao diện có một tham số thuộc loại cụ thể cho giao diện ( ví dụ: an enum). Sẽ rất tuyệt nếu lồng kiểu enum vào kiểu giao diện.

Tính chất mặc định nguy hiểm khủng khiếp của các sự kiện. Thực tế là bạn có thể gọi một sự kiện và ở trong trạng thái không nhất quán do người đăng ký bị xóa thật là kinh khủng. Xem các bài báo xuất sắc của Jon Skeet và Eric Lippert để đọc thêm về chủ đề này.

• null mọi nơi.

• const hư không.

• Các API không nhất quán, ví dụ: thay đổi một mảng sẽ trả về voidnhưng thêm vào một StringBuffertrả về cùng một biến StringBuffer.

• Giao diện bộ sưu tập không tương thích với cấu trúc dữ liệu bất biến, ví dụ: Addin System.Collections.Generic.IList<_>không thể trả về kết quả.

• Không có cấu trúc gõ để bạn viết System.Windows.Media.Effects.SamplingMode.Bilinearthay vì chỉ Bilinear.

• Có thể thay đổi IEnumeratorgiao diện được thực hiện bởi các lớp học khi nó phải là một bất biến struct.

• Bình đẳng và so sánh là một mớ hỗn độn: bạn đã có System.IComparablevà Equalsnhưng sau đó bạn cũng đã có System.IComparable<_>, System.IEquatable, System.Collections.IComparer, System.Collections.IStructuralComparable, System.Collections.IStructuralEquatable, System.Collections.Generic.IComparervà System.Collections.Generic.IEqualityComparer.

• Tuples phải là cấu trúc nhưng cấu trúc ngăn cản việc loại bỏ lệnh gọi đuôi một cách không cần thiết, vì vậy một trong những kiểu dữ liệu cơ bản và phổ biến nhất sẽ phân bổ không cần thiết và phá hủy tính song song có thể mở rộng.

0 moonlighting as enum

đặc thù của enum: http://blogs.msdn.com/abhinaba/archive/2007/01/09/more-peculiarites-of-enum.aspx

như được minh họa bởi ví dụ điển hình này: http://plus.kaist.ac.kr/~shoh/postgresql/Npgsql/apidocs/Npgsql.NpgsqlParameterCollection.Add_overload_3.html

đề xuất của tôi, hãy đặt dấu "@" để sử dụng tốt:

thay vì:

if ((myVar & MyEnumName.ColorRed)! = 0)

dùng cái này:

if ((myVar & MyEnumName.ColorRed)! = @ 0)

Để thêm vào danh sách dài những điểm tốt của những người khác đã có:

• DateTime.Now == DateTime.Now trong hầu hết, nhưng không phải tất cả các trường hợp.

• Stringlà bất biến có một loạt các tùy chọn để xây dựng và thao tác, nhưng StringBuilder(có thể thay đổi) thì không.

• Monitor.Entervà Monitor.Exitlẽ ra phải là các phương thức thể hiện, vì vậy thay vì tạo mới một đối tượng cụ thể để khóa, bạn có thể tạo mới a Monitorvà khóa đối tượng đó.

• Trình hủy không bao giờ được đặt tên là trình hủy. Đặc tả ECMA gọi chúng là trình hoàn thiện, điều này ít gây nhầm lẫn hơn cho đám đông C ++, nhưng đặc tả ngôn ngữ vẫn gọi chúng là trình hủy.

Cách chúng tôi sử dụng các thuộc tính đôi khi làm tôi khó chịu. Tôi thích nghĩ chúng tương đương với các phương thức getFoo () và setFoo () của Java. Nhưng không phải vậy.

Nếu Nguyên tắc sử dụng thuộc tính nêu rõ rằng các thuộc tính có thể được đặt theo bất kỳ thứ tự nào để quá trình tuần tự hóa có thể hoạt động, thì chúng sẽ vô dụng đối với việc xác thực thời gian thiết lập. Nếu bạn đến từ một nền mà bạn muốn ngăn một đối tượng không cho phép chính nó rơi vào trạng thái không hợp lệ, thì thuộc tính không phải là giải pháp của bạn. Đôi khi tôi không thể thấy họ tốt hơn các thành viên công cộng như thế nào, vì chúng tôi rất hạn chế về những loại công việc mà chúng tôi phải làm trong tài sản.

Để đạt được điều đó, tôi đã luôn ước gì (điều này chủ yếu là suy nghĩ lung tung ở đây, tôi chỉ ước mình có thể làm được điều gì đó như thế này) rằng tôi có thể mở rộng cú pháp thuộc tính bằng cách nào đó. Hãy tưởng tượng một cái gì đó như thế này:

private string password;

public string Password
{
    // Called when being set by a deserializer or a persistence
    // framework
    deserialize
    {
       // I could put some backward-compat hacks in here. Like
       // weak passwords are grandfathered in without blowing up
       this.password = value;
    }
    get
    {
       if (Thread.CurrentPrincipal.IsInRole("Administrator"))
       {
           return this.password;
       }
       else
       {
           throw new PermissionException();
       }
    }
    set
    {
       if (MeetsPasswordRequirements(value))
       {
           throw new BlahException();
       }
       this.password = value;
    }
    serialize
    {
        return this.password;
    }
}

Tôi không chắc liệu điều đó có hữu ích hay nó truy cập những thứ đó sẽ trông như thế nào. Nhưng tôi chỉ ước rằng tôi có thể làm được nhiều hơn với các thuộc tính và thực sự coi chúng như các phương thức get và set.

Các phương pháp mở rộng rất hay nhưng chúng là một cách xấu xí để giải quyết các vấn đề mà lẽ ra có thể được giải quyết sạch hơn với các mixin thực (hãy nhìn vào ruby ​​để xem tôi đang nói gì), về chủ đề mixin. Một cách thực sự hay để thêm chúng vào ngôn ngữ là cho phép các generic được sử dụng để kế thừa. Điều này cho phép bạn mở rộng các lớp hiện có theo hướng đối tượng tốt:

public class MyMixin<T> : T
{
    // etc...
}

điều này có thể được sử dụng như thế này để mở rộng một chuỗi, ví dụ:

var newMixin = new MyMixin<string>();

Nó mạnh hơn nhiều so với các phương thức mở rộng vì nó cho phép bạn ghi đè các phương thức, chẳng hạn như bọc chúng cho phép chức năng giống AOP bên trong ngôn ngữ.

Xin lỗi vì rant :-)

Microsoft sẽ không sửa các lỗi rõ ràng trong khuôn khổ và sẽ không cung cấp các móc để người dùng cuối có thể sửa chúng.

Ngoài ra, không có cách nào để thực thi .NET nhị phân vá lỗi trong thời gian chạy và không có cách nào để chỉ định phiên bản riêng của thư viện khung công tác .NET mà không có bản vá nhị phân các thư viện gốc (để chặn cuộc gọi tải) và ILDASM không thể phân phối lại nên tôi không thể tự động hóa bản vá.

• Có thể gọi một phương thức mở rộng trên biến null được cho là có thể

  đối tượng a = null; a.MyExtMethod (); // cái này có thể gọi được, giả sử ở đâu đó nó đã định nghĩa MyExtMethod

  Nó có thể hữu ích nhưng nó không rõ ràng về các chủ đề ngoại lệ tham chiếu rỗng.

• Một 'lỗ hổng' đặt tên. 'C' của "cấu hình" trong System.configuration.dll phải được viết hoa.

• Xử lý ngoại lệ. Ngoại lệ nên được bắt hoặc ném ra giống như trong Java, trình biên dịch nên kiểm tra nó tại thời điểm biên dịch. Người dùng không nên dựa vào các nhận xét để biết thông tin ngoại lệ trong lời gọi đích.

Phương thức .Parameters.Add () trên SqlCommand trong V1 của khung công tác được thiết kế khủng khiếp - một trong những quá tải về cơ bản sẽ không hoạt động nếu bạn truyền vào một tham số có giá trị (int) bằng 0 - điều này dẫn đến việc chúng tạo ra phương thức .Parameters.AddWithValue () trên lớp SqlCommand.

1. Không có tập con nào của ICollection<T>và IList<T>; tối thiểu, một giao diện thu thập hiệp biến chỉ đọc IListSource<out T>(với một điều tra viên, bộ lập chỉ mục và Bộ đếm) sẽ cực kỳ hữu ích.
2. .NET không hỗ trợ các đại biểu yếu . Các giải pháp thay thế tốt nhất là vụng về và các giải pháp giải quyết phía người nghe là không thể tin tưởng một phần (cần có ReflectionPermission).
3. Hợp nhất giao diện chung bị cấm ngay cả khi nó có ý nghĩa và không gây ra vấn đề gì.
4. Không giống như trong C ++, kiểu trả về hiệp phương sai không được phép trong .NET
5. Không thể so sánh theo từng bit-so sánh hai kiểu giá trị để có giá trị bằng nhau. Trong cấu trúc dữ liệu " liên tục " chức năng , tôi đã viếtTransform(Sequence<T>, Func<T,T>) hàm cần xác định nhanh xem hàm trả về cùng một giá trị hay một giá trị khác. Nếu hàm không sửa đổi hầu hết / tất cả các đối số của nó, thì chuỗi đầu ra có thể chia sẻ một số / tất cả bộ nhớ từ chuỗi đầu vào. Nếu không có khả năng so sánh bitwise bất kỳ loại giá trị T nào, thì phải sử dụng phép so sánh chậm hơn nhiều, điều này làm ảnh hưởng rất nhiều đến hiệu suất.
6. .NET dường như không thể hỗ trợ các giao diện đặc biệt (như những giao diện được cung cấp trong Go hoặc Rust) một cách hiệu quả. Các giao diện như vậy sẽ cho phép bạn truyền List<T>đến một giả định IListSource<U>(trong đó T: U) mặc dù lớp không thực thi giao diện đó một cách rõ ràng. Có ít nhất ba thư viện khác nhau (được viết độc lập) để cung cấp chức năng này (tất nhiên là có những hạn chế về hiệu suất - nếu có thể có một giải pháp hoàn hảo, sẽ không công bằng nếu gọi nó là một lỗ hổng trong .NET).
7. Các vấn đề về hiệu suất khác: IEnumerator yêu cầu hai lệnh gọi giao diện mỗi lần lặp. Con trỏ phương thức thuần túy (đại biểu mở có kích thước IntPtr) hoặc đại biểu được định kiểu giá trị (IntPtr * 2) là không thể. Mảng có kích thước cố định (kiểu T tùy ý) không thể được nhúng vào bên trong các lớp. Không có WeakReference<T>(bạn có thể dễ dàng viết của riêng bạn, nhưng nó sẽ sử dụng phôi bên trong.)
8. Thực tế là các loại đại biểu giống hệt nhau được coi là không tương thích (không có chuyển đổi ngầm định) đã gây phiền toái cho tôi trong một số trường hợp (ví dụ: Predicate<T>vs Func<T,bool>). Tôi thường ước chúng ta có thể nhập cấu trúc cho các giao diện và đại biểu, để đạt được khớp nối lỏng lẻo hơn giữa các thành phần, bởi vì trong .NET, không đủ để các lớp trong các DLL độc lập triển khai cùng một giao diện - chúng cũng phải chia sẻ tham chiếu chung đến một phần ba DLL xác định giao diện.
9. DBNull.Valuetồn tại mặc dù nullsẽ phục vụ cùng một mục đích tốt như nhau.
10. C # không có toán tử ?? =; bạn phải viết variable = variable ?? value. Thật vậy, có một vài chỗ trong C # thiếu đối xứng. Ví dụ, bạn có thể viết if (x) y(); else z();(không có dấu ngoặc nhọn), nhưng bạn không thể viết try y(); finally z();.
11. Khi tạo một luồng, không thể khiến cho luồng con kế thừa các giá trị của luồng-cục bộ từ luồng cha. BCL không chỉ không hỗ trợ điều này mà bạn không thể tự thực hiện nó trừ khi bạn tạo tất cả các luồng theo cách thủ công; ngay cả khi có một sự kiện tạo luồng, .NET không thể cho bạn biết "cha mẹ" hoặc "con" của một luồng nhất định.
12. Thực tế là có hai thuộc tính độ dài khác nhau cho các kiểu dữ liệu khác nhau, "Độ dài" và "Đếm", là một điều phiền toái nhỏ.
13. Tôi có thể nói mãi về thiết kế tồi tệ của WPF ... và WCF (mặc dù khá hữu ích cho một số trường hợp) cũng đầy mụn cóc. Nói chung, sự cồng kềnh, không trực quan và tài liệu hạn chế của nhiều thư viện con mới hơn của BCL khiến tôi không muốn sử dụng chúng. Rất nhiều nội dung mới có thể đơn giản hơn, nhỏ hơn, dễ sử dụng và dễ hiểu hơn, được liên kết chặt chẽ hơn, được tài liệu hóa tốt hơn, có thể áp dụng cho nhiều trường hợp sử dụng hơn, nhanh hơn và / hoặc được đánh máy mạnh hơn.
14. Tôi thường bị cắn bởi sự kết hợp không cần thiết giữa bộ nhận thuộc tính và bộ định tuyến: Trong một lớp dẫn xuất hoặc giao diện dẫn xuất, bạn không thể chỉ cần thêm một bộ định vị khi lớp cơ sở hoặc giao diện cơ sở chỉ có một bộ định tuyến; nếu bạn ghi đè một getter thì bạn không được phép xác định một setter; và bạn không thể định nghĩa setter là ảo nhưng getter là không ảo.

Một điều khiến tôi ngạc nhiên trong 1.x là khi sử dụng System.Xml.XmlValidatingReader, ValidationEventHandler's ValidationEventArgskhông làm lộ ra phần bên dưới XmlSchemaException(được đánh dấu bên trong) có tất cả các thông tin hữu ích như linenumbervà position. Thay vào đó, bạn dự kiến ​​sẽ phân tích cú pháp này ra khỏi thuộc tính Chuỗi tin nhắn hoặc sử dụng phản chiếu để tìm hiểu nó. Không tốt lắm khi bạn muốn trả lại một lỗi được làm sạch hơn cho người dùng cuối.

Không thích rằng bạn không thể sử dụng các giá trị của một enum này trong một enum khác, ví dụ:

    enum Colors { white, blue, green, red, black, yellow }

    enum SpecialColors { Colors.blue, Colors.red, Colors.Yellow } 

Biến được nhập ngầm được triển khai IMO kém. Tôi biết bạn thực sự chỉ nên sử dụng chúng khi làm việc với các biểu thức Linq, nhưng thật khó chịu khi bạn không thể khai báo chúng bên ngoài phạm vi cục bộ.

Từ MSDN:

• var chỉ có thể được sử dụng khi một biến cục bộ được khai báo và khởi tạo trong cùng một câu lệnh; biến không thể được khởi tạo thành null, hoặc một nhóm phương thức hoặc một hàm ẩn danh.
• var không thể được sử dụng trên các trường ở phạm vi lớp.
• Các biến được khai báo bằng cách sử dụng var không thể được sử dụng trong biểu thức khởi tạo. Nói cách khác, biểu thức này là hợp pháp: int i = (i = 20); nhưng biểu thức này tạo ra lỗi thời gian biên dịch: var i = (i = 20);
• Nhiều biến được định kiểu ngầm định không thể được khởi tạo trong cùng một câu lệnh.
• Nếu một kiểu có tên var nằm trong phạm vi, thì từ khóa var sẽ phân giải thành tên kiểu đó và sẽ không được coi là một phần của khai báo biến cục bộ được nhập ngầm.

Lý do tôi nghĩ rằng đó là một triển khai kém là họ gọi nó là var, nhưng còn lâu mới trở thành một biến thể. Nó thực sự chỉ là cú pháp viết tắt để không phải nhập tên lớp đầy đủ (ngoại trừ khi được sử dụng với Linq)