По мотивам этого выката "
5 новых фич C# 10".
Новые фичи — я прямо прослезился... НОВЫЕ! Будто предыдущие 20 лет никто и не догадывался, что оказывается можно нэймспэйс не делать одной большой херовиной со скобками и вложенностью, а тупо указать одной строчкой в начале файла!
Но обо всём по порядку...
Null Parameter Checking
Очередная попытка смягчить лошарский индусокод, чтобы макака за канпутиром вместо написания проверки ставила ХОТЯ БЫ ДВА СИМВОЛА.
Очевидно, что тупее проблемы не придумать, а главное, решение — оно как заметание пыли под ковёр.
1. Параметр — он же не просто "qwerty is null!" — у этой ошибки должно быть адекватное объяснение, типа "диапазон не может быть нулевым". А уж как именован диапазон — сами знаете, у микрософта с именованиями вообще швах. НЕ ДОЛЖНО сообщение об ошибке зависеть от имени параметра. Особенно если это дерьмо всплыло в целом стеке вызовов — поди, догадайся, юзер, что за lst вдруг оказался нулевым, когда ты всего-то хотел перекодировать клип!
2. У параметра может быть куча других ограничений — от 0 до 23, не меньше 3 элементов массива и т.п. Все эти ошибки лучше собирать в одном месте. Более того — проверка некоторых параметров может ВООБЩЕ НЕ СЛУЧИТЬСЯ, если до неё не дойдёт выполнение!
3. То, что параметр — нулевой (и можно тупо поставить "!!" и забыть про него) только лишний раз провоцирует мелкомягких индусятин к написанию похабного, падающего, неустойчивого к логике кода. Для примера: подстрока. Если исходная строка — пустая, В ЧЁМ ПРОБЛЕМА вернуть такую же пустую строку?? Или строка "123", а взяли подстроку Substring(10, 100) — что в этом криминального-то?? Ну кончились символы — верни пустую строку, ЗАЧЕМ ПАДАТЬ-ТО?! Я тысячу раз натыкался на идиотский мелкоиндусский код, где я беру "плохие" данные и пытаюсь из них вырезать подстроки, при этом мне вообще неважно, правильно там форматировано или нет — я всё равно ПРОВЕРЯЮ результат и отсекаю нераспознанное. И вот вместо "взять подстроку и проверить, что значение — 'time'", я вынужден сначала проверять длину строки (и что она не пустая), чтобы безрукая обезьяна на зарплате написала единственную строчку в .NET "вернуть символы от и до". И так в КАЖДОМ употреблении Substring(!!!!). Ну охренеть там проектировщики! А теперь представьте, макаке даже null проверять не надо — она тупо наставит "!!" по всему коду, а ты ВСЮ ЖИЗНЬ будешь прыгать вокруг их кода, матеря и делая сотни тупых проверок. Вуаля — Наделла и микрософт! 
4. Символы выбраны крайне неудачные. Во-первых, их два — неужели идиотина, которая это одобряла, не уловила проблемы?! Не говоря о том, что "!" и так перегружен под "логичекое не" и "переменная может быть нулём". Что, в ASCII закончились символы??
Короче, даже такую простую проблему — и то решили через задницу.
Required Properties
В принципе, вещь нужная, но разнообразие use cases сразу же подсказывает (образованному инженеру), что подобная херня сразу же наступит на грабли где-нть при десереализации и ты проклянёшь того "архитектора", который понаставил required. Ну да, в его тестиках сложность уровня "a = b" и всё работает! Короче, вторая КРАЙНЕ СОМНИТЕЛЬНАЯ затея, которая, уверен, далеко не всеми была даже поддержана.
Field Keyword
ДАВНО уже просилась в язык! Почему БАРАНЫ, которые писали С# 2.0, так и не догадались за 20 лет, что далеко не всем и не всегда нужны полные объявления проперти? И опять сделано через жопу — field теперь ключевое слово! Ну вот где были те придурки со своим "!!"??? Вот здесь как раз бы пригодился "знак" вместо слова! И value — тоже та ещё дурь. У меня НЕТ декларации value, а значит слово, похожее на переменную, сбивает меня с толку. Тем более, что value может быть и словом из бизнес-логики! Писали бы что-то вроде "insideVar = @;" — это вместо value. А поле — ну пусть "$$" — что с того! Всё ж короче любой переменной. Да, попахивает Перлом, ну так это СПЕЦ.ЯЗЫК, это вам не частушки! Код не должен быть читаем "пассажиром трамвая", он дожен быть читаем СПЕЦИАЛИСТОМ. "$$ = @;" — эти знаки войдут вам в память и вы даже на секунду не смутитесь, видя их в коде.
Global Usings
Да неужели?!?!! Сбылось!! Наконец-то тугодумы мелкософта поняли, как это НУДНО И БЕССМЫСЛЕННО импортировать ОДНО И ТО ЖЕ В КАЖДЫЙ ФАЙЛ! 
Разродились, родимые...
И опять же — неужели надо быть настолько тупорылым, что копируя Жабу, не поморщиться от обилия using'ов?? Одних и тех же. Везде.
Я-то думал, они прямо в файл проекта юзинги засунут, ну ладно — хотя бы так, в отдельный файл ПОХОЖИЙ НА ОСТАЛЬНЫЕ (привет, проекты с тысячами файлов!).
File Namespaces
Вот оно, родное.... ещё один атавизм жабы, который плоскоумые и "специально отобранные" анжанеры(!) не могли родить ГОДАМИ.
К чему вообще эти скобки? Что это за игры в "универсальный синтаксис"? Да, это scope, но это второстепенная деталь! Зачем её делать такой тупой и отъедающей пространство?
Видимо, подразумевалось (каким-то дурным теоретиком) что люди будут писать большой нэймспэйс, потом внутри него вкладывать ещё 10 разных нэймспэйсов.
Упустили главное — код пишут ЛЮДИ и им нафиг не упёрлась сложность. Проще файл разбить на два и в каждом будет своё имя, чем городить мириады скобочек.
Вот почему D — язык будущего. Его делал ИНЖЕНЕР, а не макака, копирующая другой язык. В D пишешь "module AB;" — всё, нэймспэйс задан! Что сложного-то?
У мелкософта ушло 20 лет на понимание, что "скрипач не нужен".
Обожаю этих недалёких гениев.
Вот такой "прогресс" у языка! Пилили "фичастые фичи" (20 лет, Карл!), а на деле оказалось, что программисты будут счастливы всего лишь избавившись от нэймспэйсов/юзингов и полной декларации проперти! Святая простота....
