C# (C Sharp) programming

#ПятничныйКвиз

#ПятничныйКвиз #ДляСамыхМаленьких

💡 C#: заставьте архитектуру ломать CI, если кто-то нарушил правила

Компилятор C# отлично проверяет типы, но ему всё равно, что Application внезапно начал зависеть от Infrastructure.

Code Review тоже не гарантирует, что такое заметят.

Для этого можно использовать Architecture Tests — тесты, которые проверяют не бизнес-логику, а структуру проекта.

Например, через NetArchTest.Rules:


[Fact]
public void Application_Should_Not_Depend_On_Infrastructure()
{
var result = Types
.InAssembly(ApplicationAssembly)
.ShouldNot()
.HaveDependencyOn("MyApp.Infrastructure")
.GetResult();

Assert.True(result.IsSuccessful);
}


Теперь случайный:


Application → Infrastructure


сломает CI так же, как обычный упавший unit-тест.

Можно зафиксировать и naming convention:


[Fact]
public void Handlers_Should_End_With_Handler()
{
var result = Types
.InAssembly(ApplicationAssembly)
.That()
.ImplementInterface(typeof(ICommandHandler))
.Should()
.HaveNameEndingWith("Handler")
.GetResult();

Assert.True(result.IsSuccessful);
}


Или заставить сервисы быть sealed:


Types
.InAssembly(ApplicationAssembly)
.That()
.HaveNameEndingWith("Service")
.Should()
.BeSealed();


Особенно полезно это становится в больших Clean Architecture / DDD / Modular Monolith проектах.

Вместо документа:


❌ «Application не должен зависеть от Infrastructure»


получаем исполняемое правило:


✅ нарушил архитектуру → тест упал → PR не прошёл


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

#CSharp #DotNet #Architecture #Testing

#ПятничныйКвиз

C#-приём: точное сложение `double` через алгоритм Кэхэна

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

Обычный вариант:


double sum = 0;

foreach (double value in values)
{
sum += value;
}


Более точный вариант:


public static double KahanSum(ReadOnlySpan values)
{
double sum = 0;
double compensation = 0;

foreach (double value in values)
{
double adjusted = value - compensation;
double next = sum + adjusted;

compensation = (next - sum) - adjusted;
sum = next;
}

return sum;
}


Переменная compensation сохраняет часть числа, потерянную при округлении, и возвращает её в следующее сложение.

Использование:


double[] values = { 0.1, 0.2, 0.3, 0.4 };

double result = KahanSum(values);


Метод полезен для:

- научных расчётов;
- статистики и аналитики;
- обработки сигналов;
- симуляций;
- накопления миллионов небольших значений.

ReadOnlySpan позволяет передавать массивы и участки памяти без дополнительных копирований.

Алгоритм требует нескольких дополнительных операций на каждом шаге, зато заметно уменьшает накопленную погрешность.

Для денежных расчётов по-прежнему лучше использовать decimal. А когда нужна скорость double и повышенная численная устойчивость – пригодится Kahan Summation.

#ПятничныйКвиз

Clean Code: сложный `if` лучше превратить в понятное правило

Такой код приходится расшифровывать каждый раз:


if (invoice is not null &&
invoice.Status == InvoiceStatus.Unpaid &&
invoice.DueDateUtc < DateTime.UtcNow &&
invoice.Balance > 0 &&
!invoice.SilenceWarnings &&
invoice.Customer.Email is not null)
{
SendOverdueWarning(invoice);
}


Условие растёт, бизнес-правило теряется среди технических деталей, а изменение одного требования превращается в рискованный рефакторинг.

Вынесем правило в метод с говорящим именем:


if (invoice.ShouldSendOverdueWarning(nowUtc))
{
SendOverdueWarning(invoice);
}


Само правило:


public bool ShouldSendOverdueWarning(DateTime nowUtc)
{
return Status == InvoiceStatus.Unpaid
&& DueDateUtc < nowUtc
&& Balance > 0
&& !SilenceWarnings
&& Customer.Email is not null;
}


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

### Почему исходный вариант плохо тестируется

Он напрямую использует DateTime.UtcNow. Результат зависит от реального времени, поэтому тест может вести себя по-разному в разные моменты.

После передачи времени параметром тест становится предсказуемым:


[Fact]
public void Sends_warning_for_overdue_unpaid_invoice()
{
var invoice = new Invoice
{
Status = InvoiceStatus.Unpaid,
DueDateUtc = new DateTime(2026, 7, 20),
Balance = 1500,
SilenceWarnings = false,
Customer = new Customer { Email = "user@example.com" }
};

var nowUtc = new DateTime(2026, 7, 28);

Assert.True(invoice.ShouldSendOverdueWarning(nowUtc));
}


Для больших проектов вместо DateTime можно внедрить TimeProvider. Главное правило: время, сеть, файловая система и случайность не должны быть скрыты внутри бизнес-логики.