Comments 12
Получается, что все проверки на
Не лучше ли использовать Resharper с аннотациями, или Code Contracts, чтобы получить аналогичные проверки во время компиляции?
null
, даже будучи автоматически добавленными в код, выполняются все равно в рантайме.Не лучше ли использовать Resharper с аннотациями, или Code Contracts, чтобы получить аналогичные проверки во время компиляции?
+1
Не совсем так. Проверка на нал действительно идет в ран-тайме, но мы получаем ошибку компилятора в случае если используем нулевую ссылку там где подразумевалась ненулевая.
Code annotations от решарпера мне не нравятся тем, что
1) Это всего лишь warning
2) Используется opt-in схема. Т.е. все типы по умолчанию нулевые. По-хорошему нам нужно обратное поведение — сделать все типы по умолчанию ненулевыми и затем opt-out в случае если какой-то из них нулевой.
Но вообще Code annotations и Code Contracts — тоже вполне себе хорошая альтернатива
Code annotations от решарпера мне не нравятся тем, что
1) Это всего лишь warning
2) Используется opt-in схема. Т.е. все типы по умолчанию нулевые. По-хорошему нам нужно обратное поведение — сделать все типы по умолчанию ненулевыми и затем opt-out в случае если какой-то из них нулевой.
Но вообще Code annotations и Code Contracts — тоже вполне себе хорошая альтернатива
0
1. Можно настроить, чтобы предупреждение считалось ошибкой.
2. Да, так вроде бы нельзя — атрибуты все равно нужны.
Кстати, правильно ли я понял из ваших примеров, что проверяется только значение полей?
Значит, если сам объект будет нулевым, то Null Reference все равно возникнет?
2. Да, так вроде бы нельзя — атрибуты все равно нужны.
Кстати, правильно ли я понял из ваших примеров, что проверяется только значение полей?
Значит, если сам объект будет нулевым, то Null Reference все равно возникнет?
var customer = CustomerService.GetCustomer(); // вдруг вернуло Null?
Console.WriteLine(customer.Name); // все равно будет NRE
+1
1. Согласен
Проверяются все входящие и выходящие значения. Т.е. в вашем примере NRE будет тут:
var customer = CustomerService.GetCustomer(); // будет NRE
Console.WriteLine(customer.Name);
Проверяются все входящие и выходящие значения. Т.е. в вашем примере NRE будет тут:
var customer = CustomerService.GetCustomer(); // будет NRE
Console.WriteLine(customer.Name);
0
>2. Да, так вроде бы нельзя — атрибуты все равно нужны.
Можно github.com/ulrichb/ImplicitNullability
Можно github.com/ulrichb/ImplicitNullability
0
Еще хотел добавить. Пожалуй главный плюс подхода с Maybe для меня в том, что он улучшает читаемость кода благодаря тому, что мы разделяем нулевые и ненулевые типы.
0
Зачем необходима борьба с null-ом? Если достаточно написать: Console.WriteLine(customer?.Name).
0
UFO just landed and posted this here
Вообще говоря, это не решает проблему. В вашем примере непосредственно ваш код не падает, но метод
WriteLine
все равно вызывается и в него передается null
. Если бы это был другой метод, который передает значение куда-то глубоко вниз по цепочке вызовов и там вдруг возникает NullReferenceException
, отлаживать такую ситуацию может быть затруднительно.+1
Выглядит классно, но в свой боевой проект внедрять побоюсь. Автор сам указал на проблему с использованием фреймворков, и это не позволит кодировать разные сборки в составе солюшена в одном стиле. Мне кажется, это может усложнить чтение кода для членов команды или сторонних ревьюверов.
Может быть это надуманная проблема, но я много раз наблюдал сложности с пониманием даже достаточно простых вещей людьми, которых сложно назвать глупыми, всего лишь из-за разницы в стиле кодирования.
Может быть это надуманная проблема, но я много раз наблюдал сложности с пониманием даже достаточно простых вещей людьми, которых сложно назвать глупыми, всего лишь из-за разницы в стиле кодирования.
0
Maybe вполне можно использовать и без Fody, с сочетанием соглашения не возвращать null и ручных проверок.
Мне больше нравится реализация Maybe на основе IEnumerable: очень удобно использовать в LINQ выражениях.
Стоит отметить, что в F# Maybe называется «option».
Мне больше нравится реализация Maybe на основе IEnumerable: очень удобно использовать в LINQ выражениях.
Стоит отметить, что в F# Maybe называется «option».
0
Sign up to leave a comment.
Articles
Change theme settings
Functional C#: Non-nullable reference types (ненулевые ссылочные типы)