私は最近DateTimeオブジェクトを操作していて、次のようなものを書きました：

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

のintellisenseのドキュメントでAddDays()は、日付に1日を追加しますが、実際には追加しません。実際には、日付を追加した日付を返すため、次のように記述する必要があります。

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

これは以前に何度も私をかみましたので、最悪のC＃の落とし穴をカタログ化すると便利だと思いました。

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

ブラモ。アプリはスタックトレースなしでクラッシュします。いつも起こります。

（ゲッターMyVarでは小文字myVarではなく大文字に注意してください。）

Type.GetType

たくさんの人に噛まれたのを見たことがあるType.GetType(string)。彼らはなぜそれが独自のアセンブリの型に対して機能するのか、のような一部の型に対して機能するのか疑問に思ってSystem.StringいSystem.Windows.Forms.Formます。答えは、現在のアセンブリとのみを検索することmscorlibです。

匿名メソッド

C＃2.0は匿名メソッドを導入し、次のような厄介な状況を引き起こしました。

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

それは何を出力しますか？まあ、それは完全にスケジュールに依存します。10個の数値が出力されますが、おそらく0、1、2、3、4、5、6、7、8、9は出力されないでしょう。問題はi、デリゲートの作成時点での値ではなく、取得された変数であることです。これは、適切なスコープの追加のローカル変数で簡単に解決できます。

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

イテレータブロックの遅延実行

この「貧乏人の単体テスト」はパスしません-なぜパスしないのですか？

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

答えは、コードのソース内のCapitalLettersコードは、イテレータのMoveNext()メソッドが最初に呼び出されるまで実行されないということです。

私の頭の体操のページに他のいくつかの奇妙な点があります。

例外の再スロー

多くの新規開発者を獲得する落とし穴は、再スロー例外セマンティクスです。

多くの場合、次のようなコードが表示されます

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

問題は、スタックトレースを消去し、問題の診断をはるかに困難にすることです。これにより、例外の発生場所を追跡できなくなります。

正しいコードは、引数のないthrowステートメントです。

catch(Exception)
{
    throw;
}

または、例外を別の例外でラップし、内部例外を使用して元のスタックトレースを取得します。

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

ハイゼンベルク時計ウィンドウ

これは、次のようにロードオンデマンドの処理を実行している場合、ひどく噛みつくことがあります。

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

ここで、これを使用している別のコードがあるとします。

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

次に、CreateMyObj()メソッドをデバッグします。したがって、コードにステップインするつもりで、上の行3にブレークポイントを配置します。ちょうどいいことですが、上の行にブレークポイントを設定し、_myObj = CreateMyObj();さらにその中にブレークポイントを設定しCreateMyObj()ます。

コードは3行目のブレークポイントにヒットします。コードにステップインします。_myObj明らかにnull なので、条件付きコードを入力することを期待していますか？ええと...それで...なぜ条件をスキップして直進したのreturn _myObjですか？マウスを_myObj ...の上に置くと、確かに値があります。どうしてこうなりました？！

答えは、「監視」ウィンドウが開いているため、IDEが値を取得したためです。特に、「自動」監視ウィンドウには、現在または前の実行行に関連するすべての変数/プロパティの値が表示されます。3行目でブレークポイントに到達したとき、ウォッチウィンドウは次の値を知りたいと思っていると判断しましたMyObj-舞台裏では、ブレークポイントを無視して、値を計算しましたMyObj-その呼び出しを含めCreateMyObj()て_myObjの値を設定します！

これが私がこれをハイゼンベルクウォッチウィンドウと呼んでいる理由です。影響を与えずに値を観察することはできません... :)

GOTCHA！

編集 -@ChristianHayterのコメントは、この問題の効果的な回避策のように見えるので、メインの回答に含めるに値すると思います。したがって、遅延ロードされたプロパティがあるときはいつでも...

[DebuggerBrowsable（DebuggerBrowsableState.Never）]または[DebuggerDisplay（ "<ロードオンデマンド>"）]でプロパティを装飾します。–クリスチャンヘイター

ここに私を捕まえる別の時があります：

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

TimeSpan.Secondsは、タイムスパンの秒の部分です（2分0秒の秒の値は0です）。

TimeSpan.TotalSecondsは、秒単位で測定されるタイムスパン全体です（2分の合計秒の値は120です）。

イベントのフックを解除しなかったため、メモリがリークしています。

これは、私が知っている一部の上級開発者をも引き付けました。

たくさんのものが入っているWPFフォームを想像してみてください。そして、どこかでイベントにサブスクライブしています。購読を解除しないと、フォーム全体が閉じられ、参照が解除された後もメモリ内に保持されます。

私が見た問題は、WPFフォームでDispatchTimerを作成し、Tickイベントにサブスクライブしたことです。タイマーで-=を実行しないと、フォームでメモリリークが発生します。

この例では、ティアダウンコードは

timer.Tick -= TimerTickEventHandler;

WPFフォーム内にDispatchTimerのインスタンスを作成したため、これは特にトリッキーです。ガベージコレクションプロセスによって処理される内部参照であると思われます...残念ながら、DispatchTimerはサブスクリプションとサービスの静的内部リストを使用しますUIスレッドでリクエストを送信するため、参照は静的クラスによって「所有」されます。

動作はMSDNで明確に記述されているため、実際には問題ではないかもしれませんが、直感に反していることがわかったため、一度首を折れました。

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

この男は去ります "nice.pic"画像が破棄されるまでファイルをロックしたます。当時、私はそれに直面していましたが、その場でアイコンをロードするのは良いことですが、最初は何十もの開いていてロックされているファイルがあることに気づきませんでした。画像はどこからファイルをロードしたかを追跡します...

これを解決するには？ワンライナーで十分だと思いました。に追加のパラメーターを期待していましたが、パラメーターFromFile()がなかったため、これを記述しました...

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

ASP.NETを数えるなら、Webフォームのライフサイクルは私にとってかなり大きな問題だと思います。多くの開発者がどのイベントハンドラーを使用するか（本当に残念なことに）をいつ使用するか本当に理解していないため、私は数え切れないほどの時間を費やしてWebフォームのコードをデバッグしました。

オーバーロードされた==演算子と型なしコンテナ（配列リスト、データセットなど）：

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

ソリューション？

• string.Equals(a, b)文字列型を比較するときは常に使用します

• ジェネリックList<string>を使用して、両方のオペランドが文字列であることを確認します。

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

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

ストーリーのモラル：オブジェクトを逆シリアル化するときにフィールド初期化子が実行されない

DateTime.ToString（ "dd / MM / yyyy"） ; これは実際には常にdd / MM / yyyyを与えるわけではありませんが、代わりに地域設定を考慮し、現在の場所に応じて日付の区切り文字を置き換えます。そのため、dd-MM-yyyyまたは同様のものを取得する可能性があります。

これを行う正しい方法は、DateTime.ToString（ "dd '/' MM '/' yyyy"）;を使用することです。

DateTime.ToString（ "r"）は、GMTを使用するRFC1123に変換することになっています。GMTはUTCから数分の1秒以内ですが、問題のDateTimeがLocalとして指定されている場合でも、「r」フォーマット指定子はUTCに変換されません。

その結果、次のような問題が発生します（現地時間とUTCの距離によって異なります）。

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

おっと！

これは先日投稿されたのを見たけど、それはかなりあいまいで、知らない人にとっては苦痛だと思う

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

それはほとんどが期待するような1ではなく0を返すので

私はこのパーティーに少し遅れましたが、私は最近両方とも私を噛んだ2つの落とし穴があります：

日時解決

Ticksプロパティは、100万分の1秒（100ナノ秒ブロック）単位で時間を測定しますが、解像度は100ナノ秒ではなく、約15ミリ秒です。

このコード：

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

（たとえば）の出力が得られます：

0
0
0
0
0
0
0
156254
156254
156254

同様に、DateTime.Now.Millisecondを見ると、15.625ミリ秒（15、31、46など）の丸められたチャンクで値を取得します。

この特定の動作はシステムによって異なりますが、この日付/時刻API には他の解決に関連する問題があります。

Path.Combine

ファイルパスを組み合わせる優れた方法ですが、常に期待どおりに動作するとは限りません。

2番目のパラメーターが\文字で始まる場合、完全なパスは提供されません。

このコード：

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

次の出力が得られます。

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

コンソールに書き込むプロセスを（System.Diagnosticsを使用して）開始したが、Console.Outストリームを読み取らなかった場合、一定量の出力の後、アプリがハングしているように見えます。

Linq-To-Sqlには演算子のショートカットはありません

こちらをご覧ください。

つまり、Linq-To-Sqlクエリの条件句内では、||およびのような条件付きショートカットを使用して&&null参照例外を回避することはできません。Linq-To-Sqlは、最初の条件で2番目の条件を評価する必要がなくても、ORまたはAND演算子の両側を評価します。

仮想メソッドでのデフォルトパラメータの使用

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

出力：
派生ベース

変更可能なコレクションの値オブジェクト

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

mypoints[i].x = 10;

効果はありません。

mypoints[i]Point値オブジェクトのコピーを返します。C＃では、コピーのフィールドを変更できます。黙って何もしない。

更新： これはC＃3.0で修正されたようです。

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

おそらく最悪ではないかもしれませんが、.netフレームワークの一部は度を使用していますが、他の部分はラジアンを 使用しています（そしてIntellisenseに表示されるドキュメントではどちらが表示されるかはわかりません。MSDNにアクセスして調べる必要があります）。

これはすべて、Angle代わりにクラスを用意することで回避できました...

C / C ++プログラマーにとって、C＃への移行は自然なことです。ただし、私が個人的に遭遇した（そして他の人が同じ移行を行っているのを見た）最大の落とし穴は、C＃のクラスと構造体の違いを完全に理解することではありません。

C ++では、クラスと構造体は同じです。デフォルトの可視性のみが異なり、クラスのデフォルトはプライベートな可視性、構造体のデフォルトはパブリックな可視性です。C ++では、このクラス定義

    class A
    {
    public:
        int i;
    };

機能的には、この構造体の定義と同等です。

    struct A
    {
        int i;
    };

ただし、C＃では、クラスは参照型であり、構造体は値型です。これは作るビッグ（1）オブジェクトの等価性をテストする他の上の1つ、（2）を使用する場合を決定する、（3）の性能（例えば、ボクシング/アンボクシング）などの差を

両者の違いに関連するあらゆる種類の情報がウェブ上にあります（例：ここ）。C＃への移行を行うすべての人に、少なくとも違いとその影響についての実用的な知識があることを強くお勧めします。

ガベージコレクションとDispose（）。メモリを解放するために何もする必要はありませんが、Dispose（）を介してリソースを解放する必要があります。これは、WinFormsを使用しているとき、または何らかの方法でオブジェクトを追跡しているときに忘れることが非常に簡単なことです。

配列の実装 IList

ただし、実装しないでください。Addを呼び出すと、機能しないことが通知されます。では、クラスがインターフェースをサポートできないのに、なぜインターフェースを実装するのでしょうか。

コンパイルしますが、機能しません。

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

シリアライザー（WCF）がすべてのIListsを配列に変換し、ランタイムエラーが発生するため、この問題はたくさんあります。

foreachは変数スコープをループします！

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

5つの「amet」を出力しますが、次の例は正常に機能します

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より前の日付を処理できません。重要なことにDateTime.MinDate、これは.NET 定数（1/1/1）と同期していません。したがって、気がかりな日付、不正な日付（最近、データインポートで起こったようなもの）、または単にウィリアム征服王の誕生日を保存しようとすると、問題が発生します。このための組み込みの回避策はありません。1753年より前の日付で作業する必要がある場合は、独自の回避策を作成する必要があります。

厄介なLinq Caching Gotcha

この発見につながった私の質問と、問題を発見したブロガーを参照してください。

つまり、DataContextは、これまでにロードしたすべてのLinq-to-Sqlオブジェクトのキャッシュを保持します。以前にロードしたレコードを他の誰かが変更した場合、レコードを明示的に再ロードしても、最新のデータを取得できません！

これはObjectTrackingEnabled、デフォルトではtrueであるDataContextで呼び出されるプロパティが原因です。あなたがfalseにそのプロパティを設定した場合、レコードは改めてたびにロードされます... しかし、あなたがでSubmitChangesとそのレコードへの変更を永続化することはできません...（）。

GOTCHA！

Stream.Readの契約は、私が多くの人をつまずかせるのを見てきました。

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

これは間違っている理由は、それがあるStream.Read読み込みます、最大で指定されたバイト数を、しかしである、完全無料の別の7つのバイトは、ストリームの終了前に利用可能である場合でも、ちょうど1バイトを読み取ります。

それはに非常に類似したこのルックスことを助けないStream.Write、され、それは例外なく返した場合の保証は、すべてのバイトを書かれているし。また、上記のコードがほとんど常に機能することも役に立ちません。そしてもちろん、正確にNバイトを正確に読み取るための既製の便利な方法がないことは役に立ちません。

そのため、穴を塞ぎ、これに対する認識を高めるために、これを行う正しい方法の例を次に示します。

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

イベント

イベントが言語機能である理由を理解できませんでした。それらは使い方が複雑です。呼び出す前にnullを確認する必要があり、登録を解除する必要があります（自分自身）。なぜイベントがライブラリのクラスではないのですか？基本的には専門List<delegate>ですか？

今日、私は長い間回避されていたバグを修正しました。このバグは、マルチスレッドシナリオで使用されているジェネリッククラスにあり、Interlockedを使用してロックのない同期を提供するために静的intフィールドが使用されていました。型の総称クラスのインスタンス化ごとに独自の静的があるため、バグが発生しました。したがって、各スレッドは独自の静的フィールドを取得し、意図したとおりにロックを使用していませんでした。

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

これは5 10 5を印刷します

列挙型は複数回評価できます

遅延列挙型の列挙可能オブジェクトがあり、それを2回繰り返して異なる結果が得られると、噛み付くでしょう。（または同じ結果が得られますが、不必要に2回実行されます）

たとえば、特定のテストを作成しているときに、ロジックをテストするためにいくつかの一時ファイルが必要でした。

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

File.Delete(file)投げるときの驚きを想像してみてくださいFileNotFound!!

何ここで起こってはということですfiles列挙GOTは、反復二回（最初の反復の結果を単純にされていない覚えて）、あなたが再呼び出しされると思い、新しい各反復でPath.GetTempFilename()あなたは一時ファイル名の異なるセットを買ってあげるようにします。

解決策はもちろん、ToArray()またはを使用して値を熱心に列挙することですToList()：

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

次のようなマルチスレッドを実行している場合、これはさらに恐ろしいことです。

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

そして、あなたcontent.Lengthはすべての書き込みの後にまだ0であることがわかります!! 次に、競合状態がないことを厳密にチェックし始めます。1時間無駄にした後...それは、あなたが忘れた小さな小さな列挙可能なものだけであることがわかりました。

しばらく私をデバッグさせてしまった奇妙なものを見つけました：

例外をスローせずにnull可能なintのnullをインクリメントしても、値は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!"

はい、この動作は文書化されていますが、それで間違いなく正しくなるわけではありません。