День пятьсот шестьдесят шестой. #ЗадачиНаСобеседовании
Топ 10 Умений Которые Понадобятся на Собеседовании
На собеседовании вам могут как задать самые разные вопросы по теории, так и дать практическое задание. Некоторые из них я уже приводил на канале: 1, 2, 3, 4.
Заучить их все просто нереально. Но большинство из них тестирует одно из следующих базовых умений, которым должен обладать каждый «уважающий себя» программист.

1. Двоичный (бинарный) поиск — классический алгоритм поиска элемента в отсортированном массиве, использующий дробление массива на половины. Используется не только в элементарном нахождении элемента в отсортированном массиве. Он встречается настолько часто, что может быть скрыт даже в задании не на кодирование. К примеру, нужно найти в логах git версию, где в приложении допущена ошибка.

2. Умение строить структуры данных. Практически во всех задачах требуется правильная инкапсуляция данных. Особенно это относится к ООП. Иногда сложность задачи даже не столько в алгоритме, сколько в построении правильной структуры или класса. Поэтому без умения создавать лаконичные и непротиворечивые структуры данных никуда.

3. Рекурсия. Несмотря на то, что рекурсия – тема множества мемов и шуточек про программистов, в реальности она встречается довольно редко (а в таких мемах – почти никогда). Есть хорошее выражение: «Существует несколько задач, которые красиво и эффективно решаются рекурсией. Есть множество задач, которые красиво, но неэффективно решаются рекурсией. Подавляющее большинство задач решать рекурсией и некрасиво, и неэффективно». Тем не менее, знать принципы рекурсивного решения очень полезно. Пример: решение судоку.

4. Основы сортировки. Это не значит, что вам нужно заучить алгоритмы сортировки слиянием или быстрой сортировки. Но важно понимать общие принципы работы, почему сортировка слиянием быстрее сортировки пузырьком, время работы в O-нотации, уметь использовать факт, что коллекция уже отсортирована и т.п.

5. Разворачивание связанного списка. Вариантами задачи могут быть нахождение дубликатов в списке или определение, является ли связанный список зацикленным. Кроме того, важно правильно создать структуру элемента списка (данные и указатель).

6. Манипулирование несколькими переменными/указателями одновременно. Канонический пример: разворот строки, определение, является ли строка палиндромом, нахождение самого длинного палиндрома в тексте, - движение указателей в обе стороны, либо с разной скоростью.

7. Использование Хеш-таблиц (или множеств). Здесь вариантами могут быть задачи на оптимальное нахождение парного числа в массиве, задачи на обход графа с сохранением пути, мемоизация в рекурсии и т.п.

8. Нахождение закрывающей скобки. Вариантами могут быть проверка, все ли скобки закрыты в строке, либо нахождение, сколько скобок нужно добавить. Кандидат для использования стека. Добавляем открывающие скобки в стек, при нахождении закрывающей скобки – удаляем элемент из стека.

9. Поиск в глубину (Depth-first search) — один из методов обхода графа, который состоит в том, чтобы идти «вглубь» графа, насколько это возможно. Можно реализовать с помощью стека и рекурсии. Для заданной вершины добавляем всех её потомков в стек, далее извлекаем первый элемент стека и повторяем процедуру для него рекурсивно.

10. Поиск в ширину (Breadth-first search) — обход всех ребер для «открытия» всех вершин, достижимых из заданной вершины. Можно реализовать с помощью очереди. Для заданной вершины добавляем всех её потомков в очередь. Далее, проходя по очереди добавляем всех потомков каждого элемента в конец очереди.

Источники:
- https://www.youtube.com/watch?v=r1MXwyiGi_U
- https://youtu.be/zHczhZn-z30

День пятьсот шестьдесят седьмой. #ЧтоНовенького #CSharp9
Первичные Конструкторы в C#9
В C#9 представлен новый упрощённый способ создания классов. Большинство конструкторов очень избыточны, поскольку аргументы конструктора чаще всего используются только для инициализации свойств с тем же именем. Теперь есть способ избавиться от этого лишнего кода. Сейчас мы пишем что-то вроде этого:

public class Person {
  public Person(string firstName, string lastName) {
     this.FirstName = firstName;
     this.LastName = lastName;
  }
  public string FirstName { get; }
  public string LastName { get; }
}

8 строк кода (11, если переносить открывающую скобку на новую строку), только чтобы создать простой POCO (Plain Old CLR Object). Теперь это можно сделать в одну строку:

public record Person(string firstName, string lastName);

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

Инициализаторы
Первичные конструкторы также используют новые init-свойства. Это означает, что мы можем установить значение свойства с помощью инициализатора объекта:

var p = new Person("Miguel", "Bernard") { lastName = "test" };

Это работает, как и ожидалось. После выполнения конструктора значение "Bernard" заменяется на "test". Однако вы не можете использовать инициализатор объекта для задания обязательных свойств первичного конструктора:

// Это не скомпилируется
var p = new Person("Miguel") { lastName = "test" };

Значения по умолчанию
В первичный конструктор можно передавать значения по умолчанию:

public record Person (string firstName, string lastName = "lastName");
var p = new Person("Miguel");

Я вижу большой потенциал в этой новой функции, особенно для POCO/DTO и простых объектов. Удаление всего этого бесполезного шаблонного кода сократит издержки при создании новых типов и упростит кодовую базу.

Источник: https://blog.miguelbernard.com/c-9-0-primary-constructors/

День пятьсот шестьдесят восьмой. #ЧтоНовенького #CSharp9
Подробнее про Записи в C#9
Записи в C#9 помогут нам создавать неизменяемые типы, которые очень полезны в большой распределенной архитектуре. Поскольку запись ведет себя иначе, чем класс или структура, Microsoft ввели новое ключевое слово record.

public record Chicken { public string Name {get;init;} }
var c = new Chicken { Name = "test" };
// c.Name = "t"; - изменение значения недопустимо

Первичные конструкторы
Ещё интереснее использование записей с первичными конструкторами:

public record Chicken(string name);

Фактически есть большой соблазн использовать только первичные конструкторы для объявления записей, чтобы отличать их от объявления классов.

With
С введением записей добавится ещё одно ключевое слово with, которое позволит «клонировать» запись, изменив только некоторые свойства.

var c2 = c with { Name = "myNewName" };

Структурное равенство
Записи обладают структурным равенством, то есть две записи считаются равными, если все их свойства равны. Такое поведение сложно реализовать с помощью классических классов, поскольку нужно переопределить методы Equals и GetHashCode и обновлять код этих методов при изменении свойств.

Деконструкция
Записи также поддерживают деконструкцию, что позволяет неявно преобразовать запись в кортеж, содержащий все свойства:

public record Decons(int qty, string name, DateTime time);
var r = new Decons(42, "name", DateTime.Now);
var(x, y, z) = r;

Того же результата можно достичь с помощью метода Deconstruct(), доступного для всех типов записей.

Наследование
Поскольку C# - объектно-ориентированный язык, наследование является частью ООП, и его следует поддерживать. Должно быть, это самая серьёзная проблема, которую пришлось преодолеть команде C#, - сделать записи частью языка, сохранив при этом обратную совместимость.

public abstract record Food (int Cal);
public record Milk(int C, double Fat) : Food(C);
var m = new Milk(1, 3.25);

При этом можно обратиться как к m.C, так и к m.Cal (они будут равны 1). Но что, если объявить свойства одинаково?

public record Milk(int Cal, double Fat) : Food(Cal);

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

public interface IRecord { }
public record RecordType : IRecord { }

Ограничения обобщений
На момент написания невозможно использовать ключевое слово record для ограничения обобщения:

public void Method<T>(T t) where T : record

Надеюсь, к моменту выхода 9й версии это будет поддерживаться.

Источник: https://blog.miguelbernard.com/c-9-0-records/

День пятьсот шестьдесят девятый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
56. Делайте Невидимое Видимым
Многие аспекты невидимости справедливо относят к важным принципам разработки программного обеспечения, которых необходимо придерживаться. Наша терминология богата метафорами невидимости: ссылочная прозрачность или сокрытие информации – лишь пара примеров. ПО и процесс его разработки могут быть по большей части невидимы:

- Исходный код не имеет физической сущности, поведения и не подчиняется законам физики. Он виден, когда вы загружаете его в редактор, но закройте редактор, и он исчезнет. Как дерево, которое падает, но этого никто не слышит, можно начать сомневаться, а существует ли оно вообще.

- Работающее приложение имеет сущность и поведение, но не раскрывает ничего о своём исходном коде. Домашняя страница Google приятно минималистична, но её функционал, несомненно, огромен.

- Если вы сделали 90% задачи, но застряли, пытаясь отладить последние 10%, то нельзя сказать, что продукт готов на 90%. Исправление ошибок не считается прогрессом. Вам не платят за отладку. Отладка - пустая трата времени. Хорошо бы сделать эти потери более заметными, чтобы вы могли сразу видеть, куда тратятся ресурсы, и думать о том, как этого не допускать.

- Если ваш проект всё время продвигался по плану, а через неделю уже опаздывает на шесть месяцев, у вас проблемы. И самая большая проблема даже не в том, что проект опаздывает на шесть месяцев, а том, что вы не заметили причины задержки до самого последнего момента! Отсутствие видимого прогресса является синонимом отсутствия прогресса.

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

- Написание модульных тестов свидетельствует о том, насколько легко блок кода поддаётся тестированию. Это помогает выявить наличие (или отсутствие) качеств, которые вы хотели бы иметь в коде, таких как низкая связанность и высокая связность.

- Выполнение модульных тестов свидетельствует о поведении кода. Это помогает выявить наличие (или отсутствие) качеств времени выполнения, которые вы хотели бы иметь в приложении, таких как надёжность и корректность.

- Использование общедоступного баг трекера делает прогресс видимым и конкретным. Задачи могут отображаться как «Не начата», «Выполняется» или «Выполнена», вне зависимости от наличия скрытого инструмента управления проектом и без необходимости преследовать программистов за недостоверные отчёты о выполненной работе.

- Инкрементальная разработка улучшает видимость прогресса (или его отсутствия) за счёт увеличения частоты релизов (свидетельств прогресса). Завершение и выпуск ПО показывает реальную картину, оценка прогресса - нет.

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

Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Jon Jagger.

День пятьсот семидесятый. #TipsAndTricks
Повышаем продуктивность в Visual Studio.
31. Отслеживать или не Отслеживать Текущий Документ в Проводнике Решения
Может быть очень полезно переключаться на текущий файл в проводнике решения (Tools -> Options -> Projects and Solutions -> General -> Track Active Item in Solution Explorer). Последнее, что хочется делать, - это вручную искать его в дереве элементов вашего решения.
Проблема в том, что после работы с кучей файлов дерево проводника решения превращается в бардак. Всё развернуто и ничего не найти. Вместо автоматического отслеживания есть горячие клавиши для перехода к этому элементу.

Горячие клавиши по умолчанию - Ctrl+[,S. Я стараюсь оставлять значения по умолчанию. Не самая простая для запоминания комбинация, но ко всему привыкаешь. Как бы то ни было, поменять можно в Tools -> Options -> Environment -> Keyboard. Начните вводить "SyncWithActiveDocument" в поле справа.

Источник: https://michaelscodingspot.com/productivity-tips-in-visual-studio/

День пятьсот семьдесят первый. #ЗаметкиНаПолях
Деревья выражений
Деревья выражений - чрезвычайно мощная часть .NET, но они также являются одной из самых плохо понимаемых частей. По сути, они позволяют вам обернуть лямбда-выражения, такие как Func<T> или Action<T>, и проанализировать их. Лучше всего проиллюстрировать это на примере. Метод расширения Where в LINQ to Objects принимает Func<T, int, bool> в качестве основного параметра:

static IEnumerable<TSource> WhereIterator<TSource>(IEnumerable<TSource> source, Func<TSource, int, bool> predicate) {
  int index = -1;
  foreach (TSource element in source) {
    checked { index++; }
    if (predicate(element, index)) yield return element;
  }
}

Он выполняет итерацию по IEnumerable и возвращает элементы соответствующие предикату. Однако очевидно, что это не будет работать в LINQ to SQL/Entity Framework, т.к. там необходимо перевести предикат в SQL! Так что сигнатура для версии IQueryable немного другая:

static IQueryable<TSource> Where<TSource>(this IQueryable<TSource> source, Expression<Func<TSource, int, bool>> predicate) {
  return source.Provider.CreateQuery<TSource>( 
    Expression.Call(
      null,
      GetMethodInfo(Queryable.Where, source, predicate),
      new Expression[] { 
        source.Expression, Expression.Quote(predicate) 
      }
    )
  );
}

Выглядит страшно, но главное тут в том, что функция теперь принимает делегат Func<T, int, bool>, завернутый в Expression, то есть позволяет LINQ провайдеру прочитать Func, проанализировать переданный предикат и перевести его в SQL. Таким образом, Expression позволяет вам проверять ваш код во время выполнения.

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

var settings = new List<Setting>();
settings.Add(
  new Setting(
    "EnableBugs",
    Settings.EnableBugs));
settings.Add(
  new Setting(
    "EnableFluxCapacitor",
    Settings.EnableFluxCapacitor));

Здесь нетрудно увидеть опасность: название параметра в словаре представляет собой строку, и опечатка здесь может вызвать проблемы. Если мы создадим новый метод, который принимает Expression<Func<T>> (т.е. лямбда-выражение, которое что-то возвращает), мы можем получить фактическое имя переданной переменной:

private Setting GetSetting<T>(Expression<Func<T>> expr) {
  var me = expr.Body as MemberExpression;
  if (me == null)
   throw new ArgumentException("Invalid expression.");
  //переводим выражение обратно в Func
  var func = expr.Compile();
  //выполняем func, чтобы получить значение
  var value = func();
  return new Setting(me.Member.Name,value);
}

Вызов:

var settings = new List<Setting>();
settings.Add(GetSetting(() => Settings.EnableBugs));
settings.Add(GetSetting(() => Settings.EnableFluxCapacitor));

Заметьте, что нужно проверить, передано ли выражение типа MemberExpression (обращение к свойству), т.к ничто не мешает вызывающему коду передать любой другой подходящий делегат, тогда нельзя будет обратиться к .Member.Name.

Очевидно, это только малая толика того, на что способны деревья выражений.

Источник: https://chrisstclair.co.uk/6-lesser-known-features-of-c-net-that-you-should-be-using/

День пятьсот семьдесят второй. #TipsAndTricks
Повышаем продуктивность в Visual Studio.
32. Хитрости Ctrl+T
Есть много способов навигации по вашему решению. Мой любимый способ - это сочетание клавиш Ctrl+T (Edit > Go To > Go To All…). Вы можете искать всё, что хотите: файл, класс, свойство, поле или метод.

В этом окне есть несколько хитростей:
- Обычный поиск использует простую логику «содержит». Если файл/класс/член содержит текст из поля для поиска, он появится в результатах.
- Для элементов, написанных с помощью camelCase (или PascalCase), можно вводить только инициалы. Например, asdc найдёт AnotherSearchDemoComponent.
- Вы можете сузить поиск до определенных типов результатов:
f [строка] ищет только файлы
r [строка] ищет в недавних файлах
t [строка] ищет в типах
m [строка] ищет в членах
# [строка] ищет в символах

Источник: https://michaelscodingspot.com/productivity-tips-in-visual-studio/

День пятьсот семьдесят третий. #ЗаметкиНаПолях
Класс Path
Многие разработчики до сих пор выделяют расширение файла из имени вручную, когда есть встроенный класс Path, который имеет удобные методы, чтобы сделать это за вас. Класс находится в пространстве имен System.IO и содержит множество полезных методов, которые сокращают объем стандартного кода, который вам приходится писать. Многим известны такие методы, как Path.GetFileName и Path.GetExtension, которые делают именно то, что вы ожидаете (извлекают имя файла и расширение соответственно). Рассмотрим несколько менее популярных.

Path.Combine
Этот метод принимает несколько строк пути и объединяет их в один путь. Обычно это делают, чтобы добавить имя файла к каталогу:

directoryPath + "\" + filename

Проблема в том, что вы предполагаете, что разделителем каталогов в системе, в которой работает ваше приложение, является обратный слеш. Но в Unix используется прямой слеш. Это становится серьезной проблемой, поскольку .NET Core позволяет запускать приложения на большом количестве платформ. Path.Combine будет использовать разделитель каталогов, используемый в операционной системе, а также разберётся с избыточными разделителями (удалит дублирующие).

Path.GetTempFileName
Довольно часто бывает необходимо создать временный файл. Вам не важно имя или место хранения, вам просто нужно записать что-то в файл и через некоторое время прочитать оттуда. Можно написать этот код самостоятельно, но это будет утомительно и подвержено ошибкам. Path.GetTempFileName не принимает никаких параметров, он создаёт пустой файл во временном каталоге пользователя, и возвращает вам полный его путь. Поскольку файл находится во временном каталоге пользователя, Windows автоматически удалит его при необходимости, и вам не придётся беспокоиться о засорении системы избыточными файлами.

Path.GetInvalidPathChars / Path.GetInvalidFileNameChars
Path.GetInvalidPathChars и его собрат Path.GetInvalidFileNameChars возвращают массив всех символов, которые недопустимы для пути / имени файла в текущей системе. Я видел много кода, который вручную удаляет некоторые наиболее распространённые недопустимые символы, например, кавычки, но не удаляет другие недопустимые символы, что создаёт бомбу замедленного действия. И, если мы говорим о кросс-платформенности, неверно предполагать, что то, что недопустимо в одной системе, будет недопустимо в другой. Единственная проблема с этими методами в том, что они не позволяют проверить, содержит ли путь недопустимые символы. Из-за этого приходится писать подобные шаблонные методы:

public static bool IsValidPath(string path) {
  if (path == null)
    throw new ArgumentNullException(nameof(path));

  return path.IndexOfAny(Path.GetInvalidPathChars()) < 0;
}

Источник: https://chrisstclair.co.uk/6-lesser-known-features-of-c-net-that-you-should-be-using/

День пятьсот семьдесят пятый. #ЧтоНовенького
Новые функции Visual Studio 2019 v16.8 Preview 2
Интеграция с Git
В некоторых репозиториях содержится более одного решения. Теперь, когда вы откроете такой репозиторий, в обозревателе решений отобразится список решений, из которых вы можете выбрать. См. рис. 1 ниже. По умолчанию вверху располагается пункт «Просмотр папки» (Folder View). Он откроет корневую папку репозитория. Двойной щелчок по одному из решений в списке откроет решение. Кроме того, вы можете использовать кнопку «Переключить представления» (Switch Views) на панели инструментов проводника решений, чтобы вернуться к списку представлений и легко переключаться между решениями в репозитории. Если в вашем репозитории только одно решение, Visual Studio покажет его, а если решений нет, откроется вид просмотра папки.

Повышение продуктивности в .NET
Visual Studio продолжает перенимать крутые фишки Rider'a. На этот раз добавили встроенные подсказки имён параметров перед каждым аргументом в вызовах функций. См. рис. 2 ниже. Чтобы получить доступ к этой функции, нужно включить её в Инструменты > Параметры > Текстовый редактор > C# > Дополнительно (Tools > Options > Text Editor > C# > Advanced) и выбрать «Показывать встроенные подсказки имён параметров» (Display inline parameter name hints).

Кроме того, теперь вы можете извлекать члены из выбранного класса в новый базовый класс с помощью нового вида рефакторинга «Выделить Базовый Класс» (Extract Base Class). Чтобы попробовать это, поместите курсор либо на имя класса, либо на выделенный член. Нажмите Ctrl+., чтобы вызвать меню быстрых действий и рефакторинга. Оттуда выберите «Выделить член(ы) в новый базовый класс» (Pull member(s) up to new base class). Откроется новое диалоговое окно «Выделить Базовый Класс», в котором вы можете указать имя базового класса, место его размещения, выбрать элементы, которые хотите передать в новый базовый класс, и сделать их абстрактными, установив флажок в столбце «Сделать абстрактным» (Make abstract). См. рис. 3 ниже.

Еще одна функция рефакторинга - преобразование typeof в nameof. Использование nameof вместо имени типа позволяет избежать использования рефлексии для извлечения объекта. Поместите курсор на выражение typeof(<QualifiedType>).Name, нажмите Ctrl+. и выберите «Преобразовать 'typeof' в 'nameof'» (Convert 'typeof' to 'nameof'). См. рис. 4 ниже.

Источник: https://devblogs.microsoft.com/visualstudio/visual-studio-2019-v16-8-preview-2/

День пятьсот семьдесят шестой. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
57. Послание в Будущее
В течение многих лет я преподавала и работала бок о бок с программистами. И, возможно, поскольку большинство из них были умными людьми, мне всегда казалось, что они думали так: «Так как проблемы, с которыми они сталкивались, были трудными, то и решения должны быть так же сложны для понимания остальными (возможно, даже для самих себя через несколько месяцев после написания кода).»

Я помню один случай с Джо, студентом моего курса структур данных, который должен был зайти и показать мне, что он написал:
– Спорим, не сможете догадаться, что делает код! – с порога заявил он.
– Ты прав, – согласилась я, не тратя времени на разбор его кода, а думая, как донести до него важную мысль. – Я уверена, что ты много над этим работал. Но мне интересно, не забыл ли ты кое-что важное. Скажи-ка, Джо, у тебя ведь есть младший брат?
– Да, конечно! Фил. Он учится на вашем вводном курсе. Тоже учится программировать! – гордо ответил Джо.
– Замечательно, - сказала я. – Интересно, сможет ли он понять этот код.
– Ни за что! – сказал Джо. – Это сложно!
– А теперь представь себе, – предложила я, – что это настоящий рабочий код, и что через несколько лет Фил устроится на работу и получит задание его изменить. Что ты для него сделал?

Джо просто уставился на меня и моргал.

– Мы знаем, что Фил очень умный, верно? – Джо кивнул. – И я очень не люблю это говорить, но я тоже довольно умная! – Джо усмехнулся. – Так что, если я не могу быстро понять, что ты здесь сделал, то и твой очень умный младший брат, вероятно, будет ломать голову над этим.

Мне показалось, что Джо несколько иначе стал смотреть на свой код.

– Давай поступим так, – предложила я максимально дружелюбно. - Думай о каждой строке кода, которую ты пишешь, как о послании для кого-то в будущем. Кого-то, кто может оказаться твоим младшим братом. Представь, что ты объясняешь этому умному человеку, как решить эту трудную задачу.
Как ты себе это представляешь? Наверняка, что умный программист в будущем увидит твой код и скажет: «Вау! Это круто! Я прекрасно понимаю, что здесь происходит, и меня поражает, какой это элегантный и красивый фрагмент кода. Я хочу показать остальным в моей команде. Это шедевр!»
Джо, как ты думаешь, сможешь ли ты написать код, который решает эту сложную проблему, но будет настолько красив, что будет петь? Да, как навязчивая мелодия. Я думаю, что любой, кто может придумать очень сложное решение, как, например, твоё, также мог бы написать что-нибудь красивое. Хм… А может мне стоит ставить оценки за красоту? Что скажешь?

Джо взял свою работу и посмотрел на меня с легкой улыбкой:
– Я понял, профессор, я собираюсь сделать мир лучше для Фила. Спасибо.

Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Linda Rising.

День пятьсот семьдесят седьмой. #Оффтоп #ЗадачиНаСобеседовании
В пандан ко вчерашнему посту про простоту и понятность решений, сегодня задачка на выходные.

Прямоугольная любовь
Команда учёных-любителей создала новый сайт знакомств. Отличительной особенностью его является инновационный способ представления профилей людей в виде прямоугольников на плоскости. Чем больше пересечение прямоугольников, тем больше у них шансов на успешные отношения.
Команде нужна помощь в написании алгоритма, находящего пересечение прямоугольников. Как показано на картинке ниже, стороны прямоугольников параллельны осям x и y.

Метод должен получать на вход 2 объекта класса Rectangle, имеющего свойства:
- координаты левой нижней точки
- длина
- ширина
На выходе должен получаться такой же объект Rectangle, представляющий собой пересечение.

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

Как обычно, приглашаю всех предлагать варианты решения в чате.

День пятьсот семьдесят восьмой. #Оффтоп
Чтобы скрасить последнее воскресенье лета, предлагаю вам небольшой ютубовский плейлист (он в настоящее время пополняется) о производительности LINQ. Немного… хотя нет, много байтодрочерства и микрооптимизаций, но всё равно довольно интересное объяснение внутреннего устройства популярного механизма C#, а также советы, чего следует избегать и как в отдельных случаях можно повысить его производительность, переопределив стандартные методы.

К сожалению, видео на английском, а автор поляк, поэтому качество английского (да и его речи вообще) оставляет желать лучшего. Но, несмотря на это, если вам интересны милли- и наносекунды, бенчмарк и вотэтовсё, наслаждайтесь.

C# LINQ Performance

День пятьсот семьдесят девятый. #Оффтоп #ЗадачиНаСобеседовании
Ответ на субботнюю задачу

Задача не очень сложная, главное грамотно разбить её на части.
Мы можем рассматривать «горизонтальное» пересечение прямоугольников (по оси x) отдельно от пересечения «по вертикали» (по оси y). Например, мы рассмотрим ширину прямоугольников как отрезки на одномерной числовой прямой x. Какие возможные случаи расположения этих отрезков?
1) Пересекаются частично
2) Один отрезок полностью содержится в другом
3) Не пересекаются
4) "Касаются" в одной точке
См. рисунок ниже.

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

static Segment Overlap(Segment s1, Segment s2)
{
  // начальная точка (максимальная из начальных)
  double start = Math.Max(s1.StartPoint, s2.StartPoint);
  // конечная точка (минимальная из конечных)
  double end = Math.Min(s1.StartPoint + s1.Length, s2.StartPoint + s2.Length);

  // отрезки не пересекаются
  if (start > end)
    return null;

  return new Segment(start, end - start);
}

В результате мы найдём отрезки пересечения по оси x и по оси y. Всё, что нам остаётся сделать – это совместить их. Начальные точки отрезков будут координатами левой нижней точки прямоугольника пересечения, длина отрезка по оси x будет шириной, а длина отрезка по оси y – высотой.

Замечание: в зависимости от условий задачи надо рассмотреть, допустимы ли варианты нулевых ширины и высоты (когда прямоугольники касаются сторонами, либо касаются в одной точке).

public static Rectangle RectangularOverlap(Rectangle r1, Rectangle r2)
{
  // пересечение по оси x
  Segment xOverlap = Overlap(
    new Segment(r1.StartPoint.X, r1.Width),
    new Segment(r2.StartPoint.X, r2.Width));
  // пересечение по оси у
  Segment yOverlap = Overlap(
    new Segment(r1.StartPoint.Y, r1.Height),
    new Segment(r2.StartPoint.Y, r2.Height));

  if (xOverlap?.Length >= 0 && yOverlap?.Length >= 0)
    return new Rectangle(
        new Point(xOverlap.StartPoint, yOverlap.StartPoint),
          xOverlap.Length,
          yOverlap.Length
        );

  // не пересекаются
  return null;
}

PS: я в коде использовал новый тип записи. Вот весь код объявления:

public record Point(double X, double Y);
public record Segment(double StartPoint, double Length);
public record Rectangle(Point StartPoint, double Width, double Height);

Можно использовать класс или структуру, но их описание со свойствами и конструкторами гораздо длиннее)))
PPS: да, в коде не хватает валидации исходных данных.
PPPS: строго говоря, решение можно слегка оптимизировать, не проверяя пересечение по y, если нет пересечения по x.

Источник: https://www.interviewcake.com/question/csharp/rectangular-love