Как улучшить читаемость кода через именование переменных и коллекций

Что проверяют

Знаете ли вы соглашения .NET и умеете ли объяснить, почему хорошее имя полезнее комментария. Обычно дают кусок кода с list1, tmp и data и просят переименовать, а следом спрашивают, как вы договариваетесь о стиле в команде.

Как отвечать

Сначала соглашения C#:

• PascalCase: типы, методы, свойства, события, константы, публичные члены;
• camelCase: локальные переменные и параметры;
• _camelCase: приватные поля, так пишет сама команда .NET в своих репозиториях;
• префиксы и суффиксы: интерфейсы начинаются с I (IUserRepository), асинхронные методы заканчиваются на Async;
• булевы значения: имя звучит как утверждение, isActive, hasAccess, canRetry.

Для коллекций:

• множественное число: users, activeOrders, а не userList. Тип и так виден, а после замены List<T> на IReadOnlyCollection<T> имя не начнёт врать;
• словари: имя по связи ключа и значения, usersById, priceBySku. Сразу понятно, по чему индексировать;
• элемент в цикле: foreach (var order in orders), а не foreach (var item in list). В однострочной лямбде короткое имя допустимо: users.Where(u => u.IsActive).

Общие правила: имя отражает смысл в предметной области, а не тип (customerEmail, а не str), единицы измерения видны в имени, если тип их не несёт (timeoutSeconds или сразу TimeSpan), неочевидных сокращений нет. Договорённости закрепляются правилами именования в .editorconfig, тогда IDE и dotnet format сами подсвечивают нарушения.

Где спотыкаются

Тащат венгерскую нотацию или тип в имя: strName, lstUsers, userListArray. В C# с выводом типов и подсказками IDE это только шум.

Удлиняют имена ради понятности: listOfAllActiveUsersFromDatabase. Длина должна соответствовать области видимости, и у переменной на три строки короткое имя нормально.

Называют метод GetData или Process и считают вопрос закрытым. Хорошее имя говорит, что именно метод возвращает или меняет: GetOverdueInvoices, MarkAsPaid.