Здравствуйте, sergeyt4, Вы писали:


S>Вот, к примеру, очень полезный метод:

S>

S>public static IEnumerable<TSource> AsEnumerableSafe<TSource>(this IEnumerable<TSource> source)
S>{
S>    return source ?? System.Linq.Enumerable.Empty<TSource>();
S>}
S>

а у нас такое называется EmptyIfNull, на мой взгляд это более прозрачно

Здравствуйте, Аноним, Вы писали:

А>Как же люди код на C++ сопровождают?
Ответ в вопросе: они сопровождают код на C++, и там это норма, а в C# — нет. "Здесь так принято", ага.

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

Глядя на этот фрагмент кода, какое предположение о типе переменной info вы сделаете?

var info = GetDetailInfo();
if (info) // вроде Boolean
{
  Debug.WriteLine(info.ToString());

  // ...
}

Теперь вы читаете код дальше и видите другую строчку:

ValidateInfo(info); // хм, нафига делать валидацию Boolean?

а потом еще:

  if (info.IsValid()) // блин, у Boolean точно нет метода IsValid,
                      // может быть, это extension?
  {
    // ...
  }

В итоге вы лезете в определение типа и обнаруживаете там оператор приведения к Boolean.
Да, есть IntelliSense, да есть явное указание типа переменной (что не всегда удобно и можно забыть, какой у нее тип, если метод достаточно длинный), но это все равно лишние телодвижения. Ради чего?

Еще 5 копеек о преобразовании типов. Кмк, идеологически, преобразование типов — это преобразование данных, т.е. состояния объектов с использованием какой-то закономерности. В том, что делает ТС, преобразования состояния объекта нет, оно не анализируется, а в случае с null просто не может быть проанализировано. Т. е. отверткой забиваются гвозди.

Здравствуйте, Eldar9x, Вы писали:

E>Вот, думаю... Для удобства почти во всех классах пишу:
E> public static implicit operator bool(AnyClass anyCalss)

E>Нет ли тут подводных камней?
Есть. Шарп — это не тот язык, на которой можно писать коротко. Шарп — это язык, на котором можно писать код, легко поддерживаемый и понятный другому разработчику с первого взгляда.
Поэтому замена if (obj != null) на if (obj) духу языка очевиднейшим образом не соотвествует. Как и переименование функций "покороче" (bool SupportsTransaction { get; } в bool Trans ), как и кодогенерация самописными утилитами, как и разведение всевозможного "сахара" и "магии"

Купите Вашим разработчикам студию с интеллесенсом, а если не поможет — то курс "Соло на клавиатуре". На стоимости поддержки кода окупится

Здравствуйте, Eldar9x, Вы писали:

E>Ну, почему же? В С# я совсем не спец, поэтому и интересуюсь.

Так уже пояснили причину. Если вы пишете код не только для себя, то другим разработчикам будет трудно понять о чем речь. Я бы тоже предпочел явное сравнение, причем даже в С/C++, хоть и писать больше. Зато сразу видно о чем речь.

Здравствуйте, HowardLovekraft, Вы писали:

HL>Глядя на этот фрагмент кода, какое предположение о типе переменной info вы сделаете?
...
HL>В итоге вы лезете в определение типа и обнаруживаете там оператор приведения к Boolean.

+500
Этот индусский авнокод из-за нескольких символов ухудшает читаемость over 9000.

Здравствуйте, Eldar9x, Вы писали:

E>Именно! В том то и дело, что такой код легче читать. Ну, мне по крайней мере... Тогда как

obj != null

мозолит глаза .

Брейнфак твой выбор. Однозначно.

Здравствуйте, aloch, Вы писали:

A>Ну вот, например, нафига WPF уже в отлаженной и без ошибок работающей программе постоянно проверяет "а мы вызваны из того же потока, из которого созданы?".

Скорей всего потому, что без проверки и если действительно вызваны из другого потока, то получаем у клиента загадочные и слабовоспроизводимые баги типа мемори коррупшион.

Здравствуйте, b-3, Вы писали:


b-3>Поэтому замена if (obj != null) на if (obj) духу языка очевиднейшим образом не соотвествует. Как и переименование функций "покороче" (bool SupportsTransaction { get; } в bool Trans ), как и кодогенерация самописными утилитами, как и разведение всевозможного "сахара" и "магии"

b-3>Купите Вашим разработчикам студию с интеллесенсом, а если не поможет — то курс "Соло на клавиатуре". На стоимости поддержки кода окупится

Плюсую.

Здравствуйте, hardcase, Вы писали:

L>>

H>Я считаю что это лучше чем оператор неявного преобразования в bool. Автор говорил про читабельность — в моем варианте она на высоте.

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

Здравствуйте, b-3, Вы писали:

E>>Нет ли тут подводных камней?
b-3>Есть. Шарп — это не тот язык, на которой можно писать коротко. Шарп — это язык, на котором можно писать код, легко поддерживаемый и понятный другому разработчику с первого взгляда.
b-3>Поэтому замена if (obj != null) на if (obj) духу языка очевиднейшим образом не соотвествует. Как и переименование функций "покороче" (bool SupportsTransaction { get; } в bool Trans ), как и кодогенерация самописными утилитами, как и разведение всевозможного "сахара" и "магии"

Даешь очередной виток флейма var vs "явное указание типа".

Здравствуйте, _d_m_, Вы писали:

HL>>В итоге вы лезете в определение типа и обнаруживаете там оператор приведения к Boolean.

___>+500
___>Этот индусский авнокод из-за нескольких символов ухудшает читаемость over 9000.
___>

Не, индусский выглядел бы вот так:

if ((info != null).ToString().ToLower() == "true")

Здравствуйте, Lloyd, Вы писали:

b-3>>Поэтому замена if (obj != null) на if (obj) духу языка очевиднейшим образом не соотвествует.
L>Даешь очередной виток флейма var vs "явное указание типа".

Я удивлён, как ещё в какой-нибудь Resharper не встроили рефакторинг с заменой var

Здравствуйте, b-3, Вы писали:

L>>Даешь очередной виток флейма var vs "явное указание типа".

b-3>Я удивлён, как ещё в какой-нибудь Resharper не встроили рефакторинг с заменой var

Вообще-то встроили.

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, _d_m_, Вы писали:

HL>>>В итоге вы лезете в определение типа и обнаруживаете там оператор приведения к Boolean.

___>>+500
___>>Этот индусский авнокод из-за нескольких символов ухудшает читаемость over 9000.
___>>

L>Не, индусский выглядел бы вот так:

L>

L>if ((info != null).ToString().ToLower() == "true")
L>

L>

Круче:

if( ФункцияАнглоИндускогоПереводчика<ТЯзыкИсходный, ТЦелевойЯзык>((info != null).ToString().ToLower()) == "तात्विक" )

Здравствуйте, b-3, Вы писали:

b-3>Здравствуйте, Lloyd, Вы писали:

b-3>>>Поэтому замена if (obj != null) на if (obj) духу языка очевиднейшим образом не соотвествует.
L>>Даешь очередной виток флейма var vs "явное указание типа".

b-3>Я удивлён, как ещё в какой-нибудь Resharper не встроили рефакторинг с заменой var

Однако в некоторых случаях лучше вар:

Dictionary<string, SuperPuperMegaTip> asd = new Dictionary<string, SuperPuperMegaTip>();
// или
var asd =  new Dictionary<string, SuperPuperMegaTip>();

Здравствуйте, Eldar9x, Вы писали:

E>Вот, думаю... Для удобства почти во всех классах пишу:

E>Нет ли тут подводных камней?

var a = new AnyClass();
var b = new AnyClass();
if (a = b) // одна маааахонькая опечатка...
    Console.WriteLine("Ouch!");

Здравствуйте, _d_m_, Вы писали:

___>Однако в некоторых случаях лучше вар:
___>

Dictionary<string, SuperPuperMegaTip> asd = new Dictionary<string, SuperPuperMegaTip>();
// или
var asd =  new Dictionary<string, SuperPuperMegaTip>();

Не в "некоторых", а в тех, в которых тип написан где-то рядом.

Есть люди, пишущие так:

class MyClass
{
  var member = FooInit();

  /* на 5 экранов ниже  */
  static ILookup<string, IDictionary<MyPODKey, object>> FooInit() { /* ... */ } 
}

В особо запущенных случах попытка поговорить об этом приводит к жалобам на "какой плохой язык C#, что нельзя написать static var FooInit()" и в пример ставится какой-нибудь F#/Haskell Хотя на самом деле тут дело в неумении использовать статическую типизацию.

Здравствуйте, b-3, Вы писали:

b-3>В особо запущенных случах попытка поговорить об этом приводит к жалобам на "какой плохой язык C#, что нельзя написать static var FooInit()" и в пример ставится какой-нибудь F#/Haskell Хотя на самом деле тут дело в неумении использовать статическую типизацию.

Причем тут неумение использовать статическую типизацию, если var не отменяет статическую типизацию?
И модификатор static (var) к статической типизации отношения не имеет.

Здравствуйте, Eldar9x, Вы писали:

E>чтобы проверку на null делать так:

E>

E>if (anyClassInstance)
E>{
E>}
E>

E>Нет ли тут подводных камней?

Ха. Ха. Ха.

Архитекторы C# заботливо убрали эту граблю C++, а неразумное дитя прикладного программирования взяло и эту граблю себе обратно поставило.

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

Здравствуйте, samius, Вы писали:

S>Здравствуйте, b-3, Вы писали:

b-3>>В особо запущенных случах попытка поговорить об этом приводит к жалобам на "какой плохой язык C#, что нельзя написать static var FooInit()" и в пример ставится какой-нибудь F#/Haskell Хотя на самом деле тут дело в неумении использовать статическую типизацию.

S>И модификатор static (var) к статической типизации отношения не имеет.
Я про глобальное выведение типов, которого в C# нет, а некоторым хочется. В частности, чтобы не писать типы возвращаемых значений у функций (var Foo()).

S>Причем тут неумение использовать статическую типизацию, если var не отменяет статическую типизацию?
При том, что статическая типизация существует не только для того, чтобы осложнить жизнь программисту и заставить его писать лишние буквы. Я правильно понял, что вы считаете пример с FooInit нормальным кодом?