Взаимоблокировки в статических конструкторах

Поскольку в Гугл+ так и не нашлось объяснения странного поведения приведенного там кода, то я решил рассказать об этом более подробно.

Итак, вопрос заключается в следующем: что мы ожидаем увидеть при исполнении следующего кода и что мы увидим на самом деле?

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);
    }
}

Аргументы по умолчанию в C#

«При наличии общего механизма перегрузки функций аргументы по умолчанию становятся логически избыточными и в лучшем случае обеспечивают небольшое удобство нотации»
                                                                                            Б. Страуструп «Дизайн и эволюция С++»

Многие разработчики, перешедшие в .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),
};

Вопрос #1. Будет ли работать следующий цикл foreach?

foreach (double d in bigDoubles)
{
    Console.WriteLine(d);
}

Вопрос #2. Что мы получим в следующих случаях?

var query = from double d in bigDoubles
            select d;
 
foreach (var d in query) { Console.WriteLine(d); }

О книге Боба Мартина “Чистый код”

(Картинка без намека, просто уж очень хотелось котика в статью добавить! Ведь это основной залог популярности в интернетах, правда? :))

У меня очень неоднозначное отношение к книгам Роберта Мартина… В них довольно много здравых и интересных мыслей, но иногда они выражаются столь категорично, что неокрепшим программерским мозгом они могут восприниматься неправильно. Если же мозг читателя достаточно окреп, чтобы воспринимать советы прагматично, то есть все шансы, что ничего нового из этих советов он (мозг или программист) не вынесет.

 

О комментариях. Часть 2

В прошлый раз мы рассмотрели основные подходы к комментированию кода, а в этот раз я хочу рассмотреть эти советы на простых практических примерах.

1. Комментарии из серии «ни о чем». Или зачем дублировать код?

Основные претензии к комментариям заключаются в том, что они устаревают или просто дублируют код, описывая его на том же уровне абстракции, что и сам код. Ниже представлен утрированный антипаттерн:

О комментариях

"Не стоит относиться к комментариям как к "абсолютному добру". На самом деле, комментарии в лучшем случае являются неизбежным злом. Если бы языки программирования были достаточно выразительными или если бы мы умели искусно пользоваться этими языками для выражения своих намерений, то потребность в комментариях резко снизилась бы, а может быть и вовсе сошла "на нет".
Роберт Мартин "Чистый код"

"Комментарии должны сообщать о коде что-то такое, что он не может сообщить он сам – в виде заключения или в виде намерений".
Стив Макконнелл "Совершенный код"

Пример тестируемого дизайна

В комментариях к предыдущей заметке был задан такой вопрос:

«Вот есть, сккажем, класс, который читает какой-нибудь файл и потом его анализирует. Как такое тестировать?

Неужели надо вынести код чтения файла в отдельный класс, создать интерфейс и передать экземпляр через конструктор? Боюсь, если так буду делать, то не закончу и половины вовремя.»

Здесь очень мало информации, поэтому все мои рассуждения можно использовать лишь в качестве отправной точки дизайна и реализации. Любой исходный дизайн эволюционирует по мере развития требований и понимания задачи, но определенные подходы применимы даже при таком наборе «входных данных».