Никогда не используйте Nulls? - PullRequest
18 голосов
/ 14 мая 2009

В настоящее время мы проходим долгий процесс написания некоторых стандартов кодирования для C #.

Недавно я написал метод с подписью

string GetUserSessionID(int UserID)

GetUserSession () возвращает ноль в случае, если сеанс не найден для пользователя.

в моем коде вызова ... я говорю ...

string sessionID = GetUserSessionID(1)
if (null == sessionID && userIsAllowedToGetSession)
{
    session = GetNewUserSession(1);
}

В недавнем обзоре кода обозреватель сказал: «Вы никогда не должны возвращать нуль из метода, так как он добавляет больше работы к вызывающему методу для проверки на нули».

Сразу же я заплакал махинации, как будто вы возвращаете строку. Пусто, вам все равно нужно выполнить какую-то проверку возвращаемого значения.

if (string.Empty == sessionID)

Однако, подумав об этом, я никогда не верну ноль в случае Collection / Array / List. Я бы вернул пустой список.

Решением этого (я думаю) было бы рефакторинг этого в 2 метода.

bool SessionExists(int userID);

и

string GetUserSessionID(int UserID);

На этот раз GetUserSessionID вызовет исключение SessionNotFound (поскольку оно не должно возвращать ноль)

теперь код будет выглядеть так ...

if(!SessionExists(1) && userIsAllowedToGetSession))
{
   session = GetNewUserSession(1);
}
else
{
   session = GetUserSessionID(1);
}

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

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

Есть ли у кого-нибудь еще четкие рекомендации (или даже лучшие стандарты) в отношении использования нулей, и что это означает для типов, допускающих обнуляемость (мы должны их вообще использовать?)

Заранее спасибо,

Крис.

=====

Спасибо всем! Там очень много интересного обсуждения.

Я дал ответ egaga, так как мне нравится их предложение Get vs Find в качестве руководства по кодированию, но все они были интересными ответами.

Ответы [ 15 ]

1 голос
/ 15 мая 2009

У меня была похожая проблема, хотя я через Исключение и мне сказали, что я должен вернуть ноль,

Мы закончили читать

этот блог о досадных исключениях

Я бы порекомендовал прочитать.

1 голос
/ 15 мая 2009

Изобретатель нулей считает, что это плохая идея ..

см .: http://lambda -the-ultimate.org / node / 3186

1 голос
/ 14 мая 2009

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

Nullable - nullable особенно полезны, когда вы хотите избежать обработки «нулевых» значений из баз данных. Вы можете просто использовать GetDefaultOrValue для любого типа Nullable, не беспокоясь о нулевом значении базы данных в ваших бизнес-объектах. Мы определяем Nullables обычно ТОЛЬКО в наших бизнес-объектах, и это тоже, где мы действительно хотим избежать проверки значений db null и т. Д.

1 голос
/ 14 мая 2009

Ответ на проектирование по контракту также будет моим решением:

if (myClass.SessionExists)
{
   // Do something with myClass.Session
}
0 голосов
/ 14 мая 2009

NULL означает неизвестный / неопределенный.

Это в основном необходимо при работе с базой данных, где данные просто «не определены (пока)». В вашем приложении NULL - это хороший тип возвращаемого значения для неисключительного, но не стандартного поведения.

Вы используете NULL, когда вывод не является ожидаемым, но недостаточно серьезным для исключения.

...