Какое языковое решение в C # вас раздражает? [закрыто]

Тестирование строк для Пустого или Пустого лучше всего сделано с помощью:

if (string.IsNullOrEmpty(testString))
{
}

и касательно параметров

Вероятно, самая большая явная дыра в C#, для меня, перечислений.

Перечисления Java являются безопасными с точки зрения типов классами, которым можно дать поведение, может реализовать интерфейсы и так далее.

Перечисления C#/.Net просто прославлены, ints со всеми проблемными константами интервала имели возвращение к C и C++.

Подробно останавливаясь на ответе Mitch.

Это - на самом деле решение CLR, не C# один. C# не имеет никакого контроля над деталями реализации Системы BCL. Строковый класс.

Истинный C# мог иметь специальную строку в корпусе в компиляторе и сказал, что мы сделаем специальные пустые проверки, но это имело бы, по моему скромному мнению, плохое решение. Строка. IsNullOrEmpty является приемлемым компромиссом.

Путем я должен реализовать свойства от интерфейса в c# 3.0 даже при том, что они - точно то же как интерфейс, когда я не изменяю поведение по умолчанию автоматических свойств.

например.

public interface MyInterface
{
   int MyProperty { get; set;}
}

public class MyClass : MyInterface
{
   public int MyProperty { get; set; }
}

public class MyClass2 : MyInterface
{
   public int MyProperty { get; set; }
}

public class MyClass3 : MyInterface
{
   public int MyProperty { get; set; }
}

Править: Обратиться к некоторым комментариям к этому. Я не изменяю поведения по умолчанию своего метода считывания. Я понимаю, что различие между классом и интерфейсом слова благодарности, моя точка - то, что моя маркировка его с интерфейсом, у меня не придется быть этого свойства в каждом классе с реализацией, если я не хочу изменить поведение по умолчанию метода считывания или метода set. Предположите, что 500 классов реализуют этот интерфейс?

Также отсутствие Mixins..

Проверенные исключения были бы хорошими. Я знаю, что многие люди ненавидят их с Java, но я думаю, что это всегда принудительные проверки работоспособности, особенно при вводе-выводе. Мне нравится большинство вещей, которые C # изменил и / или добавил по сравнению с Java, но мне бы очень хотелось, чтобы они приняли проверенные исключения. Сейчас уже слишком поздно (среда .NET, изменяемая так, чтобы они ломали практически все программы), но я думаю, было бы лучше иметь их.

Применение разрыва в непустом регистре.

Детальность перечислений, особенно в операторах регистра. Если у меня есть switch (expr) и expr - это enum, меня не должны заставлять полностью квалифицировать каждое перечисление в каждом случае, если только нет конфликта имен.

Я хотел бы видеть объекты класса как объекты первого класса в языке.

Это позволит вам переопределить статические методы и объявить их в интерфейсах.

Not allowing co/contra-variance or access rights changes when overriding base class or implementing interface methods:

public class A
{
    protected virtual Stream method()
    {
        //...stuff...
    }
}

public class B : A
{
    // compiler borks...
    public override FileStream method()
    {
        //...more stuff...
    }
}

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

Почему:

Array.Sort(myArray);
String.IsNullOrEmpty(myString);

вместо:

myArray.Sort();
myString.IsNullOrEmpty

Я не говорю, что для этого нет веских причин, и это не имеет большого значения, но если JS может справиться с этим, почему может ' т C #? *

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

* Кстати, я тоже скучаю по синтаксису закрытия JS.

Ненавижу набирать IEnumerable повсюду. Это так трудно читать. Я бы предпочел что-то вроде сокращенной записи, чтобы мой код был чище.

Это сообщение SO хорошо подводит итог.

Мне не нравятся IDisposable / Dispose и т. Д. Исходя из C ++, очень неприятно думать об управлении памятью в C #. Оператор using подходит, если одноразовый объект используется только в одной функции. Если его нужно передать, вам нужно вручную указать счетчик ссылок или сделать что-то еще, чтобы узнать, когда можно избавиться от объекта.