- 1
- 2
- 3
- 4
private static bool? GetBoolFromObject(object o)
{
return string.IsNullOrEmpty(o.ToString()) ? (bool?)null : (bool)o;
}-
C# / Говнокод #7004
+130
и как такое можно только писать...
Запостил:
testguru,
20 Июня 2011
Follow us!
Соответственно, клиент получит null там, где должен был быть InvalidCastException.
Самый кородкий код с проверкой на null выглядит так (13 байт):
А вот использованный автором двойной explicit cast в нормальном исполнении займёт уже 25 байт:
1) оригинальный говнокод возвращает null для объектов, ToString от которых будет пустой строкой, а оба ваших варианта выбрасывают в таком случае InvalidCast.
2) оригинальный говнокод падает с NullReference если o == null. Ваш - возвращает null.
P.S. Что-за прикол выдрачивать байты из IL? Имхо, попахивает преждевременной оптимизацией аля "одинарные кавычки в PHP работают быстрее двойных".
Меня больше заинтересовало поведение компилятора с 2мя explicit cast'ами в тернарном операторе, а не накладывания сверху оптимизированной кучи на существующую кучу.
P.S. Что-за прикол выдрачивать байты из IL?
Ну, это вопрос практики говнокоженья на шарпе, можно и StringBuilder не использовать, ведь String'а заглаза хватает. Или достаточно новый холивар "List vs Array" и т.п...
P.S. Это не относится к микроконтроллерам и другим прокрустовым ложам, в которых каждый байт и такт в цене.
Свалится с InvalidCastException.
При использовании ключевого слова as получаем null:
В результате получаем возможный "Mad girlfriend bug" где-то ниже по коду. Для примера:
И в результате:
1) Произойдёт ошибка NullReferenceException, а не InvalidCastException.
2) Ошибка произойдёт не во время каста, а во время вывода сообщения, т.е. n строками ниже.
Вот кстати в этом отношении жаба рулит. На ней это звучало бы так:и не крашилось бы ни при каких условиях ;)
Которую можно использовать, скажем, так:
А в ресурсах уже строка куда подставить значение. И если o==null, то будет пустая строка.
Аналогично String.Format(...).
Вариант @abatishchev применим в случаях, когда неправильный тип это вполне допустимая ситуация, и ловить InvalidCast, а потом все-равно делать абсолютно то же самое, что и при null было бы неудобно и бессмысленно.
Ваш вариант удобнее в случаях, когда неправильный тип - это недопустимая, но редкая ситуация, которую никто не будет обрабатывать. А просто в свое время прочтут бектрейс и исправят истинную причину бага.
Вот такое мое имхо.
Не соглашусь, кодинг на .NET'е рекомендует по любому поводу выбрасывать исключение, особенно если это метод, а не инлайн переменная, и если входной параметр такой абстрактный.
Как я понимаю, это связано с тем же WinAPI, где часть функций выбрасывало Exception, а часть модифицировали результатирующее значение, при появлении которого необходимо было читать GetLastError.
В свою очередь, использование GetLastError, я предполагаю, связано с тем, что директория Exception Table в PE файле появилась не так чтобы и давно, а вот CorILMethodSect, которая предоставляет аналогичную таблицу адресов, в толстом формате методов таблицы MethodDef были заложены в первую версию ecma-335.
А по поводу ключевого слова "as", у меня был опыт говнокодинга, когда я нарвался на подобный плавающий баг с бездумным использованием этого ключевого слова, после этого решил что лучше обработать first chance exception с явным преобразованием, а уже на лог-сервере, если это реально лишнее, отсеять CEP'ом.
return o as bool?;
проверка после return'а - бессмысленна. А в некоторых случаях (threat warnings as errors) даже не соберётся.
Речь была про минусовальщика, вот я и захотел объяснить за что минусователь поставил минусы. Заодно наткнулся на интересное поведение явного преобразования в тернарном операторе, что и попытался объяснить в своём первом посте в этой теме.
Хотя, если вообще убрать эту функцию, то проще заменить её на:
или так (если не нравится поведение метода ToBoolean при передаче value=null):
Или даже так (Если не нравится отсутствие структуры Nullable<T> в .NET 1.1):
А чтобы не писать лишнего кода, проше написать предложенный Вами вариант.
Код:
будет короче аналогичного кода с использованием as:
Хотя и в таком случае можно получить NullReferenceException при обращении к свойству Value.
Так что самый красивый вариант будет проверить o на null, а затем уже делать преобразование:
По сравнению с Вами - я не знаток шарпа :)
Да ну бросьте ;) Я его никогда не учил даже... недельный не очень удачный опыт общения с шарпиком лет 6-7 назад, и созерцание шедевров на нем на ГК...
Мне ближе c, c++ и, как не странно, жаба.
> созерцание шедевров на нем на ГК...
same shit.
Полагаю таким же образом Тарас выучил С++, годами обсирая его на крестофоруме.
мужская логика bool да/нет
женская логика bool? да/нет/не знаю
=)
ps
рыдаю
тянет на отдельный говнокод )