Я недавно работал с DateTimeобъектом и написал что-то вроде этого:

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

В документации по intellisense AddDays()говорится, что она добавляет день к дате, а это не так - фактически она возвращает дату с добавленным днем, поэтому вы должны написать ее следующим образом:

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

Этот укусил меня несколько раз прежде, поэтому я подумал, что было бы полезно занести в каталог худшие ошибки C #.

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

Blammo. Ваше приложение падает без трассировки стека. Бывает все время.

(Обратите внимание на заглавные 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он явно равен нулю, верно? Э-э ... так ... почему оно пропустило условие и сразу пошло return _myObj?! Вы наводите указатель мыши на _myObj ... и это действительно имеет значение! Как это произошло?!

Ответ в том, что ваша IDE заставила его получить значение, потому что у вас открыто окно «watch» - особенно окно «Autos», которое отображает значения всех переменных / свойств, относящихся к текущей или предыдущей строке выполнения. Когда вы достигли своей точки останова в строке 3, окно наблюдения решило, что вам будет интересно узнать значение MyObj- так что за кулисами, игнорируя любую из ваших точек останова , оно пошло и вычислило значение MyObjдля вас - включая вызов CreateMyObj()этого устанавливает значение _myObj!

Вот почему я называю это Окно часов Гейзенберга - вы не можете наблюдать значение, не влияя на него ... :)

ПОПАЛСЯ!

Редактировать - я считаю, что комментарий @ 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 с множеством вещей, и где-то там вы подписываетесь на событие. Если вы не отмените подписку, тогда вся форма будет храниться в памяти после закрытия и разыменования.

Я полагаю, что проблема, которую я видел, заключалась в создании DispatchTimer в форме WPF и подписке на событие Tick, если вы не сделаете - = в таймере, ваша форма утечка памяти!

В этом примере ваш код разрыва должен иметь

timer.Tick -= TimerTickEventHandler;

Это особенно сложно, поскольку вы создали экземпляр DispatchTimer внутри формы WPF, поэтому вы могли бы подумать, что это будет внутренняя ссылка, обрабатываемая процессом сборки мусора ... к сожалению, DispatchTimer использует статический внутренний список подписок и служб запросы в потоке пользовательского интерфейса, поэтому ссылка «принадлежит» статическому классу.

Возможно, на самом деле это не уловка, потому что поведение написано четко в 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, я бы сказал, что жизненный цикл веб-форм - это довольно большой вопрос для меня. Я потратил бесчисленные часы на отладку плохо написанного кода веб-форм только потому, что многие разработчики просто не понимают, когда использовать какой обработчик событий (включая меня, к сожалению).

перегруженные операторы == и нетипизированные контейнеры (массивы, наборы данных и т. д.):

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 ("дд / мм / гггг") ; На самом деле это не всегда даст вам дд / мм / гггг, но вместо этого он будет учитывать региональные настройки и заменять разделитель даты в зависимости от того, где вы находитесь. Таким образом, вы можете получить дд-мм-гггг или что-то подобное.

Правильный способ сделать это - использовать DateTime.ToString ("dd '/' MM '/' yyyy");

DateTime.ToString ("r") должен преобразовываться в RFC1123, который использует GMT. Время по Гринвичу составляет доли секунды от UTC, и все же спецификатор формата «r» не преобразуется в UTC , даже если рассматриваемый DateTime указан как Local.

Это приводит к следующей ошибке (зависит от того, как далеко ваше местное время от 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;

Так как это вернет 0, а не 1, как многие ожидали бы

Я немного опоздал на эту вечеринку, но у меня есть две ошибки, которые недавно меня укусили:

DateTime разрешение

Свойство Ticks измеряет время в 10 миллионных долях секунды (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

Отличный способ объединить пути к файлам, но он не всегда ведет себя так, как вы ожидаете.

Если второй параметр начинается с \символа, он не даст вам полный путь:

Этот код:

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 нельзя использовать условные ярлыки, такие как ||и, &&чтобы избежать исключений с нулевой ссылкой; Linq-To-Sql оценивает обе стороны оператора 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 Framework используют градусы, в то время как другие используют радианы (и документация, которая появляется с Intellisense, никогда не говорит вам, что, вы должны посетить MSDN, чтобы узнать)

Всего этого можно было бы избежать, если бы Angleвместо этого был класс ...

Для программистов на C / C ++ переход на C # является естественным. Тем не менее, самая большая проблема, с которой я столкнулся лично (и видел, как другие делали такой же переход), не полностью понимает разницу между классами и структурами в C #.

В C ++ классы и структуры идентичны; они отличаются только видимостью по умолчанию, где классы по умолчанию имеют частную видимость, а структуры по умолчанию - публичную видимость. В C ++ это определение класса

    class A
    {
    public:
        int i;
    };

функционально эквивалентно этому определению структуры.

    struct A
    {
        int i;
    };

Однако в C # классы являются ссылочными типами, а структуры - типами значений. Это делает БОЛЬШУЮ разницу в (1) решении, когда использовать один над другим, (2) тестировании равенства объектов, (3) производительности (например, бокс / распаковка) и т. Д.

В Интернете есть все виды информации, связанной с различиями между ними (например, здесь ). Я настоятельно рекомендую всем, кто осуществляет переход на C #, по крайней мере, иметь практические знания о различиях и их последствиях.

Сборка мусора и утилизация (). Хотя вам не нужно ничего делать для освобождения памяти , вам все равно нужно освободить ресурсы с помощью 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());

печатает пять "амет", в то время как следующий пример работает нормально

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 года, вам нужно написать собственный обходной путь.

Nasty Linq Caching Gotcha

Смотрите мой вопрос, который привел к этому открытию, и блогера, который обнаружил проблему.

Короче говоря, DataContext хранит кэш всех объектов Linq-to-Sql, которые вы когда-либо загружали. Если кто-либо внесет какие-либо изменения в запись, которую вы ранее загрузили, вы не сможете получить последние данные, даже если вы явно перезагрузите запись!

Это происходит из-за свойства, вызываемого ObjectTrackingEnabledдля DataContext, которое по умолчанию имеет значение true. Если вы установите для этого свойства значение false, запись будет загружаться заново каждый раз ... НО ... вы не можете сохранить какие-либо изменения в этой записи с помощью SubmitChanges ().

ПОПАЛСЯ!

Контракт на 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будет считываться не более указанного количества байтов, но полностью свободна для чтения всего 1 байта, даже если до конца потока доступны еще 7 байтов.

Это не помогает , что это выглядит так , подобные 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;
    }

Мероприятия

Я никогда не понимал, почему события являются языковой особенностью. Они сложны в использовании: вам нужно проверить нулевое значение перед звонком, вам нужно отменить регистрацию (самостоятельно), вы не можете узнать, кто зарегистрирован (например: я зарегистрировался?). Почему событие не просто класс в библиотеке? В основном специализированный List<delegate>?

Сегодня я исправил ошибку, которая долго отсутствовала. Ошибка была в универсальном классе, который использовался в многопоточном сценарии, а статическое поле int использовалось для обеспечения синхронизации без блокировки с использованием Interlocked. Ошибка была вызвана тем, что каждый экземпляр универсального класса для типа имеет собственную статическую переменную. Таким образом, каждый поток получил свое собственное статическое поле и не использовал блокировку, как предполагалось.

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

Перечисляемые могут быть оценены более одного раза

Это укусит вас, когда у вас будет перечислимое с ленивым перечислением, и вы дважды итерируете его и получите разные результаты. (или вы получаете те же результаты, но они выполняются дважды без необходимости)

Например, при написании определенного теста мне понадобилось несколько временных файлов для проверки логики:

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перечислимое повторяется дважды (результаты первой итерации просто не запоминаются), и на каждой новой итерации вы будете повторно вызывать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 после всех записей !! Затем вы начинаете строго проверять, что у вас нет состояния гонки, когда ... после одного потерянного часа ... вы поняли, что это просто крошечная Перечисляемая вещь, которую вы забыли ...

Просто нашел странный, который на некоторое время застрял в отладке:

Вы можете увеличивать ноль для обнуляемого целого, не выбрасывая исключение, и значение остается нулевым.

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

Да, это поведение задокументировано, но это определенно не делает его правильным.