В помощь следующему разработчику: удобочитаемый C#

Я хотел бы поделиться несколькими советами по написанию лаконичного, удобочитаемого C#. Стоит помнить о них, если вы хотите упростить задачу для тех, кто поддерживает ваш код.

Пробелы и отступы

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

Уменьшить длину строки

Короткие строки лучше читаются.

Видишь, что я там сделал? Вы можете сделать отступы для вызовов интерфейса (например, методов расширения LINQ), чтобы их было намного легче сканировать:

var resultList = items
    .SelectMany(x => x.IntArray)
    .Select(x => x[1])
    .Distinct()
    .ToList();

Другим распространенным виновником длинных строк является троичное выражение. Я считаю полезным разбивать длинные выражения на несколько строк:

var intVar = myVal == 1
    ? Convert.ToInt32(longVariableName.GetValue())
    : new DynamicConfiguration(myVal).GetValue();

В приведенном выше случае может быть даже понятнее переписать с помощью if/ else.

По возможности используйте неявно типизированные переменные.

Использование varключевого слова уменьшает шум. В этом нет необходимости:

RatherLengthyClassName myObject = new RatherLengthyClassName();

Когда вы можете сделать это без потери ясности:

var myObject = new RatherLengthyClassName();

Исключением из этого правила является случай, когда неясно, какой тип будет у присваивания:

Animal dog = GetThing(true);

Этот надуманный пример содержит нарочито ужасное имя метода, но я уверен, что мы все видели подобный код в реальных кодовых базах…

Именованные аргументы

Я уверен, что вы также видели такой код:

var myObject1 = new ComplicatedThing(true, 3, true, false, true);

myObject2.PerformAction(Action.Update, 12, "Joe Bloggs", true);

Что представляют все эти значения параметров?

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

Используя аргументы именованного метода, мы можем сделать вещи намного яснее:

var myObject1 = new ComplicatedThing(
    loadChildren: true,
    maxDepth: 3,
    loadImages: true,
    allowUpdates: false,
    lockDeletion: true
);

myObject2.PerformAction(
    action: Action.Update,
    id: 12,
    name: "Joe Bloggs",
    subscribe: true
);

Вам не нужно указывать имя каждого параметра, поэтому вы можете опустить их там, где смысл очевиден:

myObject3.AddNewItem(itemData, redirect: true);

Комментирование: помните «ПОЧЕМУ, а не ЧТО»

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

Добавляйте комментарии, когда хотите объяснить , почему вы что-то сделали. Таким образом, сопровождающим не придется тратить время на то, чтобы понять, о чем вы думали, когда писали это.

Удалить старый код

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

Если код больше не используется, удалите его и сделайте коммит с объяснением, почему вы это сделали . Если позже вы обнаружите, что он вам все-таки нужен, извлеките его из системы контроля версий — для этого он и нужен!