Я нещодавно працював з 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 # gotchas.

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

Проблема полягає в тому, що вона стирає слід стека і ускладнює діагностику проблем, тому що ви не можете відстежувати, звідки виник виняток.

Правильний код - це або операція кидання без аргументів:

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 призвів до отримання значення, оскільки у вас відкрите вікно "годинник" - особливо вікно перегляду "Авто", яке відображає значення всіх змінних / властивостей, що відповідають поточному чи попередньому рядку виконання. Коли ви потрапили на точку розриву на лінії 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 ("dd / MM / yyyy") ; Це насправді не буде завжди дає вам dd / MM / yyyy, але замість цього воно врахує регіональні налаштування та замінить роздільник ваших дат залежно від того, де ви знаходитесь. Таким чином, ви можете отримати dd-MM-yyyy чи щось подібне.

Правильний спосіб зробити це - використовувати DateTime.ToString ("dd" / "MM" / "yyyy");

DateTime.ToString ("r") повинен перетворитися на RFC1123, який використовує GMT. 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

Властивість Тікса вимірює час у 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,625ms: 15, 31, 46 тощо.

Ця поведінка відрізняється від системи до системи , але є й інші пов'язані з вирішенням проблеми в API цього дати / часу.

Шлях.комбінація

Чудовий спосіб поєднання шляхів до файлів, але він не завжди поводиться так, як ви очікували.

Якщо другий параметр починається з \символу, він не дасть вам повного шляху:

Цей код:

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 рамки використовуються градуси, в той час як інші використовують радіани (а документація, яка з’являється разом з 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

Але не реалізовуйте це. Коли ви телефонуєте "Додати", він повідомляє, що це не працює. То чому ж клас реалізує інтерфейс, коли він не може його підтримувати?

Компілює, але не працює:

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 року, вам потрібно написати власне рішення.

Спритний Linq Caching Gotcha

Подивитися моє запитання, яке призвело до цього відкриття, і блогер який виявив проблему.

Коротше кажучи, DataContext зберігає кеш усіх об'єктів Linq-to-Sql, які ви коли-небудь завантажували. Якщо хтось інший внесе зміни до запису, який ви раніше завантажили, ви не зможете отримати останні дані, навіть якщо ви явно перезавантажите запис!

Це пов’язано з властивістю, що називається ObjectTrackingEnabledв DataContext, яка за замовчуванням відповідає істині. Якщо ви встановите це властивість на значення 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, зрештою, пише !! Тоді ви починаєте суворо перевіряти, чи не маєте ви гоночного стану, коли .... після однієї витраченої години ... ви зрозуміли, що це просто та крихітна маленька річ, яку ви забули ....

Щойно знайшов дивного, який на деякий час застряг у налагодженні:

Ви можете збільшити null для нульового int, не кидаючи виняток, і значення залишається 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!"

Так, така поведінка задокументована, але це, безумовно, не робить це правильним.