Gần đây tôi đã làm việc với một DateTimeđối tượng và đã viết một cái gì đó như thế này:

DateTime dt = DateTime.Now;
dt.AddDays(1);
return dt; // still today's date! WTF?

Tài liệu intellisense cho AddDays()biết nó thêm một ngày vào ngày mà nó không - nó thực sự trả về một ngày với một ngày được thêm vào nó, vì vậy bạn phải viết nó như sau:

DateTime dt = DateTime.Now;
dt = dt.AddDays(1);
return dt; // tomorrow's date

Điều này đã cắn tôi một số lần trước đây, vì vậy tôi nghĩ rằng nó sẽ hữu ích để lập danh mục các C # gotchas tồi tệ nhất.

private int myVar;
public int MyVar
{
    get { return MyVar; }
}

Blammo. Ứng dụng của bạn gặp sự cố không có dấu vết ngăn xếp. Xảy ra mọi lúc.

(Thông báo vốn MyVarthay vì chữ thường myVartrong getter.)

Loại.GetType

Người mà tôi đã thấy cắn nhiều người là Type.GetType(string). Họ tự hỏi tại sao nó hoạt động cho các loại trong lắp ráp riêng của họ, và một số loại như System.String, nhưng không System.Windows.Forms.Form. Câu trả lời là nó chỉ nhìn vào lắp ráp hiện tại và trong mscorlib.

Phương pháp ẩn danh

C # 2.0 đã giới thiệu các phương thức ẩn danh, dẫn đến các tình huống khó chịu như thế này:

using System;
using System.Threading;

class Test
{
    static void Main()
    {
        for (int i=0; i < 10; i++)
        {
            ThreadStart ts = delegate { Console.WriteLine(i); };
            new Thread(ts).Start();
        }
    }
}

Điều đó sẽ in ra cái gì? Vâng, nó hoàn toàn phụ thuộc vào lịch trình. Nó sẽ in 10 số, nhưng có lẽ nó sẽ không in 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, đó là những gì bạn có thể mong đợi. Vấn đề là đó là ibiến đã được nắm bắt, không phải là giá trị của nó tại điểm tạo ra đại biểu. Điều này có thể được giải quyết dễ dàng với một biến cục bộ bổ sung có phạm vi đúng:

using System;
using System.Threading;

class Test
{
    static void Main()
    {
        for (int i=0; i < 10; i++)
        {
            int copy = i;
            ThreadStart ts = delegate { Console.WriteLine(copy); };
            new Thread(ts).Start();
        }
    }
}

Trì hoãn thực hiện các khối lặp

"Bài kiểm tra đơn vị của người nghèo" này không vượt qua - tại sao không?

using System;
using System.Collections.Generic;
using System.Diagnostics;

class Test
{
    static IEnumerable<char> CapitalLetters(string input)
    {
        if (input == null)
        {
            throw new ArgumentNullException(input);
        }
        foreach (char c in input)
        {
            yield return char.ToUpper(c);
        }
    }

    static void Main()
    {
        // Test that null input is handled correctly
        try
        {
            CapitalLetters(null);
            Console.WriteLine("An exception should have been thrown!");
        }
        catch (ArgumentNullException)
        {
            // Expected
        }
    }
}

Câu trả lời là mã trong nguồn của CapitalLettersmã không được thực thi cho đến khi MoveNext()phương thức của trình vòng lặp được gọi lần đầu tiên.

Tôi đã có một số điều kỳ lạ khác trên trang brainteasers của tôi .

Ném lại ngoại lệ

Một gotcha nhận được rất nhiều nhà phát triển mới, là ngữ nghĩa ngoại lệ.

Nhiều thời gian tôi thấy mã như sau

catch(Exception e) 
{
   // Do stuff 
   throw e; 
}

Vấn đề là nó xóa sạch dấu vết ngăn xếp và làm cho việc chẩn đoán các vấn đề khó khăn hơn nhiều, vì bạn không thể theo dõi ngoại lệ bắt nguồn từ đâu.

Mã chính xác là câu lệnh throw không có đối số:

catch(Exception)
{
    throw;
}

Hoặc gói ngoại lệ trong một ngoại lệ khác và sử dụng ngoại lệ bên trong để có được dấu vết ngăn xếp ban đầu:

catch(Exception e) 
{
   // Do stuff 
   throw new MySpecialException(e); 
}

Cửa sổ đồng hồ Heisenberg

Điều này có thể cắn bạn rất tệ nếu bạn đang làm những thứ theo yêu cầu, như thế này:

private MyClass _myObj;
public MyClass MyObj {
  get {
    if (_myObj == null)
      _myObj = CreateMyObj(); // some other code to create my object
    return _myObj;
  }
}

Bây giờ hãy nói rằng bạn có một số mã ở nơi khác bằng cách sử dụng này:

// blah
// blah
MyObj.DoStuff(); // Line 3
// blah

Bây giờ bạn muốn gỡ lỗi CreateMyObj()phương thức của bạn . Vì vậy, bạn đặt một điểm dừng trên Dòng 3 ở trên, với ý định bước vào mã. Chỉ cần cho biện pháp tốt, bạn cũng đặt một điểm dừng trên dòng trên đó _myObj = CreateMyObj();, và thậm chí là một điểm dừng bên trong CreateMyObj()chính nó.

Mã đạt điểm dừng của bạn trên Dòng 3. Bạn bước vào mã. Bạn muốn nhập mã có điều kiện, vì _myObjrõ ràng là null, phải không? Uh ... vậy ... tại sao nó lại bỏ qua điều kiện và đi thẳng tới return _myObj?! Bạn di chuột qua _myObj ... và thực sự, nó có giá trị! Làm thế nào điều đó xảy ra?!

Câu trả lời là IDE của bạn khiến nó nhận được giá trị, bởi vì bạn mở cửa sổ "xem" - đặc biệt là cửa sổ đồng hồ "Ô tô", hiển thị các giá trị của tất cả các biến / thuộc tính có liên quan đến dòng thực thi hiện tại hoặc trước đó. Khi bạn đạt điểm dừng của mình trên Dòng 3, cửa sổ đồng hồ quyết định rằng bạn sẽ quan tâm để biết giá trị của MyObj- vì vậy, đằng sau hậu trường, bỏ qua bất kỳ điểm dừng nào của bạn , nó đã đi và tính giá trị của MyObjbạn - bao gồm cả cuộc gọi đến CreateMyObj()đó đặt giá trị của _myObj!

Đó là lý do tại sao tôi gọi đây là Cửa sổ Đồng hồ Heisenberg - bạn không thể quan sát giá trị mà không ảnh hưởng đến nó ... :)

GOTCHA!

Chỉnh sửa - Tôi cảm thấy bình luận của @ ChristianHayter xứng đáng được đưa vào câu trả lời chính, bởi vì nó có vẻ như là một cách giải quyết hiệu quả cho vấn đề này. Vì vậy, bất cứ lúc nào bạn có một tài sản tải lười biếng ...

Trang trí tài sản của bạn bằng [DebuggerBrowable (DebuggerBrowableState.Never)] hoặc [DebuggerDisplay ("<được tải theo yêu cầu>")]. - Christian Hayter

Đây là một lần khác có được tôi:

static void PrintHowLong(DateTime a, DateTime b)
{
    TimeSpan span = a - b;
    Console.WriteLine(span.Seconds);        // WRONG!
    Console.WriteLine(span.TotalSeconds);   // RIGHT!
}

TimeSpan.Seconds là phần giây của khoảng thời gian (2 phút và 0 giây có giá trị giây là 0).

TimeSpan.TotalSeconds là toàn bộ thời gian được tính bằng giây (2 phút có tổng giá trị giây là 120).

Rò rỉ bộ nhớ vì bạn đã không bỏ các sự kiện.

Điều này thậm chí đã bắt được một số nhà phát triển cao cấp mà tôi biết.

Hãy tưởng tượng một hình thức WPF có rất nhiều thứ trong đó, và ở đâu đó trong đó bạn đăng ký một sự kiện. Nếu bạn không hủy đăng ký thì toàn bộ biểu mẫu sẽ được giữ xung quanh trong bộ nhớ sau khi được đóng và hủy tham chiếu.

Tôi tin rằng vấn đề mà tôi đã thấy là tạo một DispatchTimer trong biểu mẫu WPF và đăng ký sự kiện Tick, nếu bạn không thực hiện - = trên bộ đếm thời gian biểu mẫu của bạn bị rò rỉ bộ nhớ!

Trong ví dụ này, mã phân tích của bạn nên có

timer.Tick -= TimerTickEventHandler;

Điều này đặc biệt khó khăn vì bạn đã tạo phiên bản của DispatchTimer bên trong biểu mẫu WPF, vì vậy bạn sẽ nghĩ rằng đó sẽ là một tham chiếu nội bộ được xử lý bởi quy trình Thu gom rác ... thật không may, DispatchTimer sử dụng danh sách đăng ký và dịch vụ nội bộ tĩnh các yêu cầu trên luồng UI, vì vậy tham chiếu được 'sở hữu' bởi lớp tĩnh.

Có thể không thực sự là một gotcha vì hành vi được viết rõ ràng trong MSDN, nhưng đã bị gãy cổ tôi một lần vì tôi thấy nó khá phản trực giác:

Image image = System.Drawing.Image.FromFile("nice.pic");

Anh chàng này để các "nice.pic"tập tin bị khóa cho đến khi hình ảnh được xử lý. Vào thời điểm tôi đối mặt với nó, mặc dù thật tuyệt khi tải các biểu tượng một cách nhanh chóng và không nhận ra (lúc đầu) tôi đã kết thúc với hàng tá tệp mở và bị khóa! Hình ảnh theo dõi nơi nó đã tải tệp từ ...

Làm thế nào để giải quyết điều này? Tôi nghĩ rằng một lót sẽ làm công việc. Tôi mong đợi một tham số bổ sung cho FromFile(), nhưng không có tham số nào, vì vậy tôi đã viết ...

using (Stream fs = new FileStream("nice.pic", FileMode.Open, FileAccess.Read))
{
    image = System.Drawing.Image.FromStream(fs);
}

Nếu bạn đếm ASP.NET, tôi sẽ nói rằng vòng đời của webforms là một vấn đề khá lớn đối với tôi. Tôi đã dành vô số giờ để gỡ lỗi mã webforms được viết kém, chỉ vì nhiều nhà phát triển thực sự không hiểu khi nào nên sử dụng trình xử lý sự kiện nào (bao gồm cả tôi, đáng buồn thay).

quá tải == toán tử và các container chưa được xử lý (danh sách mảng, bộ dữ liệu, v.v.):

string my = "my ";
Debug.Assert(my+"string" == "my string"); //true

var a = new ArrayList();
a.Add(my+"string");
a.Add("my string");

// uses ==(object) instead of ==(string)
Debug.Assert(a[1] == "my string"); // true, due to interning magic
Debug.Assert(a[0] == "my string"); // false

Các giải pháp?

• luôn luôn sử dụng string.Equals(a, b)khi bạn so sánh các loại chuỗi

• sử dụng khái quát như List<string>để đảm bảo rằng cả hai toán hạng là chuỗi.

[Serializable]
class Hello
{
    readonly object accountsLock = new object();
}

//Do stuff to deserialize Hello with BinaryFormatter
//and now... accountsLock == null ;)

Đạo đức của câu chuyện: Trình khởi tạo trường không được chạy khi khử lưu trữ đối tượng

DateTime.ToString ("dd / MM / yyyy") ; Điều này thực sự sẽ không phải lúc nào cũng cung cấp cho bạn dd / MM / yyyy mà thay vào đó, nó sẽ tính đến các cài đặt khu vực và thay thế dấu phân cách ngày của bạn tùy thuộc vào vị trí của bạn. Vì vậy, bạn có thể nhận được dd-MM-yyyy hoặc một cái gì đó tương tự.

Cách đúng đắn để làm điều này là sử dụng DateTime.ToString ("dd '/' MM '/' yyyy");

DateTime.ToString ("r") được cho là chuyển đổi thành RFC1123, sử dụng GMT. GMT nằm trong một phần của giây từ UTC và tuy nhiên, chỉ định định dạng "r" không chuyển đổi sang UTC , ngay cả khi DateTime trong câu hỏi được chỉ định là Cục bộ.

Điều này dẫn đến gotcha sau (thay đổi tùy theo thời gian địa phương của bạn đến từ UTC):

DateTime.Parse("Tue, 06 Sep 2011 16:35:12 GMT").ToString("r")
>              "Tue, 06 Sep 2011 17:35:12 GMT"

Rất tiếc!

Tôi đã thấy cái này được đăng vào một ngày khác và tôi nghĩ nó khá mơ hồ và đau đớn cho những người không biết

int x = 0;
x = x++;
return x;

Vì điều đó sẽ trả về 0 chứ không phải 1 như hầu hết mong đợi

Tôi đến bữa tiệc này hơi muộn, nhưng tôi có hai chú chó vừa cắn tôi gần đây:

Độ phân giải DateTime

Thuộc tính Ticks đo thời gian trong 10 phần triệu giây (khối 100 nano giây), tuy nhiên độ phân giải không phải là 100 nano giây, khoảng 15ms.

Mã này:

long now = DateTime.Now.Ticks;
for (int i = 0; i < 10; i++)
{
    System.Threading.Thread.Sleep(1);
    Console.WriteLine(DateTime.Now.Ticks - now);
}

sẽ cung cấp cho bạn một đầu ra của (ví dụ):

0
0
0
0
0
0
0
156254
156254
156254

Tương tự, nếu bạn xem DateTime.Now.Millisecond, bạn sẽ nhận được các giá trị trong các khối tròn 15.625ms: 15, 31, 46, v.v.

Hành vi đặc biệt này thay đổi tùy theo hệ thống , nhưng có các vấn đề khác liên quan đến độ phân giải trong API ngày / giờ này.

Path.Combine

Một cách tuyệt vời để kết hợp các đường dẫn tệp, nhưng nó không phải lúc nào cũng hoạt động theo cách bạn mong đợi.

Nếu tham số thứ hai bắt đầu bằng một \ký tự, nó sẽ không cung cấp cho bạn một đường dẫn hoàn chỉnh:

Mã này:

string prefix1 = "C:\\MyFolder\\MySubFolder";
string prefix2 = "C:\\MyFolder\\MySubFolder\\";
string suffix1 = "log\\";
string suffix2 = "\\log\\";

Console.WriteLine(Path.Combine(prefix1, suffix1));
Console.WriteLine(Path.Combine(prefix1, suffix2));
Console.WriteLine(Path.Combine(prefix2, suffix1));
Console.WriteLine(Path.Combine(prefix2, suffix2));

Cung cấp cho bạn đầu ra này:

C:\MyFolder\MySubFolder\log\
\log\
C:\MyFolder\MySubFolder\log\
\log\

Khi bạn bắt đầu một quá trình (sử dụng System.Diagnostics) ghi vào bảng điều khiển, nhưng bạn không bao giờ đọc luồng Console.Out, sau một lượng đầu ra nhất định, ứng dụng của bạn sẽ xuất hiện.

Không có phím tắt toán tử trong Linq-To-Sql

Xem ở đây .

Nói tóm lại, bên trong mệnh đề điều kiện của truy vấn Linq-To-Sql, bạn không thể sử dụng các phím tắt có điều kiện như ||và &&để tránh các ngoại lệ tham chiếu null; Linq-To-Sql đánh giá cả hai mặt của toán tử OR hoặc AND ngay cả khi điều kiện thứ nhất không cần phải đánh giá điều kiện thứ hai!

Sử dụng tham số mặc định với phương thức ảo

abstract class Base
{
    public virtual void foo(string s = "base") { Console.WriteLine("base " + s); }
}

class Derived : Base
{
    public override void foo(string s = "derived") { Console.WriteLine("derived " + s); }
}

...

Base b = new Derived();
b.foo();

Đầu ra:
cơ sở dẫn xuất

Các đối tượng giá trị trong các bộ sưu tập có thể thay đổi

struct Point { ... }
List<Point> mypoints = ...;

mypoints[i].x = 10;

không có hiệu lực.

mypoints[i]trả về một bản sao của một Pointđối tượng giá trị. C # vui vẻ cho phép bạn sửa đổi một trường của bản sao. Âm thầm không làm gì cả.

Cập nhật: Điều này dường như được sửa trong C # 3.0:

Cannot modify the return value of 'System.Collections.Generic.List<Foo>.this[int]' because it is not a variable

Có lẽ không phải là tồi tệ nhất, nhưng một số phần của khung .net sử dụng độ trong khi những phần khác sử dụng radian (và tài liệu xuất hiện với Intellisense không bao giờ cho bạn biết, bạn phải truy cập MSDN để tìm hiểu)

Tất cả điều này có thể tránh được bằng cách có một Anglelớp thay vào đó ...

Đối với các lập trình viên C / C ++, việc chuyển đổi sang C # là một điều tự nhiên. Tuy nhiên, vấn đề lớn nhất mà tôi gặp phải cá nhân (và đã thấy với những người khác thực hiện cùng một quá trình chuyển đổi) là không hiểu đầy đủ về sự khác biệt giữa các lớp và cấu trúc trong C #.

Trong C ++, các lớp và cấu trúc giống hệt nhau; chúng chỉ khác nhau về khả năng hiển thị mặc định, trong đó các lớp mặc định là khả năng hiển thị riêng tư và cấu trúc mặc định thành khả năng hiển thị công khai. Trong C ++, định nghĩa lớp này

    class A
    {
    public:
        int i;
    };

là chức năng tương đương với định nghĩa cấu trúc này.

    struct A
    {
        int i;
    };

Tuy nhiên, trong C #, các lớp là các kiểu tham chiếu trong khi các cấu trúc là các loại giá trị. Điều này làm cho một LỚN khác biệt trong (1) quyết định khi nào nên sử dụng cái này so với cái kia, (2) kiểm tra sự bình đẳng của đối tượng, (3) hiệu suất (ví dụ: đấm bốc / bỏ hộp), v.v.

Có tất cả các loại thông tin trên web liên quan đến sự khác biệt giữa hai (ví dụ, ở đây ). Tôi rất khuyến khích bất cứ ai thực hiện quá trình chuyển đổi sang C # để ít nhất có kiến ​​thức làm việc về sự khác biệt và ý nghĩa của chúng.

Thu gom rác thải và vứt bỏ (). Mặc dù bạn không phải làm bất cứ điều gì để giải phóng bộ nhớ , bạn vẫn phải giải phóng tài nguyên thông qua Dispose (). Đây là một điều cực kỳ dễ quên khi bạn đang sử dụng WinForms hoặc theo dõi các đối tượng theo bất kỳ cách nào.

Mảng thực hiện IList

Nhưng đừng thực hiện nó. Khi bạn gọi Add, nó sẽ cho bạn biết rằng nó không hoạt động. Vậy tại sao một lớp thực hiện một giao diện khi nó không thể hỗ trợ nó?

Biên dịch, nhưng không hoạt động:

IList<int> myList = new int[] { 1, 2, 4 };
myList.Add(5);

Chúng tôi có vấn đề này rất nhiều, bởi vì serializer (WCF) biến tất cả các IList thành mảng và chúng tôi gặp lỗi thời gian chạy.

foreach vòng lặp phạm vi biến!

var l = new List<Func<string>>();
var strings = new[] { "Lorem" , "ipsum", "dolor", "sit", "amet" };
foreach (var s in strings)
{
    l.Add(() => s);
}

foreach (var a in l)
    Console.WriteLine(a());

in năm "amet", trong khi ví dụ sau hoạt động tốt

var l = new List<Func<string>>();
var strings = new[] { "Lorem" , "ipsum", "dolor", "sit", "amet" };
foreach (var s in strings)
{
    var t = s;
    l.Add(() => t);
}

foreach (var a in l)
    Console.WriteLine(a());

MS SQL Server không thể xử lý ngày trước năm 1753. Đáng kể, đó là không đồng bộ với DateTime.MinDatehằng số .NET , là 1/1/1. Vì vậy, nếu bạn cố gắng lưu ý, một ngày không đúng định dạng (như gần đây đã xảy ra với tôi trong nhập dữ liệu) hoặc đơn giản là ngày sinh của William the Conqueror, bạn sẽ gặp rắc rối. Không có cách giải quyết tích hợp cho việc này; nếu bạn có khả năng cần phải làm việc với ngày trước năm 1753, bạn cần phải viết cách giải quyết của riêng bạn.

Lincha bộ nhớ cache khó chịu

Xem câu hỏi của tôi dẫn đến khám phá này, và các blogger đã phát hiện ra vấn đề.

Nói tóm lại, DataContext giữ một bộ đệm của tất cả các đối tượng Linq-to-Sql mà bạn đã từng tải. Nếu bất kỳ ai khác thực hiện bất kỳ thay đổi nào đối với bản ghi mà bạn đã tải trước đó, bạn sẽ không thể lấy dữ liệu mới nhất, ngay cả khi bạn tải lại bản ghi một cách rõ ràng!

Điều này là do một thuộc tính được gọi ObjectTrackingEnabledtrên DataContext, theo mặc định là đúng. Nếu bạn đặt thuộc tính đó thành false, bản ghi sẽ được tải lại mỗi lần ... NHƯNG ... bạn không thể duy trì bất kỳ thay đổi nào đối với bản ghi đó với SendChanges ().

GOTCHA!

Hợp đồng trên Stream.Read là điều mà tôi đã thấy rất nhiều người gặp phải:

// Read 8 bytes and turn them into a ulong
byte[] data = new byte[8];
stream.Read(data, 0, 8); // <-- WRONG!
ulong data = BitConverter.ToUInt64(data);

Lý do là sai Stream.Read sẽ đọc tối đa số byte được chỉ định, nhưng hoàn toàn miễn phí chỉ đọc 1 byte, ngay cả khi 7 byte khác có sẵn trước khi kết thúc luồng.

Nó không giúp gì cho việc này trông rất giống với Stream.Write , được đảm bảo đã ghi tất cả các byte nếu nó trả về không có ngoại lệ. Nó cũng không giúp cho mã trên hoạt động gần như mọi lúc . Và tất nhiên, điều đó không giúp ích gì cho việc không có phương pháp thuận tiện, sẵn sàng để đọc chính xác N byte.

Vì vậy, để cắm lỗ hổng và tăng cường nhận thức về điều này, đây là một ví dụ về một cách chính xác để làm điều này:

    /// <summary>
    /// Attempts to fill the buffer with the specified number of bytes from the
    /// stream. If there are fewer bytes left in the stream than requested then
    /// all available bytes will be read into the buffer.
    /// </summary>
    /// <param name="stream">Stream to read from.</param>
    /// <param name="buffer">Buffer to write the bytes to.</param>
    /// <param name="offset">Offset at which to write the first byte read from
    ///                      the stream.</param>
    /// <param name="length">Number of bytes to read from the stream.</param>
    /// <returns>Number of bytes read from the stream into buffer. This may be
    ///          less than requested, but only if the stream ended before the
    ///          required number of bytes were read.</returns>
    public static int FillBuffer(this Stream stream,
                                 byte[] buffer, int offset, int length)
    {
        int totalRead = 0;
        while (length > 0)
        {
            var read = stream.Read(buffer, offset, length);
            if (read == 0)
                return totalRead;
            offset += read;
            length -= read;
            totalRead += read;
        }
        return totalRead;
    }

    /// <summary>
    /// Attempts to read the specified number of bytes from the stream. If
    /// there are fewer bytes left before the end of the stream, a shorter
    /// (possibly empty) array is returned.
    /// </summary>
    /// <param name="stream">Stream to read from.</param>
    /// <param name="length">Number of bytes to read from the stream.</param>
    public static byte[] Read(this Stream stream, int length)
    {
        byte[] buf = new byte[length];
        int read = stream.FillBuffer(buf, 0, length);
        if (read < length)
            Array.Resize(ref buf, read);
        return buf;
    }

Sự kiện

Tôi không bao giờ hiểu tại sao các sự kiện là một tính năng ngôn ngữ. Chúng rất phức tạp để sử dụng: bạn cần kiểm tra null trước khi gọi, bạn cần hủy đăng ký (chính mình), bạn không thể tìm ra ai đã đăng ký (ví dụ: tôi đã đăng ký chưa?). Tại sao không phải là một sự kiện chỉ là một lớp học trong thư viện? Cơ bản là chuyên ngành List<delegate>?

Hôm nay tôi đã sửa một lỗi đã trốn tránh trong một thời gian dài. Lỗi này là trong một lớp chung được sử dụng trong kịch bản đa luồng và trường int tĩnh được sử dụng để cung cấp khóa đồng bộ hóa miễn phí bằng cách sử dụng Khóa liên động. Lỗi được gây ra bởi vì mỗi lần khởi tạo của lớp chung cho một loại có tĩnh riêng. Vì vậy, mỗi luồng có trường tĩnh riêng và nó không được sử dụng khóa như dự định.

class SomeGeneric<T>
{
    public static int i = 0;
}

class Test
{
    public static void main(string[] args)
    {
        SomeGeneric<int>.i = 5;
        SomeGeneric<string>.i = 10;
        Console.WriteLine(SomeGeneric<int>.i);
        Console.WriteLine(SomeGeneric<string>.i);
        Console.WriteLine(SomeGeneric<int>.i);
    }
}

Cái này in 5 10 5

Số lượng có thể được đánh giá nhiều lần

Nó sẽ cắn bạn khi bạn có vô số người lười biếng và bạn lặp đi lặp lại hai lần và nhận được kết quả khác nhau. (hoặc bạn nhận được kết quả tương tự nhưng nó thực hiện hai lần không cần thiết)

Ví dụ, trong khi viết một bài kiểm tra nhất định, tôi cần một vài tệp tạm thời để kiểm tra logic:

var files = Enumerable.Range(0, 5)
    .Select(i => Path.GetTempFileName());

foreach (var file in files)
    File.WriteAllText(file, "HELLO WORLD!");

/* ... many lines of codes later ... */

foreach (var file in files)
    File.Delete(file);

Hãy tưởng tượng sự ngạc nhiên của tôi khi File.Delete(file)ném FileNotFound!!

Điều đang xảy ra ở đây là vô số lầnfiles lặp lại hai lần (kết quả từ lần lặp đầu tiên đơn giản là không được nhớ) và trên mỗi lần lặp mới, bạn sẽ gọi lạiPath.GetTempFilename() để bạn có được một tên tệp tạm thời khác.

Tất nhiên, giải pháp là háo hức liệt kê giá trị bằng cách sử dụng ToArray()hoặc ToList():

var files = Enumerable.Range(0, 5)
    .Select(i => Path.GetTempFileName())
    .ToArray();

Điều này thậm chí còn đáng sợ hơn khi bạn đang làm một cái gì đó đa luồng, như:

foreach (var file in files)
    content = content + File.ReadAllText(file);

và bạn tìm ra content.Lengthvẫn là 0 sau khi viết xong !! Sau đó, bạn bắt đầu kiểm tra nghiêm ngặt rằng bạn không có tình trạng chủng tộc khi .... sau một giờ lãng phí ... bạn đã nhận ra rằng đó chỉ là một điều nhỏ bé mà bạn đã quên ....

Chỉ tìm thấy một thứ kỳ lạ khiến tôi bị mắc kẹt trong một thời gian:

Bạn có thể tăng null cho một int nullable mà không cần đưa ra một đoạn trích và giá trị vẫn là null.

int? i = null;
i++; // I would have expected an exception but runs fine and stays as null

TextInfo textInfo = Thread.CurrentThread.CurrentCulture.TextInfo;

textInfo.ToTitleCase("hello world!"); //Returns "Hello World!"
textInfo.ToTitleCase("hElLo WoRld!"); //Returns "Hello World!"
textInfo.ToTitleCase("Hello World!"); //Returns "Hello World!"
textInfo.ToTitleCase("HELLO WORLD!"); //Returns "HELLO WORLD!"

Vâng, hành vi này được ghi lại, nhưng điều đó chắc chắn không làm cho nó đúng.