Son zamanlarda bir DateTimenesne ile çalışıyordum ve şöyle bir şey yazdım:

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

İçin intellisense dokümantasyon AddDays(), tarihe bir gün eklediğini söylüyor, ki aslında - bir gün eklenmiş bir tarih döndürüyor , bu yüzden şöyle yazmanız gerekiyor:

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

Bu beni daha önce birkaç kez ısırdı, bu yüzden en kötü C # gotchas katalog için yararlı olacağını düşündüm.

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

Blammo. Uygulamanız yığın izlemesi olmadan kilitleniyor. Her zaman olur.

( Alıcıda MyVarküçük harf yerine sermayeye dikkat edin myVar.)

Type.GetType

Bir sürü insanı ısırdığımı gördüm Type.GetType(string). Kendi montajlarındaki türler için neden işe yaradığını merak ediyorlar System.String, ancak bazıları gibi , ama değil System.Windows.Forms.Form. Cevap, sadece mevcut montajda ve içeriye bakmasıdır mscorlib.

Anonim yöntemler

C # 2.0, böyle kötü durumlara yol açan anonim yöntemler tanıttı:

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();
        }
    }
}

Ne yazdıracak? Tamamen programlamaya bağlıdır. 10 sayı basacaktır, ancak muhtemelen 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 yazdıramaz. Sorun, itemsilci oluşturma noktasında değeri değil, yakalanan değişken olmasıdır. Bu, doğru kapsamın ekstra bir yerel değişkeni ile kolayca çözülebilir:

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();
        }
    }
}

Yineleyici blokların ertelenmiş yürütülmesi

Bu "zavallı adamın birim testi" geçmiyor - neden olmasın?

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
        }
    }
}

Cevap, kodun kaynağı içindeki CapitalLetterskodun, yineleyicinin MoveNext()yöntemi ilk çağrılana kadar yürütülmediğidir .

Benim bazı diğer tuhaflıklar var brainteasers sayfa .

Yeniden fırlatma istisnaları

Çok sayıda yeni geliştirici alan bir gotcha, yeniden atma istisna semantiği.

Birçok zaman aşağıdaki gibi kod görüyorum

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

Sorun, yığın izini silmesi ve sorunları daha zor hale getirmesidir, çünkü istisnanın nereden kaynaklandığını izleyemezsiniz.

Doğru kod, argüman içermeyen throw ifadesidir:

catch(Exception)
{
    throw;
}

Veya istisnayı başka bir pakete sarmak ve orijinal yığın izlemesini almak için iç istisnayı kullanmak:

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

Heisenberg İzleme Penceresi

Bu, istek üzerine yüklenen şeyler yapıyorsanız sizi kötü bir şekilde ısıtabilir:

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

Şimdi bunu kullanarak başka bir yerde kodunuz olduğunu varsayalım:

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

Şimdi CreateMyObj()yönteminizde hata ayıklamak istiyorsunuz . Bu nedenle, koda adım atmak amacıyla yukarıdaki Satır 3'e bir kesme noktası koydunuz. Sadece iyi bir ölçü için, yukarıdaki çizgiye _myObj = CreateMyObj();bir kesme noktası ve hatta CreateMyObj()kendi içine bir kesme noktası koyabilirsiniz .

Kod, Satır 3'teki kesme noktanıza çarpar. Koşullu kodu girmeyi beklersiniz, çünkü _myObjaçıkçası boştur, değil mi? Ah ... yani ... neden koşulu atladı ve doğruca return _myObj?! Farenizi _myObj'ın üzerine getirin ... ve gerçekten de bir değeri var! Bu nasıl oldu?!

Cevap, IDE'nizin bir değer almasına neden olmasıdır, çünkü bir "izleme" pencereniz açıktır - özellikle geçerli veya önceki yürütme satırıyla ilgili tüm değişkenlerin / özelliklerin değerlerini görüntüleyen "Autos" izleme penceresi. Hat 3'teki kırılma noktanıza çarptığınızda, izleme penceresi, değerini bilmek isteyeceğinize karar verdi MyObj- bu yüzden perde arkasında kesme noktalarınızı görmezden geldi, gitti veMyObj sizin için - çağrısına dahil CreateMyObj()olduğu _myObj!

Bu yüzden Heisenberg Gözetleme Penceresi diyorum - değeri etkilemeden gözlemleyemezsiniz ... :)

ANLADIM!

Düzenle - @ ChristianHayter'in yorumunun ana cevaba dahil edilmeyi hak ettiğini hissediyorum, çünkü bu sorun için etkili bir geçici çözüm gibi görünüyor. Öyleyse tembel yüklü bir mülkünüz olduğunda ...

Mülkünüzü [DebuggerBrowsable (DebuggerBrowsableState.Never)] veya [DebuggerDisplay ("<istek üzerine yüklenir>")] ile dekore edin. - Christian Hayter

İşte beni alan başka bir zaman:

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

TimeSpan.Seconds , zaman aralığının saniye bölümüdür (2 dakika ve 0 saniye, 0 saniye değerine sahiptir).

TimeSpan.TotalSeconds , saniye cinsinden ölçülen tüm zaman aralığıdır (2 dakika toplam saniye değerine 120 sahiptir).

Hafıza sızıyor çünkü olayları açmadınız.

Bu bile biliyorum bazı üst düzey geliştiriciler yakaladı.

İçinde birçok şey bulunan bir WPF formu düşünün ve orada bir yerde bir etkinliğe abone olun. Aboneliği iptal etmezseniz, form kapatıldıktan ve referansı kaldırıldıktan sonra tüm form bellekte tutulur.

Gördüğüm sorun WPF formunda bir DispatchTimer oluşturmak ve Tick olayına abone oldu, zamanlayıcı üzerinde bir - = yapmazsanız formunuz bellek sızdırıyor inanıyorum!

Bu örnekte, ayırma kodunuz

timer.Tick -= TimerTickEventHandler;

WPF formunda DispatchTimer örneğini oluşturduğunuz için bu özellikle zordur, bu nedenle bunun Çöp Toplama işlemi tarafından işlenen dahili bir başvuru olacağını düşünürsünüz ... maalesef DispatchTimer statik bir dahili abonelik listesi ve hizmetleri listesi kullanır. UI iş parçacığı istekleri, bu nedenle başvuru statik sınıfa 'ait'.

Belki gerçekten bir gotcha değil çünkü davranış MSDN'de açıkça yazılmıştır, ancak oldukça sezgisel bulduğum için boynumu bir kez kırmıştır:

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

Bu adam "nice.pic"görüntü imha edilene kadar dosyayı kilitli bırakır . Karşı karşıya geldiğimde, simgeleri anında yüklemek güzel olurdu ve (ilk başta) düzinelerce açık ve kilitli dosya ile sonuçlandığımı fark etmedim! Görüntü dosyayı yüklediği yeri izler ...

Bunu nasıl çözebilirim? Bir astarın işi yapacağını düşündüm. Ben ekstra bir parametre bekleniyor FromFile(), ama hiçbiri yoktu, bu yüzden bu yazdı ...

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

ASP.NET'i sayarsanız, web formlarının yaşam döngüsünün benim için oldukça büyük bir sorun olduğunu söyleyebilirim. Birçok geliştirici sadece hangi olay işleyiciyi (ne yazık ki dahil) ne zaman kullanacağımı gerçekten anlamadığından, kötü yazılmış webformları kodunda hata ayıklamak için sayısız saat geçirdim.

aşırı yüklenmiş == operatörler ve türetilmemiş konteynerler (arraylistler, veri setleri vb.):

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

Çözümler?

• string.Equals(a, b)dize türlerini karşılaştırırken her zaman kullan

• List<string>her iki işlenenin de dize olmasını sağlamak için generics kullanmak .

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

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

Hikayenin ahlakı: Bir nesnenin serisini kaldırırken alan başlatıcıları çalıştırılmaz

DateTime.ToString ("gg / aa / yyyy") ; Bu aslında edecek değil her zaman / gg AA / yyyy ama bunun yerine nerede olduğunu bağlı olarak tarih ayırıcı dikkate bölgesel ayarları alıp yerini alacak verir. Böylece dd-AA-yyyy ya da benzer bir şey elde edebilirsiniz.

Bunu yapmanın doğru yolu DateTime.ToString ("dd '/' MM '/' yyyy") kullanmaktır;

DateTime.ToString ("r") , GMT kullanan RFC1123'e dönüştürülmelidir. GMT, UTC'den bir saniyeden daha kısa bir süredir , ancak söz konusu DateTime öğesi Yerel olarak belirtilse bile , "r" biçim belirleyicisi UTC'ye dönüştürülmez .

Bu, aşağıdaki sorcha ile sonuçlanır (yerel saatinizin UTC'den ne kadar olduğuna bağlı olarak değişir):

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

Tüh!

Bunu geçen gün yayınladığını gördüm ve bence bilmeyenler için oldukça karanlık ve acı verici

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

Bu çoğu beklendiği gibi 0 değil 1 döndürecektir

Bu partiye biraz geç kaldım, ama son zamanlarda beni ısırmış iki yakaladım:

DateTime çözünürlüğü

Ticks özelliği, saniyenin 10 milyonda birini (100 nanosaniye blok) ölçer, ancak çözünürlük 100 nanosaniye değildir, yaklaşık 15 ms'dir.

Bu kod:

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

size bir çıktı verecektir (örneğin):

0
0
0
0
0
0
0
156254
156254
156254

Benzer şekilde, DateTime.Now.Millisecond'a bakarsanız, 15.625 ms'lik yuvarlak parçalar halinde değerler alırsınız: 15, 31, 46, vb.

Bu özel davranış sistemden sisteme değişiklik gösterir , ancak bu tarih / saat API'sında çözümle ilgili başka öğeler de vardır.

Path.Combine

Dosya yollarını birleştirmenin harika bir yolu, ancak her zaman beklediğiniz gibi davranmaz.

İkinci parametre bir \karakterle başlarsa , size tam bir yol vermez:

Bu kod:

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));

Bu çıktıyı size verir:

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

Konsola yazılan bir işlemi başlattığınızda (System.Diagnostics kullanarak), ancak Console.Out akışını asla okumazsanız, belirli bir çıktıdan sonra uygulamanız askıda görünecektir.

Linq-To-Sql'de operatör kısayolu yok

Buraya bakın .

Kısacası, bir Linq-To-Sql sorgusunun koşullu yan tümcesinde, boş başvuru istisnalarını önlemek için ||ve gibi koşullu kısayolları kullanamazsınız &&; Linq-To-Sql, birinci koşul ikinci koşulu değerlendirme ihtiyacını ortadan kaldırsa bile OR veya AND operatörünün her iki tarafını da değerlendirir!

Varsayılan parametreleri sanal yöntemlerle kullanma

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();

Çıktı:
türetilmiş taban

Değişken koleksiyonlardaki değer nesneleri

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

mypoints[i].x = 10;

etkisi yoktur.

mypoints[i]Pointdeğer nesnesinin bir kopyasını döndürür . C # mutlu bir şekilde bir kopya alanı değiştirmenizi sağlar. Sessizce hiçbir şey yapmıyor.

Güncelleme: Bu C # 3.0 sabit gibi görünüyor:

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

Belki de en kötü değil, ancak .net çerçevesinin bazı bölümleri derece kullanırken diğerleri radyan kullanıyor (ve Intellisense ile görünür öğrenmek için MSDN ziyaret etmek zorunda olan söyler asla belgelerine)

Bütün bunlar Anglebunun yerine bir sınıfa sahip olmaktan kaçınabilirdi ...

C / C ++ programcıları için C # 'a geçiş doğaldır. Ancak, şahsen karşılaştığım en büyük gotcha (ve aynı geçişi yapan diğerleriyle gördüm) C # 'daki sınıflar ve yapılar arasındaki farkı tam olarak anlamak değildir.

C ++ 'da, sınıflar ve yapılar aynıdır; yalnızca sınıfların varsayılan olarak özel görünürlük ve yapıların varsayılan olarak genel görünürlük olarak ayarlandığı varsayılan görünürlükte farklılık gösterir. C ++ 'da, bu sınıf tanımı

    class A
    {
    public:
        int i;
    };

işlevsel olarak bu yapı tanımına eşdeğerdir.

    struct A
    {
        int i;
    };

Ancak C # 'da, sınıflar başvuru tipleridir, yapılar ise değer tipleridir. Bu BÜYÜK (1) amacı, eşitlik test üst üste, (2) kullanmak, karar vermek, (3) performans (örneğin, boks / kutusu açma) vb farkı

Web'de ikisi arasındaki farklarla ilgili her türlü bilgi vardır (örneğin, burada ). En azından farklılıklar ve etkileri hakkında çalışma bilgisine sahip olmak için C # 'a geçiş yapan herkesi şiddetle tavsiye ederim.

Çöp toplama ve atma (). Belleği boşaltmak için hiçbir şey yapmanıza gerek olmasa da , hala Dispose () aracılığıyla kaynakları boşaltmanız gerekir . Bu, WinForms'u kullanırken veya herhangi bir şekilde nesneleri izlerken unutulması son derece kolay bir şeydir.

Diziler uygulamak IList

Ama bunu uygulama. Add'i çağırdığınızda, size çalışmadığını söyler. Öyleyse sınıf neden bir arabirimi destekleyemediğinde uygular?

Derler, ancak çalışmaz:

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

Bu sorun çok fazla, çünkü serileştirici (WCF) tüm IListleri dizilere dönüştürüyor ve çalışma zamanı hataları alıyoruz.

foreach döngü değişkenleri kapsamı!

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());

beş "amet" yazdırırken, aşağıdaki örnek iyi çalışıyor

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, 1753'ten önceki tarihleri ​​işleyemez DateTime.MinDate. Dolayısıyla, bir mindatı, hatalı biçimlendirilmiş bir tarihi (yakın zamanda veri aktarımında başıma geldi) veya sadece Fatih William'ın doğum tarihini kaydetmeye çalışırsanız, başınız belada olacak. Bunun için yerleşik bir çözüm yoktur; 1753'ten önceki tarihlerle çalışmanız gerekiyorsa, kendi geçici çözümünüzü yazmanız gerekir.

Kötü linq önbellekleme gotcha

Bkz sorumu bu keşif yol açtığını ve blogcu sorunu keşfetti.

Kısacası, DataContext, daha önce yüklediğiniz tüm Linq-Sql nesnelerinin önbelleğini tutar. Daha önce yüklediğiniz bir kayıtta başka herhangi bir değişiklik yaparsa, en son verileri alamazsınız, yaparsa, kaydı açıkça yeniden olsanız bile alamazsınız!

Bunun nedeni, ObjectTrackingEnabledvarsayılan olarak true olan DataContext üzerinde çağrılan bir özelliktir . Bu özelliği false olarak ayarlarsanız, kayıt her seferinde yeniden yüklenir ... AMA ... SubmitChanges () ile kayıtta herhangi bir değişiklik yapamazsınız.

ANLADIM!

Stream.Read ile ilgili sözleşme, birçok insanın yolculuğunu gördüğüm bir şey:

// 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);

Bunun yanlış olmasının nedeni , en fazla belirtilen bayt sayısını Stream.Readokuyacağı , ancak akış bitmeden önce başka bir 7 bayt bulunsa bile, yalnızca 1 baytı okumakta tamamen ücretsiz olmasıdır .

O kadar benzer bu görünümün onun yardım etmez Stream.Write, olduğu hiçbir istisna ile dönerse garantili tüm bayt yazdım etmek. Ayrıca yukarıdaki kodun neredeyse her zaman çalışmasına yardımcı olmaz . Ve elbette N baytlarını doğru bir şekilde okumak için hazır ve kullanışlı bir yöntemin bulunmamasına yardımcı olmaz.

Yani, deliği tıkamak ve bunun farkındalığını arttırmak için, bunu yapmanın doğru bir yol örneği:

    /// <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;
    }

Etkinlikler

Olayların neden bir dil özelliği olduğunu hiç anlamadım. Kullanımı karmaşıktır: aramadan önce null olup olmadığını kontrol etmeniz gerekir, kaydını silmeniz gerekir (kendiniz), kimin kayıtlı olduğunu bulamazsınız (örneğin: kayıt oldum mu?). Bir olay neden sadece kütüphanedeki bir sınıf değil? Temelde bir uzman List<delegate>?

Bugün uzun süre kaçan bir hatayı düzelttim. Hata, çok iş parçacıklı senaryoda kullanılan genel bir sınıftaydı ve Interlocked kullanarak kilitsiz eşitleme sağlamak için statik bir int alanı kullanıldı. Hata, bir tür için genel sınıfın her örneğinin kendi statikine sahip olmasından kaynaklandı. Böylece her iş parçacığının kendi statik alanı vardır ve istendiği gibi bir kilit kullanılmamıştır.

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);
    }
}

Bu baskı 5 10 5

Numaralandırıcılar bir kereden fazla değerlendirilebilir

Tembel olarak numaralandırılmış bir numaralandırmanız olduğunda sizi ısırır ve iki kez tekrarlar ve farklı sonuçlar alırsınız. (veya aynı sonuçları alırsınız ancak gereksiz yere iki kez çalışır)

Örneğin, belirli bir testi yazarken, mantığı test etmek için birkaç geçici dosyaya ihtiyacım vardı:

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);

Sürprizimi ne zaman hayal et File.Delete(file) atarFileNotFound !!

Burada olan, filesnumaralandırılabilir olanın iki kez yinelenmesidir (ilk yinelemenin sonuçları basitçe değil hatırladı) ve her yeni tekrarında Eğer yeniden arayarak olurdu Path.GetTempFilename()Eğer geçici dosya adları farklı bir dizi alırsınız.

Çözüm, elbette, ToArray()veya kullanarak değeri istekli olarak numaralandırmaktır ToList():

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

Çok iş parçacıklı bir şey yaptığınızda bu daha da korkutucu:

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

ve sen content.Lengthtüm yazmadan sonra hala 0 olduğunu bulmak !! O zaman bir yarış koşulu olmadığını titizlikle kontrol etmeye başlar .... bir saat boşa sonra ... sadece unuttum o küçük küçük Numaralandırılabilir gotcha şey anladım ....

Sadece bir süre hata ayıklamada sıkışmış garip bir tane buldum:

Bir dışlama atmadan boş bir int için null değerini artırabilirsiniz ve değer null olarak kalır.

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!"

Evet, bu davranış belgelenmiştir, ancak bu kesinlikle doğru değildir.