Недоліки дизайну C # (.NET) [закрито]

Які найбільші недоліки дизайну в C # або .NET Framework загалом?

Приклад: не існує типового типу рядка, який не можна онулювати, і вам потрібно перевірити DBNull під час отримання значень із IDataReader.

Я рішуче погоджуюсь з цим постом (для тих, хто пукає відсутність ToString, існує атрибут налагоджувача, який забезпечує власний формат для вашого класу).

Зверху наведеного вище списку я б також додав такі обґрунтовані запити:

1. ненульовані посилальні типи як доповнення до типів значень, що допускають нульове значення,
2. дозволити перевизначити порожній конструктор структури,
3. дозволити загальним обмеженням типу вказувати закриті класи,
4. Я погоджуюсь з іншим плакатом тут, який вимагав довільних підписів конструктора, коли використовується як обмеження, тобто. де T : new(string)або деT : new(string, int)
5. Я також погоджуюсь з іншим плакатом тут щодо виправлення подій, як для порожніх списків подій, так і в паралельних налаштуваннях (хоча останній складний),
6. оператори повинні визначатися як методи розширення, а не як статичні методи класу (або не лише як статичні методи принаймні),
7. дозволити статичні властивості та методи для інтерфейсів (Java має це, але C # ні),
8. дозволити ініціалізацію подій в ініціалізаторах об’єктів (наразі дозволено лише поля та властивості),
9. чому синтаксис "ініціалізатора об'єкта" можна використовувати лише під час створення об'єкта? Чому б не зробити його доступним у будь-який час, тобто.var e = new Foo(); e { Bar = baz };
10. виправити квадратичну перелічену поведінку ,
11. всі колекції повинні мати незмінні знімки для ітерації (тобто. мутація колекції не повинна робити інвалідацію ітератора),
12. кортежі легко додати, але ефективний замкнутий алгебраїчний тип, такий як " Either<T>", це не так, тому я хотів би якось оголосити закритий алгебраїчний тип і накласти на нього вичерпне узгодження шаблонів (в основному першокласна підтримка шаблону відвідувача, але набагато ефективніше); так що просто приймайте переліки, розширюйте їх за допомогою вичерпної підтримки збігу шаблонів і не допускайте недійсних випадків
13. Я хотів би підтримати узгодження шаблонів загалом, але принаймні тестування типу об’єкта; Мені також подобається синтаксис перемикача, запропонований в іншому повідомленні тут,
14. Я погоджуюсь з іншим повідомленням, що System.IOзаняття, як Stream, наприклад , дещо погано розроблені; будь-який інтерфейс, який вимагає деяких реалізацій, NotSupportedExceptionє поганим дизайном,
15. IListмає бути набагато простішим, ніж є; насправді, це може бути справедливим для багатьох інтерфейсів збирання бетону, наприклад ICollection,
16. занадто багато методів викидають винятки, наприклад, наприклад, IDictionary,
17. Я віддав би перевагу формі перевірених винятків, кращій за ту, яка доступна в Java (див. Дослідження щодо систем типу та ефекту, як це можна зробити),
18. виправити різні настирливі випадки кутів у загальному дозволі перевантаження; наприклад, спробуйте надати два перевантажені методи розширення, один, який працює з посилальними типами, а інший - з типовими типами структури, і подивіться, як це подобається висновку вашого типу,
19. забезпечити спосіб безпечного розмірковування над іменами полів та членів для таких інтерфейсів, як INotifyPropertyChanged, які приймають ім'я поля як рядок; Ви можете зробити це, використовуючи метод розширення, який бере лямбду з a MemberExpression, тобто. () => Foo, але це не дуже ефективно,
    • Оновлення: C # 6.0 додав nameof()оператор для імен окремих членів, але це не працює у nameof(T) == "T"загальних виробах ( замість фактичного імені аргументу типу: все ще потрібно це зробити typeof(T).Name)) - і не дозволяє отримати рядок "шлях" , наприклад, nameof(this.ComplexProperty.Value) == "Value"обмеження можливих застосувань.
20. дозволяють операторам в інтерфейсах і забезпечують реалізацію всіх основних типів чисел IArithmetic; можливі також інші корисні інтерфейси спільного оператора,
21. ускладнити мутацію полів / властивостей об’єкта або, принаймні, дозволити анотувати незмінні поля та змусити перевірку типу примусити його (просто розглядати це як властивість, що отримує лише геттер, це не важко!); насправді, уніфікувати поля та властивості більш розумно, оскільки немає сенсу мати обидва; Автоматичні властивості C # 3.0 - це перший крок у цьому напрямку, але вони заходять недостатньо далеко,
    • Оновлення: Хоча в C # було readonlyключове слово, а в C # 6.0 додані автоматичні властивості лише для читання, хоча воно не таке суворе, як підтримка справжньої мови для незмінних типів і значень.
22. спростити конструктори оголошення; Мені подобається підхід F #, але інша публікація тут, яка вимагає просто "новий" замість назви класу, принаймні краще,

Наразі цього вистачає. Це все роздратування, з якими я стикався минулого тижня. Я, мабуть, міг би тривати годинами, якби я справді до цього додумався. C # 4.0 вже додає іменовані, необов'язкові та аргументи за замовчуванням, що я наполегливо схвалюю.

Тепер щодо одного необґрунтованого запиту:

1. було б дуже, дуже приємно, якби C # / CLR міг підтримувати поліморфізм конструктора типу, тобто. дженерики над дженериками,

Гарненько, будь ласка? :-)

• Reset()метод на IEnumerator<T>була помилка (для блоків ітераторів, мова специфікація навіть вимагає , що це кидає виняток)
• на думку Еріка, методи відображення, які повертають масиви, були помилкою
• коваріація масиву була і залишається дивним
  • Оновлення: C # 4.0 з .NET 4.0 додав підтримку коваріантних / контраваріаційних змін до загальних інтерфейсів (як IEnumerable<out T>і Func<in T, out TResult>, але не конкретних типів (як List<T>).
• ApplicationException скоріше впав із немилості - це була помилка?
• синхронізовані колекції - приємна ідея, але не обов’язково корисна насправді: зазвичай вам потрібно синхронізувати кілька операцій ( Containsтоді Add), тому колекція, яка синхронізує окремі операції, не так вже й корисна
  • Оновлення: У System.Collections.Concurrentтипи , з TryAdd, GetOrAdd, TryRemoveі т.д. були додані в .NET Framework 4.0 - хоча методи , які приймають заводську делегат не гарантують завод буде запущений тільки один раз за ключ.
• можна було б більше використовувати шаблон using/ lock- можливо, дозволивши їм ділитися повторно використовуваним (розширюваним?) синтаксисом; Ви можете змоделювати це, повернувшись IDisposableта використовуючи using, але це могло бути зрозуміліше
• блоки ітераторів: не простий спосіб перевірки аргументів завчасно (а не ліниво). Звичайно, ви можете написати два ланцюгові методи, але це негарно
• простіша незмінність була б непоганою; C # 4.0 трохи допомагає , але недостатньо
• жодна підтримка "цей параметр типу ref не може бути нульовим" - хоча контракти (у версії 4.0) дещо допомагають у цьому. Але синтаксис типу Foo(SqlConnection! connection)(який вводить null-check / throw) був би непоганим (на відміну від int?тощо)
  • Оновлення: це виправлено у C # 8.0 .
• відсутність підтримки операторів та конструкторів, що не виконуються за замовчуванням, із дженериками; C # 4.0 це трохи вирішує dynamic, або ви можете ввімкнути це так
• ітераторна змінна оголошується поза межами while у foreachрозгортанні, що означає, що anon-методи / лямбди захоплюють одну змінну, а не одну за ітерацію (болюче при потоках / async / і т.д.)
  • Оновлення: це було виправлено в C # 5.0 .

TextWriter - базовий клас StreamWriter. wtf?

Це мене завжди бентежить до крайності.

Невеликий конструктор C # pet peev - використовує синтаксис C ++ / Java, щоб конструктор мав те саме ім'я, що і клас.

New()або ctor()було б набагато приємніше.

Звичайно, такі інструменти, як coderush, роблять це менш проблематичним для перейменування класів, але завдяки доступності для читання POV, New () забезпечує велику ясність.

Я не розумію, що ти не можеш зробити

де T: новий (U)

Отже, ви заявляєте, що загальний тип T має конструктор, який не є типовим.

редагувати:

Я хочу зробити це:

public class A 
{
    public A(string text) 
    {

    }
}


public class Gen<T> where T : new(string text) 
{

}

Я справді здивований, що першим згадав про це:

Набори даних ADO.NET, що вводяться, не виставляють стовпці, що підлягають нульовому використанню, як властивості типів, що дозволяють опустити. Ви повинні мати можливість написати це:

int? i = myRec.Field;
myRec.Field = null;

Натомість вам потрібно написати це, що просто дурно:

int? i = (int?)myRec.IsFieldNull() ? (int?)null : myRec.Field;
myRec.SetFieldNull();

Це дратувало в .NET 2.0, і це ще більше дратує зараз, коли вам доводиться використовувати джиггі-покер, як зазначено вище, у ваших приємних акуратних запитах LINQ.

Також дратує те, що згенерований Add<TableName>Rowметод так само нечутливий до поняття типів, що дозволяють опустити. Тим більше, що генеровані TableAdapterметоди не є.

У .NET не так багато, що викликає у мене відчуття, як команда розробників сказала: "Добре, хлопці, ми досить близько - доставляйте!" Але це точно так.

1. Я не великий шанувальник класів Stream, StringWriter, StringReader, TextReader, TextWriter ... просто не зрозуміло, що є що.
2. IEnumerable.Reset, викидаючи виняток для ітераторів. У мене є деякі сторонні компоненти, які завжди викликають скидання, коли пов’язані дані, вимагає від мене першого переходу до списку, щоб використовувати їх.
3. Серіалізатор Xml повинен мати серіалізовані елементи IDictionary
4. Я зовсім забув про HttpWebRequest & FTP API, який біль у мене .... (спасибі за коментар Микола, що мені нагадує про це :-)

Редагувати
5. Ще одне моє роздратування - це те, як System.Reflection.BindingFlags має різне використання залежно від використовуваного вами методу. Наприклад, у FindFields, що означає CreateInstance або SetField? Це випадок, коли вони перевантажили зміст цього переліку, що викликає заплутаність.

Я не знаю, що я піду так далеко, що скажу, що це недолік дизайну, але було б дуже добре, якби ви могли зробити висновок про лямбда-вираз так само, як і у VB:

VB:

Dim a = Function(x) x * (x - 1)

C #

Було б непогано, якби міг зробити це:

var a = x => x * (x - 1);

Замість того, щоб робити це:

Func<int, int> a = x => x * (x - 1);

Я розумію, що це не набагато довше, але в Code Golf кожен персонаж має значення! Хіба вони не беруть цього до уваги, коли розробляють ці мови програмування? :)

1. Клас System.Object :

   • Equals і GetHashCode - не всі класи можна порівняти або розширити, їх слід перемістити в інтерфейс. IEquatable або IComparable (або подібний) спадає на думку.

   • ToString - не всі класи можна перетворити на рядок, їх слід перемістити в інтерфейс. IФормат (або подібний) приходить мені на думку.

2. ICollection.SyncRoot властивість:

   • Сприяє поганому дизайну, зовнішній замок майже завжди корисніший.

3. Дженерики мали бути там із самого початку:

   • System.Collections простір імен містить багато більш-менш застарілих класів і інтерфейсів.

Одна з речей, яка мене дратує, - це Predicate<T> != Func<T, bool>парадокс. Вони обидва делегатів типу, T -> boolі все ж вони не сумісні з призначенням.

Деякі люди (ISV) бажають, щоб ви могли скомпілювати його до машинного коду під час побудови та зв'язати, щоб створити власний виконуваний файл, якому не потрібен час роботи dotNet.

Ми так багато знаємо про право методики ОО. Роз'єднання, програмування за контрактом, уникнення неправильного успадкування, належне використання винятків, відкритий / закритий принципал, замінність Ліскова тощо. Однак у рамках .Net не застосовуються найкращі практики.

Для мене найбільшим недоліком дизайну .Net є не стояння на плечах гігантів; просування менш ідеальних парадигм програмування до маси програмістів, які використовують їх фреймворки .

Якби MS звернули на це увагу, у цьому десятилітті світ програмної інженерії міг би зробити значні стрибки з точки зору якості, стабільності та масштабованості, але, на жаль, це, здається, регресує.

Мені не подобається оператор перемикача C #.

Я хотів би щось подібне

switch (a) {
  1    : do_something;
  2    : do_something_else;
  3,4  : do_something_different;
  else : do_something_weird; 
}

Тож більше немає перерв (легко забути) та можливості розділяти різні значення комами.

Події в C #, де вам потрібно чітко перевірити слухачів. Хіба не в цьому суть подій, щоб транслювати їх тому, хто випадково опинився там? Навіть якщо таких немає?

Жахлива (і досить невидима для більшості людей) поведінка O (N ^ 2) вкладених / рекурсивних ітераторів .

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

Я постійно працюю з деревоподібними структурами, і мені доводиться виправляти інакше розумні коди людей, коли вони ненавмисно вводять дуже дорогі операції таким чином.

Принадність "yield foreach" полягає в тому, що простіший, простіший синтаксис заохочує правильний, продуктивний код. Це "яма успіху", до якої, на мою думку, їм слід прагнути, перш ніж додавати нові функції для довгострокового успіху платформи.

Деякі класи реалізують інтерфейси, але вони не реалізують багато методів цього інтерфейсу, наприклад, Array реалізує IList, але 4 з 9 методів викидають NotSupportedException http://msdn.microsoft.com/en-us/library/system.array_members .aspx

Статичні члени та вкладені типи в інтерфейсах.

Це особливо корисно, коли член інтерфейсу має параметр типу, який є специфічним для інтерфейсу ( наприклад, an enum). Було б непогано вкласти тип enum у тип інтерфейсу.

Страшенно небезпечний характер подій за замовчуванням. Той факт, що ви можете викликати подію і знаходитись у суперечливому стані через вилучення передплатників, просто жахливий. Дивіться чудові статті Джона Скіта та Еріка Ліпперта, щоб більше прочитати цю тему.

• null скрізь.

• const нікуди.

• API несумісні, наприклад, мутація масиву повертається, voidале додавання до StringBufferповертає ту саму змінну StringBuffer.

• Інтерфейси збору несумісні з незмінними структурами даних, наприклад, Addin System.Collections.Generic.IList<_>не може повернути результат.

• Немає структурного набору тексту, тому ви пишете System.Windows.Media.Effects.SamplingMode.Bilinearзамість просто Bilinear.

• Змінюваний IEnumeratorінтерфейс, реалізований класами, коли він повинен бути незмінним struct.

• Рівність і порівняння безлад: у вас є , System.IComparableі Equalsале тоді ви також отримали System.IComparable<_>, System.IEquatable, System.Collections.IComparer, System.Collections.IStructuralComparable, System.Collections.IStructuralEquatable, System.Collections.Generic.IComparerі System.Collections.Generic.IEqualityComparer.

• Кортежі повинні бути структурами, але структури непотрібно гальмують усунення хвостового виклику, тому один із найпоширеніших і основних типів даних буде розподіляти без потреби і руйнувати масштабований паралелізм.

0 місячне освітлення як перерахування

особливості переліку: http://blogs.msdn.com/abhinaba/archive/2007/01/09/more-peculiarites-of-enum.aspx

як показано на цьому хорошому прикладі: http://plus.kaist.ac.kr/~shoh/postgresql/Npgsql/apidocs/Npgsql.NpgsqlParameterCollection.Add_overload_3.html

моя пропозиція, використовуйте знак "@":

замість:

if ((myVar & MyEnumName.ColorRed)! = 0)

використовуй це:

if ((myVar & MyEnumName.ColorRed)! = @ 0)

Щоб додати до довгого списку хороших балів, зроблених іншими вже:

• DateTime.Now == DateTime.Now у більшості, але не у всіх випадках.

• Stringякий є незмінним, має купу варіантів побудови та маніпуляцій, але StringBuilder(що змінюється) не має.

• Monitor.Enterі Monitor.Exitмали бути методами екземпляра, тому замість того, щоб створювати конкретний об’єкт для блокування, ви можете створити a Monitorта заблокувати його.

• Деструктори ніколи не повинні називатися деструкторами. Специфікація ECMA називає їх фіналізаторами, що набагато менш заплутано для натовпу C ++, але специфікація мови все ще називає їх деструкторами.

Те, як ми використовуємо властивості, мене часом дратує. Мені подобається думати про них як про еквівалент методів Java getFoo () та setFoo (). Але вони не є.

Якщо в Правилах використання властивостей зазначено, що властивості слід встановлювати в будь-якому порядку, щоб серіалізація могла працювати, то вони марні для перевірки часу встановлення. Якщо ви походите з фону, де ви хочете, щоб об’єкт не дозволив собі коли-небудь потрапити в недійсний стан, тоді властивості не є вашим рішенням. Іноді я не можу зрозуміти, наскільки вони краще , ніж державні члени, так як ми настільки обмежені в тому, що види речей , які ми як передбачається зробити в властивості.

З цією метою я завжди якось хотів (це в основному тут мислення вголос, я просто хотів би зробити щось подібне), щоб я міг якось розширити синтаксис властивостей. Уявіть щось подібне:

private string password;

public string Password
{
    // Called when being set by a deserializer or a persistence
    // framework
    deserialize
    {
       // I could put some backward-compat hacks in here. Like
       // weak passwords are grandfathered in without blowing up
       this.password = value;
    }
    get
    {
       if (Thread.CurrentPrincipal.IsInRole("Administrator"))
       {
           return this.password;
       }
       else
       {
           throw new PermissionException();
       }
    }
    set
    {
       if (MeetsPasswordRequirements(value))
       {
           throw new BlahException();
       }
       this.password = value;
    }
    serialize
    {
        return this.password;
    }
}

Я не впевнений, чи корисно це, або як би виглядав доступ до них. Але я просто бажаю, щоб я міг зробити більше із властивостями і по-справжньому ставитися до них як до методів get і set.

Методи розширення приємні, але це некрасивий спосіб вирішити проблеми, які можна було б вирішити чистіше за допомогою справжніх міксинів (подивіться на ruby, щоб зрозуміти, про що я говорю), на тему міксинів. Дійсно хорошим способом додати їх до мови було б дозволити використання дженериків для успадкування. Це дозволяє розширити існуючі класи приємним об'єктно-орієнтованим способом:

public class MyMixin<T> : T
{
    // etc...
}

це можна використовувати так, щоб розширити рядок, наприклад:

var newMixin = new MyMixin<string>();

Це набагато потужніше, ніж методи розширення, оскільки дозволяє замінити методи, наприклад, обернути їх, дозволяючи функціональність, схожу на AOP, всередині мови.

Вибачте за розмову :-)

Microsoft не буде виправляти очевидні помилки у фреймворку і не надаватиме хуки, щоб кінцеві користувачі могли їх виправляти.

Крім того, не існує способу двійкового виправлення виконуваних файлів .NET під час виконання, а також неможливо вказати приватні версії бібліотек .NET framework без двійкового виправлення власних бібліотек (щоб перехопити виклик завантаження), а ILDASM не підлягає розповсюдженню, тому я не можу автоматизувати патч у будь-якому випадку.

• Можливість викликати метод розширення для нульової змінної є спірною, наприклад

  об'єкт a = null; a.MyExtMethod (); // це можна викликати, припустимо, десь він визначив MyExtMethod

  Це може бути зручно, але неоднозначно щодо тем винятків нульових посилань.

• Одна назва „вада”. 'C' "configuration" у System.configuration.dll має бути написано великими літерами.

• Обробка винятків. Виняток слід примусово вловити або кинути, як у Java, компілятор повинен перевірити його під час компіляції. Користувачі не повинні покладатися на коментарі щодо інформації про винятки в межах цільового виклику.

Метод .Parameters.Add () на SqlCommand у V1 фреймворку був жахливо розроблений - одна з перевантажень в основному не працювала б, якщо ви передали параметр зі значенням (int) 0 - це призвело до їх створення метод .Parameters.AddWithValue () для класу SqlCommand.

1. Не існує підмножин ICollection<T>і IList<T>; як мінімум, коваріантний інтерфейс збору лише для читанняIListSource<out T> (з перелічувачем, індексатором та Count) був би надзвичайно корисним.
2. .NET не підтримує слабких делегатів . Обхідні шляхи в кращому випадку незграбні, а обхідні шляхи для слухачів неможливі при частковій довірі (потрібен ReflectionPermission).
3. Уніфікація загального інтерфейсу заборонена, навіть коли це має сенс і не викликає проблем.
4. На відміну від С ++, коваріантні типи повернення заборонені в .NET
5. Побітове порівняння двох типів значень для рівності неможливе. У функціональній " постійній " структурі даних я писав aTransform(Sequence<T>, Func<T,T>) функцію, яка мала швидко визначити, чи повертає функція те саме значення чи інше значення. Якщо функція не змінює більшість / усіх своїх аргументів, то вихідна послідовність може спільно використовувати частину / всю пам'ять із вхідної послідовності. Без можливості побітового порівняння будь-якого значення типу Т, слід застосовувати набагато повільніше порівняння, що надзвичайно шкодить продуктивності.
6. Здається, .NET не може ефективно підтримувати спеціальні інтерфейси (як ті, що пропонуються в Go або Rust). Такі інтерфейси дозволили б вам перейти List<T>до гіпотетичного IListSource<U>(де T: U), хоча клас явно не реалізує цей інтерфейс. Існує щонайменше три різні бібліотеки (написані незалежно), що забезпечують цю функціональність (звичайно, з недоліками продуктивності - якби було можливе ідеальне обхідне рішення, було б несправедливо називати це недоліком .NET).
7. Інші проблеми з продуктивністю: IEnumerator вимагає двох викликів інтерфейсу за ітерацію. Звичайні вказівники методів (відкриті делегати розміру IntPtr) або делегати зі значенням (IntPtr * 2) неможливі. Масиви фіксованого розміру (довільного типу T) не можуть бути вбудовані всередину класів. Немає WeakReference<T>(ви можете легко написати свій власний, але він буде використовувати зліпки всередині.)
8. Той факт, що ідентичні типи делегатів вважаються несумісними (відсутність неявного перетворення), для мене часом дратував (наприклад, Predicate<T>проти Func<T,bool>). Я часто хочу, щоб ми могли мати структурну типізацію інтерфейсів та делегатів, щоб досягти більш вільного зв’язку між компонентами, оскільки в .NET недостатньо для класів у незалежних бібліотеках DLL реалізувати один і той же інтерфейс - вони також повинні мати спільне посилання на третій DLL, що визначає інтерфейс.
9. DBNull.Valueіснує, хоча nullб однаково добре виконував ті самі цілі.
10. C # не має оператора ?? =; ви повинні написати variable = variable ?? value. Справді, є кілька місць у C #, яким без потреби не вистачає симетрії. Наприклад, ви можете писати if (x) y(); else z();(без фігурних дужок), але не можете писати try y(); finally z();.
11. При створенні потоку неможливо змусити дочірній потік успадкувати локальні значення потоків від батьківського потоку. BCL не тільки не підтримує цього, але ви не можете реалізувати це самостійно, якщо не створити всі потоки вручну; навіть якщо мала місце подія створення потоку, .NET не може сказати вам "батьків" або "дітей" даного потоку.
12. Той факт, що існують два різні атрибути довжини для різних типів даних, "Довжина" та "Кількість", є незначною неприємністю.
13. Я міг би продовжувати і говорити назавжди про поганий дизайн WPF ... і WCF (хоча цілком корисний для деяких сценаріїв) також повний бородавок. Взагалі, роздутість, неінтуїтивність та обмежена документація багатьох новіших підбібліотек BCL змушують мене не використовувати їх. Багато нового може бути набагато простішим, меншим, простішим у використанні та розумінні, більш вільно пов’язаним, краще задокументованим, застосовним до більшої кількості випадків використання, швидшим та / або сильнішим типом.
14. Мене часто кусає непотрібна взаємозв'язок між методами отримання і встановлення: у похідному класі або похідному інтерфейсі ви не можете просто додати сеттер, коли базовий клас або базовий інтерфейс має лише геттер; якщо ви перевизначите геттер, то вам не дозволяється визначати сеттер; і ви не можете визначити сеттер як віртуальний, але геттер як невіртуальний.

Одна річ , яка галочкою мене в 1.x було при використанні System.Xml.XmlValidatingReader, то ValidationEventHandler«s ValidationEventArgsне виставляє Базового XmlSchemaException(позначено внутрішній) , який має всю корисну інформацію , як linenumberі position. Натомість вам слід проаналізувати це з властивості рядка Message або скористатися відображенням, щоб викопати його. Не так добре, коли потрібно повернути кінцевому користувачеві дезінфіковану помилку.

Не подобається, що ви не можете використовувати значення одного переліку в іншому, наприклад:

    enum Colors { white, blue, green, red, black, yellow }

    enum SpecialColors { Colors.blue, Colors.red, Colors.Yellow } 

Неявно набрані змінні були імплементовані погано в IMO. Я знаю, що ви насправді повинні використовувати їх лише під час роботи з виразами Linq, але дратує те, що ви не можете оголосити їх поза локальною сферою.

З MSDN:

• var може використовуватися лише тоді, коли локальна змінна оголошена та ініціалізована в тому самому операторі; змінна не може бути ініціалізована значенням null, групою методів або анонімною функцією.
• var не може використовуватися в полях класу.
• Змінні, оголошені за допомогою var, не можна використовувати у виразі ініціалізації. Іншими словами, цей вираз легальний: int i = (i = 20); але цей вираз видає помилку під час компіляції: var i = (i = 20);
• Кілька неявно введених змінних не можна ініціалізувати в одному і тому ж операторі.
• Якщо тип із іменем var є в області дії, тоді ключове слово var перетвориться на це ім’я типу і не буде розглядатися як частина неявно набраного оголошення локальної змінної.

Причиною того, що я вважаю, що це погана реалізація, є те, що вони називають це var, але це далеко не варіант. Це насправді просто скорочений синтаксис для того, щоб не потрібно вводити повністю ім'я класу (за винятком випадків, коли використовується з Linq)