Конференция DotNext 2015 Moscow уже скоро! Мне посчастливилось быть в программном комитете этого замечательного мероприятия, так что я теперь в курсе закулисной деятельности: наблюдаю за общей организацией и помогаю готовить доклады. Организаторы долгими неделями трудятся с утра и до вечера, чтобы у вас была возможность на один день погрузиться в уникальную атмосферу: послушать крутые доклады, пообщаться с умными людьми, завести полезные знакомства, покушать вкусной еды, вдохновиться на великие свершения и просто хорошо провести время.

Впрочем, самым важным на конференции является не атмосфера, а контент. В этом году программа очень насыщенная: 22 докладчика (из которых 7 являются MVP) будут в 4 потока целый день рассказывать вам про .NET. Темы будут самые разные: есть доклады про новинки .NET-мира, про современные подходы и тенденции разработки ПО, про использование хороших библиотек/инструментов и про много чего ещё. Но моя любимая тема — это внутренности .NET, потроха рантайма и прочий хардкор. Мне кажется, что рано или поздно каждый сеньор разработчик приходит к осознанию того, что для разработки действительно сложных продуктов явно не помешает понимать, что же происходит под капотом наших программ. Увы, разбираться с этим самостоятельно зачастую долго и сложно: слишком уж много всего надо изучить. Поэтому с каждой следующей конференцией DotNext мы повышаем градус хардкора и пытаемся умудриться в течение одного дня загрузить в оперативную память разработчиков максимальное количество интересной и полезной информации о том, что же на самом деле делают наши приложения и как их лучше писать.

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

Что такое фильтры исключений?

Фильтры исключений (Exception Filters) — новая фича C# 6, которая позволяет устанавливать специфические условия для блока catch. Этот блок будет исполнятся только в случае, если указанные условия выполнены. Проиллюстрируем синтаксис небольшим фрагментом кода:

public void Main()
{
  try
  { 
    throw new Exception("E2");
  }
  catch(Exception ex) when(ex.Message == "E1")
  {
    Console.WriteLine("caught E1");
  }
  catch(Exception ex) when(ex.Message == "E2")
  {
    Console.WriteLine("caught E2");
  }
}

Каждый C#-разработчик знает, что C#-компилятор переводит исходный код программы в промежуточный язык под названием Intermediate Language (IL). А за превращение IL в последовательность машинных команд чаще всего отвечает Just-In-Time-компилятор (JIT). Да, на сегодняшний день есть NGen, Mono AOT, .NET Native, но JIT-компиляция всё ещё лидирует в мире .NET-приложений. А вот работает этот самый JIT, знают далеко не все. Если брать в расчёт только реализацию .NET от Microsoft, то стоит различать JIT-x86 и JIT-x64. А ещё за дверями стоит RyuJIT который уже совсем скоро займёт почётное место основного JIT-компилятора. А если вы любите старые версии .NET, то полезно знать, что в разных версиях CLR логика работы JIT отличалась. Исходники у нас теперь открыты, вы можете их посмотреть и осознать, насколько же это большая и сложная тема. Сегодня мы не будем пытаться охватить её, а лишь кратко посмотрим на несколько интересных особенностей отдельных версий JIT-компиляторов. Итак, сегодня в номере:

• Почему короткий метод может не быть заинлайнен и как этого избежать
• JIT-баги: опасные и беспощадные
• Кто и как разматывает циклы
• Чем отличается размотка маленьких и больших циклов

Чем больше я пишу на C# 6, тем больше убеждаюсь в том, насколько оператор ?. (null coalescing operator) помогает писать чистый простой и понятный код. Сегодня я покажу 4 ситуации, в которых он может быть очень полезен.

Большая вложенность

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

var location = default(string);
if (vendor != null)
{
    if (vendor.ContactPerson != null)
    {
        if (vendor.ContactPerson.HomeAddress != null)
        {
            location = vendor.ContactPerson.HomeAddress.LineOne;
        }
    }
}

Но теперь у нас есть C# 6, с ним код можно привести на намного более читаемому виду:

var location = vendor?.ContactPerson?.HomeAddress?.LineOne;

Оператор ?. сделает так, что как только в одном из свойств цепочки окажется null, дальнейшее вычисление выражения производится не будет. Посмотрим ещё несколько примеров.

Есть такой язык программирования, который называется C#. И есть очень много разработчиков, которым он очень нравится. А ещё есть такой язык программирования, который называется JavaScript. Как-то так сложилось, что он нравится далеко не всем C#-разработчикам. А теперь представьте ситуацию: есть заядлый C#-разработчик. Он очень любит C#, все-все проекты на нём пишет. Но судьба распорядилась так, что ему понадобилось написать клиентское веб-приложение. Знаете, такое, чтобы пользователю не нужно было себе ничего скачивать и устанавливать, чтобы он мог просто открыть любой браузер в любой операционной системе на любом устройстве — а приложение уже там. И вот тут у нашего лирического героя возникла проблема: вроде бы JavaScript идеально подходит для этой задачи, но вот писать на нём отчего-то не очень хочется. К счастью, в современном мире существует много языков, которые транслируются в JavaScript (всякие TypeScript, CoffeScript и тысячи других). Но наш разработчик оказался очень упрямым: он упорно не хочет изменять своему любимому C# с «вражескими» технологиями.

К счастью для него, счастливое будущее уже практически наступило. Есть такой проект, который называется DuoCode. Он умеет транслировать C#-код в JavaScript. Пока он в состоянии beta, но у него уже весьма неплохо получается: поддерживаются нововведения C# 6.0, Generic-типы, Reflection, структуры и LINQ, а отлаживать итоговый JavaScript можно на исходном C#. Давайте посмотрим внимательнее, что же представляет из себя продукт.

В последнее время многие обсуждают недавние открытие CoreCLR и CoreFX от Microsoft. Напомню, что ядро CLR и реализация базовых классов .NET у нас теперь открытые, кроссплатформенные и распространяются под MIT. Таким образом, вы можете собрать свою собственную версию рантайма, которая будет работать под Windows, Linux и Mac. И многих терзал вопрос: а что же теперь будет с Mono? Недавно появились черновики Mono 4.0.0 Release Notes, из которых мы можем узнать о будущих планах компании Xamarin. Итак, сегодня в номере:

• Adoption of Microsoft’s open source code
• Floating point optimizations
• We dropped support for the 2.0, 3.5 and 4.0 assemblies
• Updated IKVM

Обсудим грядущие изменения чуть подробней.

Высокоуровневые языки программирования содержат в себе много абстрактных программистских конструкций, таких как функции, условные операторы и циклы — они делают нас удивительно продуктивными. Однако одним из недостатков написания кода на высокоуровневом языке является потенциальное значительное снижение скорости работы программы. Поэтому компиляторы стараются автоматически оптимизировать код и увеличить скорость работы. В наши дни логика оптимизации стала очень сложной: компиляторы преобразуют циклы, условные выражения и рекурсивные функции; удаляют целые блоки кода. Они оптимизируют код под процессорную архитектуру, чтобы сделать его действительно быстрым и компактным. И это очень здорово, ведь лучше фокусироваться на написании читабельного кода, чем заниматься ручными оптимизациями, которые будет сложно понимать и поддерживать. Кроме того, ручные оптимизации могут помешать компилятору выполнить дополнительные и более эффективные автоматические оптимизации. Вместо того чтобы писать оптимизации руками, лучше бы сосредоточиться на дизайне архитектуры и на эффективных алгоритмах, включая параллелизм и использование особенностей библиотек.

Данная статья посвящена оптимизациям компилятора Visual C++. Я собираюсь обсудить наиболее важные техники оптимизаций и решения, которые приходится применить компилятору, чтобы правильно их применить. Моя цель не в том, чтобы рассказать вам как вручную оптимизировать код, а в том, чтобы показать, почему стоит доверять компилятору оптимизировать ваш код самостоятельно.

От переводчика: мы в компании Энтерра очень любим алгоритмы компьютерного зрения. Работаем чаще всего с OpenCv. Время от времени нам пишут разные разработчики с вопросами: «А как лучше начать работать с OpenCv?» или «Какую интересную задачу можно просто решить с помощью OpenCv?» В связи с чем мы решили перевести очень хорошую статью, которая будет полезна всем, кто интересуется компьютерным зрением.



Черная Пятница близко.

Толпы злых покупателей. Рой одинаковых теток среднего возраста, готовых сожрать практически всё, что угодно, в ближайшем супермаркете — главное, что со скидкой 75%. Они выстроятся в очереди перед дверьми магазинов в полночь Дня благодарения. Они будут ломиться внутрь, стучать в запертые двери кулаками и головами, пока не сплющат друг друга и не разобьют руки в кровь, став похожими на зомби из «28 дней спустя». Но вместо человеческой плоти, они жаждут удовлетворить инстинкт покупателя. Их боевые кличи о скидках и распродажах достигают небес. А их громовая поступь способна привести к землетрясению на Великой Равнине.

Естественно, от СМИ помощи не жди — они будут смаковать каждую подробность. От обмороженных семейств, ночевавших в палатке на морозе, до старой леди, растоптанной охотниками за скидкой в момент, когда открылись двери. Что-то похожее случилось с галлимимусом в «Парке Юрского периода». А она просто хотела купить Halo для девятилетнего внука Тимми, чьи родители забыли это сделать в прошлом году. В Wal-Mart. Во время Черной Пятницы.

И я обязан спросить: весь этот хаос и бедлам стоят того?

Чёрт возьми, нет!

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

Просто представьте, как глупо вы будете выглядеть, стоя в очереди в ожидании свободной кассы – только для того, чтобы после сканирования штрихкода последнего сезона «Игры Престолов» выяснить, что в Target его можно купить на 5 долларов дешевле?

Собственно, далее я покажу, как можно обнаружить штрихкод на изображении, используя только Python и OpenCV.

С каждым днём кроссплатформенная разработка под .NET становится всё более реальной. А после недавнего анонса официальной поддержки Linux/MacOS счастливое будущее стало ещё немножечко ближе. Вышеприведённая картинка утратила свою былую актуальность, ведь исходники теперь будут под MIT. Впрочем, писать кроссплатформенные .NET-приложения можно достаточно давно — в этом нам помогает Mono. Но вот отношение к нему в сообществе довольно неоднозначное. Мне зачастую приходится слышать изречения вроде «Mono тупит, под него всё в три раза медленнее работает» или «Под Mono вообще нормально ничего не запускается». Причём очень редко доводится слышать от этих людей конкретные факты. Вопросы «А что конкретно тупит?» или «А что конкретно не работает?» повергают их в ступор. Не всех (некоторые способны на конструктивную дискуссию), но большинство. Чаще всего начинаются возмущённые ответы в духе «Да вообще ничего не работает! А если и работает, то очень медленно!». В конце беседы создаётся впечатление, что каждая конечная машинная команда под Mono работает в несколько раз медленнее, а в половине исходников стоят throw new Exception().

В этом посте мне хотелось бы немножко поделиться опытом. Не так давно мы портировали наш продукт PassportVision (анонс на Хабре) под Linux. Могу заявить, что работает он вполне нормально. Да, чутка медленнее, чем под Windows на классическом .NET от Microsoft (далее — MS.NET). Но работает вполне стабильно, а падение производительности не принципиальное. При этом продукт у нас достаточно большой и вполне попадает под категорию enterprise, а возможности C#/.NET мы используем на полную катушку. Так что завести большое серверное приложение под .NET реально — было бы желание. Также мне довелось беседовать с разными разработчиками, которые пишут что-то под Mono — истории в большинстве своём успешные.

Но почему же тогда встречается столько негатива в сторону Mono? Я считаю, что проблема в том, что люди не особо хотят разбираться в разнице между рантаймами. Запустили разок какое-нибудь .NET-приложение под Linux на Mono 2.4, а оно с ходу не запустилось — всё, Mono целиком плохой, не будем его использовать. А в итоге виноват оказывается один-единственный метод, у которого реализация немного отличается от MS.NET. Новые версии Mono выходят раз в пару месяцев, реализацию уже давно поправили, но люди всё равно продолжают ходить и хаять бедный Mono, не желая разбираться в деталях.

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

Невероятно, но факт: с момента релиза JQuery прошло уже почти восемь лет. Веб-разработка сильно изменилась за эти годы, и JQuery менялась вместе с ней. И всё это время наша команда старалась сохранить безупречный баланс между совместимостью с устаревшим кодом и поддержкой самых современных методов веб-разработки.

Один из лучших способов это сделать — семантическое версионирование (semver). В практическом плане, для разработчиков и инструментов разработки, SemVer дает представление о рисках, связанных с переходом на новую версию программного обеспечения. Номера версий представлены в формате MAJOR.MINOR.PATCH, где каждый из трёх компонентов – целое число. Согласно SemVer, если меняется номер MAJOR, это указывает на существенные изменения API, с которыми разработчикам нужно быть очень осторожными.

Эта концепция версионирования обрастает нюансами, если говорить о jQuery, ведь совместимость с браузерами может быть так же важна, как совместимость API. В попытке создать более изящную jQuery, команда выпустила две версии в 2013 году. Первая осталась в линейке 1.* (сегодня это 1.11.1) и обеспечивает совместимость с максимальным количеством браузеров. Вторая версия, начиная с 2.0.0 и до сегодняшней 2.1.1, исключает поддержку ряда браузеров типа IE8 и ниже, чтобы оптимизировать код. Как 1.*, так и 2.* версии jQuery имеют одинаковый публичный API, хотя в их внутренней реализации есть некоторые различия.

Наши будущие релизы будут использовать другую номенклатуру. Как прежде, речь идет о двух разных пакетах. Преемником сегодняшней версии 1.11.1 будет jQuery Compat 3.0. Преемником jQuery 2.1.1 станет jQuery 3.0. Речь идет о двух разных пакетах на npm и Bower, но при этом они будут иметь одинаковую версию, чтобы обозначить тот факт, что их API одинаков.

Мы — небольшой стартап в Чарльстоне, Южная Каролина. Мы принимаем заказы с помощью текстовых сообщений и распечатываем их непосредственно в ресторанах.

Мы запустили eatabit.com в Чарльстоне почти год назад. За это время наш API распечатал более 9300 заказов на еду у наших клиентов — это рестораны, стадионы, курсы гольфа. Работа с мобильной связью не отличается простотой — особенно в зонах с повышенной нагрузкой на сеть, как на стадионах во время матчей, но наши системы отслеживают ситуации вроде плохого качества сигнала или разрывов.

Вне всяких сомнений, Pro Git — это одна из лучших книг про систему контроля версий git. Совсем недавно появилось второе издание этой замечательной книжки. Большие изменения произошли в издательском процессе: исходный код книги теперь хранится в AsciiDoc, а не в Markdown, а различные форматы (PDF, ePub и Mobi) автоматически генерируются с помощью O'Reilly Atlas platform. Разработка книги активно ведётся на гитхабе, актуальная online-версия находится в открытом доступе на официальном сайте, а любители печатной продукции могут заказать себе экземпляр на Amazon. Второе издание получилось почти в два раза больше первого: на сегодняшний день PDF-версия содержит 570 страниц. Помимо улучшения старого материала, книжка также пополнилась новыми главами и разделами:

Этот пост предназначается всем любителям платформы .NET и языка C#. Думаю, многие встречали на просторах сети разнообразные задачки на понимание тех или иных особенностей платформы или языка. Я большой любитель подобных задачек и головоломок. Они помогают глубже понять определённые области и повысить собственные программистские навыки. Однажды я решил сделать подборку подобных задачек, чтобы можно было показывать другим людям и обсуждать нюансы работы с .NET/C#. Когда задачек накопилось достаточное количество, появилась новая мысль — оформить мою подборку в виде книжки. Вашему вниманию предоставляется текущий вариант этого сочинения под названием «Задачник.NET».


Читать online
Скачать PDF-версию
Исходные коды на GitHub

Сегодня мы поговорим о региональных настройках. Но сперва — небольшая задачка: что выведет нижеприведённый код? (Код приведён на языке C#, но рассматривается достаточно общая проблематика, так что вы можете представить на его месте какой-нибудь другой язык.)

Console.WriteLine((-42).ToString() == "-42");
Console.WriteLine(double.NaN.ToString() == "NaN");
Console.WriteLine(int.Parse("-42") == -42);
Console.WriteLine(1.1.ToString().Contains("?") == false);
Console.WriteLine(new DateTime(2014, 1, 1).ToString().Contains("2014"));
Console.WriteLine("i".ToUpper() == "I" || "I".ToLower() == "i");

Сколько значений true у вас получилось? Если больше 0, то вам не мешает узнать больше про региональные настройки, т. к. правильный ответ: «зависит». К сожалению, многие программисты вообще не задумываются о том, что настройки эти в различных окружениях могут отличаться. А выставлять для всего кода InvariantCulture этим программистом лениво, в результате чего их прекрасные приложения ведут себя очень странно, попадая к пользователям из других стран.Ошибки бывают самые разные, но чаще всего связаны они с форматированием и парсингом строк — достаточно частыми задачами для многих программистов. В статье приведена краткая подборка некоторых важных моментов, на которые влияют региональные настройки.

Проектирование интерфейсов — ремесло очень сложное. Увы, не очень понятно, как этому ремеслу учиться. Разумеется, на сегодняшний день существует огромное количество разных хороших книжек про разные хорошие подходы к этому самому проектированию. Однако практика подсказывает, что даже если вы их все вдумчиво прочитаете, то это не будет означать, что вы будете уметь в любой ситуации создавать идеальный UI. А всё дело в том, что подобная деятельность скорее является своего рода искусством, нежели следованием набору правил. Но как же этим искусством овладевать, если хорошие книжки не дадут необходимых навыков? Нам кажется, что ключевым фактором в этом деле всё-таки является опыт. Но учиться только на своём опыте — занятие долговременное, лучше бы и на других людей поглядывать (и это далеко не только к интерфейсам относится).

Давайте немного поговорим о том, как правильно перенимать чужой опыт. У нас есть много знакомых команд, которые разрабатывают действительно крутые приложения. И при показе нам своих интерфейсов они начинают рассказывать, что и как они сделали. А мы всегда спрашиваем, почему они так сделали, почему они пришли именно к такому решению. И нам кажется, что это самый правильный вопрос. Да, бывают гениальные люди, которым без всякой матчасти во сне привидится идеальный интерфейс без разного рода тяжёлых размышлений о том, как делать хорошо, а как делать плохо. Но таких людей мало, а на подобном опыте многому не научишься. Образное мышление действительно развивается, когда тебе рассказывают о мотивации каждого своего решения (даже самого маленького). Мол, мы сначала сделали так и так, но пользователям было неудобно ввиду вот этого, поэтому мы переделали всё вот так, и теперь все живут счастливо.

В этом посте мы хотели бы рассказать историю одной формочки, которую мы сделали при разработке нашего продукта PassportVision (о котором уже рассказывалось на Хабре). Это одна-единственная небольшая формочка, но мы её делали целый год. Насколько хорошо у нас получилось — судить вам, но пользователи весьма довольны (а разве не это критерий удачного интерфейса?). Мы многократно переделывали разные штуки, горячо спорили о разных мелочах, но в конце концов получилось то, чем удобно пользоваться. Впрочем, нам думается, что через год мы взглянем на этот пост, взглянем на наш к тому времени уже старый UI и скажем: «О Господи! Мы что, действительно отдавали это пользователям? Ох, стыдно, как же стыдно». Но всё правильно — интерфейс постоянно должен развиваться, эволюционировать, становиться лучше. А сегодня мы поговорим о том, что имеется на сегодняшний день и как же мы к этому пришли.

Мне нравится рефакторинг. Нет, не так. Я люблю рефакторинг. Не, даже не так. Я чертовски люблю рефакторинг.
Я не переношу плохой код и плохую архитектуру. Меня коробит, когда я пишу новую фичу, а в соседнем классе творится полный бардак. Я просто не могу смотреть на печально названные переменные. Иногда перед сном я закрываю глаза и представляю, что можно было бы улучшить в проекте. Иногда я просыпаюсь в три часа ночи и иду к ноутбуку, чтобы что-нибудь поправить. Мне хочется, чтобы на любой стадии разработки код был не просто кодом, а произведением искусства, на которое приятно смотреть, с которым приятно работать.

Если вы хоть немного разделяете мои ощущения, то нам есть о чём поговорить. Дело в том, что со временем что-то внутри меня начало подсказывать, что рефакторить всё подряд, везде и всё время — не самая лучшая идея. Поймите меня правильно, код должен быть хорошим (а лучше бы ему быть идеальным), но в условиях суровой реальности не всегда разумно постоянно заниматься улучшением кода. Я вывел для себя несколько правил о своевременности рефакторинга. Если у меня начинают чесаться руки что-нибудь улучшить, то я оглядываюсь на эти правила и начинаю думать: «А действительно ли сейчас тот момент, когда нужно нарефакторить?». Давайте порассуждаем о том, в каких же случаях рефакторинг уместен, а в каких — не очень.

Наверняка вам доводилось попадать в такую ситуацию: заходите в какое-нибудь учреждение (почта, банк, больница, кассы и т. п.), где для достижения ваших целей необходимо предъявить паспорт. И вроде очередь-то небольшая, всего 5 человек, но ждать придётся очень долго, ведь тётя Маша тратит по несколько минут на внесение данных с каждого паспорта в компьютер. Вам остаётся только наблюдать, как её указательный палец не спеша планирует над клавиатурой в поисках очередной клавиши.

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



Сегодня в выпуске:

• Популярные заблуждения о паспортах
• Немного об используемых технологиях
• Наш подход к интерфейсу
• Как лучше всего отдать данные пользователю

Рассмотрим простую задачу: есть некоторый достаточно большой неизменный набор чисел, к нему осуществляется множество запросов на наличие некоторого числа в этом наборе, необходимо максимально быстро эти запросы обрабатывать. Одно из классических решений заключается в формировании отсортированного массива и обработке запросов через бинарный поиск. Но можно ли добиться более высокой производительности, чем в классической реализации? В этой статье мне хотелось бы рассказать про Cache-Conscious Binary Search. В данном алгоритме предлагается переупорядочить элементы массива таким образом, чтобы использование кэша процессора происходило максимально эффективно.

У меня есть проблема — я перфекционист. Я люблю совершенный код. Ведь это не только правильный подход к написанию программ, но и настоящее искусство. От чтения хорошего листинга я получаю не меньше удовольствия, чем от чтения хорошей книги. Проектировать архитектуру большого проекта ничуть не легче, чем проектировать архитектуру большого здания, а в случае хорошей работы — результат не менее прекрасен. Порой меня завораживает то, как изящно переплелись паттерны проектирования в создании совершенной программной системы. Меня восхищает внимание к деталям, когда абсолютно каждый метод настолько прост и понятен, что претендует на место классического примера совершенного кода.

Но, увы, всё это великолепие разбивается о суровую действительность и реальные проекты. Если мы говорим о продакшн-проекте, то пользователей не волнует, насколько красив ваш код и насколько хороша архитектура, их волнует, чтобы проект хорошо работал. Но я всё равно считаю, что в любом случае нужно стремиться писать правильно, просто при этом фанатизма быть не должно. После чтения различных холиваров на тему правильных подходов к написанию кода мне в глаза бросилась одна тенденция: каждый пытается применить означенные подходы не в целом к программированию, а только к своему опыту разработки, к своим проектам. Многие не осознают, что хорошие практики — это не абсолютные правила, которые должны строго соблюдаться в 100% сценариев, это лишь советы о том, как следовало бы поступать в большинстве ситуаций. На каждую хорошую практику всегда можно придумать несколько дюжин примеров, в которых она работать не будет. Но это вовсе не означает, что хорошая практика не такая уж и хорошая, просто её применили не к месту.

По-настоящему хороший комментарий — тот,
без которого вам удалось обойтись.
Дядюшка Боб

В последнее время меня стали очень утомлять оживлённые дебаты о том, нужно ли комментировать код. Как правило, по одну сторону баррикад — самоуверенные джуниоры, имеющие непререкаемую позицию вида «А как же его не комментировать, ведь без комментариев непонятно будет!». По другую — умудрённые опытом сеньоры. Они понимают, что если возможно обойтись без комментариев, то «Лучше бы, чёрт возьми, так и сделать!». Наверное, у многих жажда комментировать идёт со студенческой скамьи, когда товарищи преподаватели заставляли комментировать каждую строчку, «чтобы студент лучше разобрался». В реальном проекте не должно быть кучи комментариев, которые только и делают, что засоряют код. Впрочем, я не агитирую вообще не писать комментарии, но если вам удалось написать такой код, который не требует пояснений, то расценивайте это, как свою маленькую победу. Сразу хотелось бы сослаться на нескольких очень умных книжек, на основе которых формировалась моя позиция. Я люблю и уважаю авторов этих работ, полностью разделяя их мнение.

• С. Макконнелл, «Совершенный код. Мастер-класс»
• Р. Мартин, «Чистый код. Создание, анализ и рефакторинг»
• Д. Босуэлл, Т. Фаучер, «Читаемый код, или Программирование как искусство»