Dictionary<TKey, TValue> — быстрый доступ к данным по ключу
Иногда нужно хранить данные так, чтобы быстро находить значение не по индексу, а по ключу.
Например, у нас есть набор пользователей и их возрастов.
Если хранить это в массиве или списке, поиск будет менее удобным.
В C# для таких задач используется
Создадим словарь, где ключ — это имя, а значение — возраст:
Здесь:
Мы обращаемся к словарю по ключу
Вот что получится при запуске:
🔥
➡️ C# Ready | #практика
Иногда нужно хранить данные так, чтобы быстро находить значение не по индексу, а по ключу.
Например, у нас есть набор пользователей и их возрастов.
Если хранить это в массиве или списке, поиск будет менее удобным.
В C# для таких задач используется
Dictionary<TKey, TValue>:using System;
using System.Collections.Generic;
Создадим словарь, где ключ — это имя, а значение — возраст:
Dictionary<string, int> ages = new Dictionary<string, int>
{
["Анна"] = 25,
["Игорь"] = 31,
["Мария"] = 28
};
Console.WriteLine(ages["Игорь"]);
Здесь:
string — тип ключа,int — тип значения.Мы обращаемся к словарю по ключу
"Игорь" и сразу получаем его возраст.Вот что получится при запуске:
31
Dictionary удобно использовать, когда нужно быстро получать данные по имени, id, коду или любому другому ключуPlease open Telegram to view this post
VIEW IN TELEGRAM
🔥14👍5❤4
Например, CPU хорошо справляется с логикой, ветвлениями и задачами с низкой задержкой. GPU — про массовый параллелизм: подходит для обработки больших массивов данных, графики и вычислений.
На картинке — наглядное сравнение архитектуры, модели вычислений и типичных сценариев применения для каждого типа процессоров.
Сохрани, чтобы не потерять!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10🤝7❤6
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤12🔥8👍4🤝3
В этой статье:
• Подготовка базы данных PostgreSQL и настройка миграций EF Core• Проектирование моделей данных и сервисных методов обмена сообщениями• Реализация клавиатур и inline-кнопок для удобного интерфейса бота🟡 Рекомендую прочитать на Habr!
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9👍7🔥5👎1
Обрабатываем пары значений с tuple-паттернами в switch!
Часто в коде нужно принимать решение сразу по нескольким переменным. Например, по координатам точки — находится ли она в начале координат, на осях или в другой области.
Раньше такую логику реализовывали через цепочку
Такой код быстро становится громоздким и сложным для поддержки при добавлении новых условий.
Сейчас перепишем на современный
🔥 Выражение стало компактнее, логика читается лучше, а добавление новых комбинаций — проще.
➡️ C# Ready | #практика
Часто в коде нужно принимать решение сразу по нескольким переменным. Например, по координатам точки — находится ли она в начале координат, на осях или в другой области.
Раньше такую логику реализовывали через цепочку
if-ов:if (x == 0 && y == 0)
return "Начало координат";
else if (x == 0)
return "На оси Y";
else if (y == 0)
return "На оси X";
else
return "Другая точка";
Такой код быстро становится громоздким и сложным для поддержки при добавлении новых условий.
Сейчас перепишем на современный
switch с tuple-паттернами:return (x, y) switch
{
(0, 0) => "Начало координат",
(0, _) => "На оси Y",
(_, 0) => "На оси X",
_ => "Другая точка"
};
🔥 Выражение стало компактнее, логика читается лучше, а добавление новых комбинаций — проще.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤13🔥6👍3
This media is not supported in your browser
VIEW IN TELEGRAM
Здесь вы найдёте базовые руководства по синтаксису языка, работу с переменными, операциями, массивами и строками, основы ООП, алгоритмы, структуры данных, а также практические задания и готовые программы для отработки навыков.Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10❤6👍6👎1
Почему nameof() лучше, чем строка, написанная руками?
Когда имя параметра или свойства передаётся обычной строкой, код становится более хрупким.
На первый взгляд всё выглядит нормально, но у такого подхода есть слабое место: строка никак не связана с самим кодом.
Например:
Пока параметр действительно называется
Но если позже кто-то переименует его, например в
Гораздо надёжнее использовать
В этом случае имя берётся прямо из кода.
Если параметр переименуют, выражение тоже обновится при рефакторинге, и код останется корректным.
По сути, это простая привычка, которая помогает избежать мелких, но неприятных ошибок при изменениях в коде.
🔥 Маленькая деталь, а код становится надёжнее и лучше переживает рефакторинг.
➡️ C# Ready | #совет
Когда имя параметра или свойства передаётся обычной строкой, код становится более хрупким.
На первый взгляд всё выглядит нормально, но у такого подхода есть слабое место: строка никак не связана с самим кодом.
Например:
throw new ArgumentNullException("user");Пока параметр действительно называется
user, проблем нет.Но если позже кто-то переименует его, например в
currentUser, строка останется старой. В итоге код уже изменился, а текст внутри исключения — нет.Гораздо надёжнее использовать
nameof():throw new ArgumentNullException(nameof(user));
В этом случае имя берётся прямо из кода.
Если параметр переименуют, выражение тоже обновится при рефакторинге, и код останется корректным.
По сути, это простая привычка, которая помогает избежать мелких, но неприятных ошибок при изменениях в коде.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11🔥4❤3😁1
Например, регистры — это самый быстрый уровень памяти внутри CPU, кэш (L1/L2/L3) снижает latency за счёт локальности данных, RAM хранит рабочее состояние приложений, а SSD/HDD используются для персистентного хранения с существенно более высоким временем доступа.
На картинке — базовая иерархия памяти, взаимодействие CPU — cache — RAM — disk, а также упрощённая модель работы HDD и архитектура SSD.
Сохрани, чтобы не потерять!
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10❤6👍6
yield return — возвращаем значения по одному, а не всё сразу!
Иногда нужно получить последовательность данных шаг за шагом, не создавая сразу целую коллекцию в памяти.
Обычный подход — сначала собрать список, а потом вернуть его:
Такой код работает, но сначала создаётся весь список целиком.
В C# можно использовать
Теперь элементы будут выдаваться по мере перебора, а не собираться заранее в отдельную коллекцию.
Используем метод:
Вот что получится при запуске:
🔥
➡️ C# Ready | #практика
Иногда нужно получить последовательность данных шаг за шагом, не создавая сразу целую коллекцию в памяти.
Обычный подход — сначала собрать список, а потом вернуть его:
List<int> GetNumbers()
{
var numbers = new List<int>();
for (int i = 1; i <= 5; i++)
{
numbers.Add(i);
}
return numbers;
}
Такой код работает, но сначала создаётся весь список целиком.
В C# можно использовать
yield return, чтобы возвращать элементы по одному:IEnumerable<int> GetNumbers()
{
for (int i = 1; i <= 5; i++)
{
yield return i;
}
}
Теперь элементы будут выдаваться по мере перебора, а не собираться заранее в отдельную коллекцию.
Используем метод:
foreach (var number in GetNumbers())
{
Console.WriteLine(number);
}
Вот что получится при запуске:
1
2
3
4
5
yield return удобен, когда нужно лениво генерировать данные и не хранить всё сразу в памятиPlease open Telegram to view this post
VIEW IN TELEGRAM
❤13🔥8👍4
This media is not supported in your browser
VIEW IN TELEGRAM
Этот репозиторий собирает лучшие гайды, где вместо теории — реальные проекты, которые можно реализовать с нуля. Внутри есть десятки идей. В разделах по C++ и C# можно найти идеи разного уровня: работа с файлами, сетевое взаимодействие, графика, многопоточность и др. задачи.
Оставляю ссылочку: GitHub📱
Please open Telegram to view this post
VIEW IN TELEGRAM
🤝11👍6❤5🔥2
Почему string.IsNullOrWhiteSpace() лучше, чем несколько проверок подряд?
Когда нужно понять, что строка пустая или не заполнена, ручные проверки быстро делают условие шумным.
При чтении приходится разбирать детали:
Например, такой код:
работает, но читается не так просто, как мог бы.
Сразу приходится смотреть, какие именно случаи мы проверяем и не забыли ли что-то по пути.
Гораздо понятнее выглядит такой вариант:
Здесь намерение видно сразу: строка не содержит нормального значения.
Не нужно вчитываться в детали условия — метод уже говорит всё за нас.
Особенно полезно это в валидации, обработке ввода, DTO, командах и любых местах, где строка приходит извне и может оказаться пустой или состоять только из пробелов.
🔥 Маленькая замена, а условие становится заметно легче для чтения.
➡️ C# Ready | #совет
Когда нужно понять, что строка пустая или не заполнена, ручные проверки быстро делают условие шумным.
При чтении приходится разбирать детали:
null, пустая строка, сравнения, операторы ||.Например, такой код:
if (name == null || name == "")
{
return;
}
работает, но читается не так просто, как мог бы.
Сразу приходится смотреть, какие именно случаи мы проверяем и не забыли ли что-то по пути.
Гораздо понятнее выглядит такой вариант:
if (string.IsNullOrWhiteSpace(name))
{
return;
}
Здесь намерение видно сразу: строка не содержит нормального значения.
Не нужно вчитываться в детали условия — метод уже говорит всё за нас.
Особенно полезно это в валидации, обработке ввода, DTO, командах и любых местах, где строка приходит извне и может оказаться пустой или состоять только из пробелов.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤15👍8🔥3
This media is not supported in your browser
VIEW IN TELEGRAM
Здесь собраны основные конструкции языка и типовые задачи, с которыми сталкиваются разработчики. Материал ориентирован на практику, показаны частые проблемы и подходы к их решению, что делает его удобным как быстрый справочник.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12❤10👍7
Почему var иногда читается лучше, чем явный тип?
Когда тип и так очевиден из правой части выражения, его повторение слева не добавляет пользы.
Наоборот — строка становится тяжелее, и глазу приходится дважды считывать одну и ту же информацию.
Например, здесь:
код формально понятный, но перегруженный.
Тип уже явно указан в момент создания объекта, поэтому повтор слева только делает запись длиннее.
Гораздо проще читается такой вариант:
Здесь внимание уходит не на длинное имя типа, а на сам смысл переменной.
Код выглядит легче, чище и быстрее считывается.
Важно:
Если по правой части непонятно, что лежит в переменной, явный тип может быть полезнее.
🔥 То есть идея не в том, чтобы писать
➡️ C# Ready | #совет
Когда тип и так очевиден из правой части выражения, его повторение слева не добавляет пользы.
Наоборот — строка становится тяжелее, и глазу приходится дважды считывать одну и ту же информацию.
Например, здесь:
Dictionary<string, List<User>> usersByRole = new Dictionary<string, List<User>>();
код формально понятный, но перегруженный.
Тип уже явно указан в момент создания объекта, поэтому повтор слева только делает запись длиннее.
Гораздо проще читается такой вариант:
var usersByRole = new Dictionary<string, List<User>>();
Здесь внимание уходит не на длинное имя типа, а на сам смысл переменной.
Код выглядит легче, чище и быстрее считывается.
Важно:
var хорошо работает именно там, где тип очевиден сразу.Если по правой части непонятно, что лежит в переменной, явный тип может быть полезнее.
var везде, а в том, чтобы убирать лишний визуальный шум там, где он не нужен.Please open Telegram to view this post
VIEW IN TELEGRAM
❤15👍7🔥6
В этой статье:
• Базовая подготовка: dotnet new + VS Code, установка шаблонов Avalonia• Разметка интерфейса на Grid и биндинги MVVM через ReactiveUI• Стилизация: от локальных сеттеров до готовой Material-темы🟡 Рекомендую прочитать на Habr!
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5👍3🔥3
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥23🤝10❤4👍2