Все-таки решил выделить все свои рецензии, обзоры и анонсы книг в отдельную статью, которая будет доступна с главной страницы и будет пополняться по мере поступления чего-то нового.
Интересно, как я читаю книги?
Интересно, что я еще читаю?
И хотя эти книги являются раем для читателя, их невероятно сложно писать. Чтобы понять это, достаточно попробовать написать статейку из серии "Используйте/не используйте эту возможность языка C#" или просто вспомните какой-нибудь холи-ворчик у себя в коллективе, который начался невинной фразой, "а давайте везде будем использовать as вместо оператора приведения типов" или другой подобной фразы.
Проблема любых советов из серии используй/не используй/избегай в том обилии исключений, которые следуют за любым подобным правилом. Вот, например, стоит ли использовать изменяемые значимые типы (mutable value types)? Любой программист, пришедший в .NET из С++ ответит положительно (ведь так быстрее!), потом он прочитает о проблемах и его мнение наверняка изменится на противоположное. После чего, в его голове может возникнуть барьер, который он уже не сможет преодолеть даже тогда, когда ему нужно будет пожертвовать безопасностью в угоду эффективности и использовать структуры в своем коде.
Статические конструкторы являются одной из самых странных возможностей C# и CLR и многие годы я не понимал их достаточно хорошо, но поскольку Джон (Скит) внес дополнительные разъяснения в мое понимание этой возможности, я все еще явно не до конца ее понимаю!
Эрик Липперт “Static constructors, part three”
Вопрос: в каком порядке будут вызваны экземплярные и статические конструкторы классов B и D при создании экземпляра класса D?
class B { }
class D : B { }
Ответ: конструкторы экземпляров вызываются от базового к наследнику, а статические конструкторы – it depends!
Поскольку в Гугл+ так и не нашлось объяснения странного поведения приведенного там кода, то я решил рассказать об этом более подробно.
Итак, вопрос заключается в следующем: что мы ожидаем увидеть при исполнении следующего кода и что мы увидим на самом деле?
class CrazyType
{
public static readonly int Foo = GetFoo();
private static int GetFoo()
{
return Task.Run(() => 42).Result;
}
}
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Main method get called!");
Console.WriteLine(CrazyType.Foo);
}
}
«При наличии общего механизма перегрузки функций аргументы по умолчанию становятся логически избыточными и в лучшем случае обеспечивают небольшое удобство нотации»
Б. Страуструп «Дизайн и эволюция С++»
Многие разработчики, перешедшие в .NET с языка С++ хотели увидеть в C# аргументы по умолчанию. И вот в C# 4.0 они появились, но с существенными ограничениями, особенно по сравнению с языком С++. Конечно эти особенности и ограничения не сложно запомнить, а их перечисление займет не больше пары строк, но вместо простого перечисления этих особенностей я предлагаю побывать в шкуре разработчиков этой фичи для языка платформы .NET и прийти к этим ограничениям и особенностям самостоятельно.
Поскольку мне говорят (точнее пишут), что я немного утомил с философией программирования и стоит браться за ум вспомнить и о технологиях, то я решил не откладывать это дело в долгий ящик, и опубликовать несколько заметок о языке C#. Тем более, что после подготовки к Hot Code остались некоторые наработки, которыми будет интересно поделиться.
Итак, у нас есть структура BigDouble с оператором неявного приведения типов к double и список этих структур:
struct BigDouble
{
private readonly double _value;
public BigDouble(double value) { _value = value; }
public static implicit operator double(BigDouble value)
{ return value._value; }
}
var bigDoubles = new List<BigDouble>
{
new BigDouble(42.0),
new BigDouble(18.0),
};
foreach (double d in bigDoubles)
{
Console.WriteLine(d);
}
var query = from double d in bigDoubles
select d;
foreach (var d in query) { Console.WriteLine(d); }
(Картинка без намека, просто уж очень хотелось котика в статью добавить! Ведь это основной залог популярности в интернетах, правда? :))
У меня очень неоднозначное отношение к книгам Роберта Мартина… В них довольно много здравых и интересных мыслей, но иногда они выражаются столь категорично, что неокрепшим программерским мозгом они могут восприниматься неправильно. Если же мозг читателя достаточно окреп, чтобы воспринимать советы прагматично, то есть все шансы, что ничего нового из этих советов он (мозг или программист) не вынесет.
