Имеет ли когда-нибудь смысл для рефактора получить более высокий LOC? [закрыто]

Существуют ли случаи, когда более подробный код (как в более логичных выражениях) является более чистым, чем более сжатый код?

Чтобы ответить на этот вопрос, давайте рассмотрим пример из реальной жизни, который произошел со мной. В C # библиотеке, которую я поддерживаю, у меня был следующий код:

TResult IConsFuncMatcher<T, TResult>.Result() =>
    TryCons(_enumerator) is var simpleMatchData && !simpleMatchData.head.HasValue
        ? _emptyValue.supplied
            ? _emptyValue.value
            : throw new NoMatchException("No empty clause supplied");
        : _recursiveConsTests.Any() 
            ? CalculateRecursiveResult() 
            : CalculateSimpleResult(simpleMatchData);

Обсуждая это с коллегами, единодушным вердиктом было то, что вложенные троичные выражения в сочетании с «умным» использованием is varпривели к краткому, но трудному для чтения коду.

Так что я рефакторинг это:

TResult IConsFuncMatcher<T, TResult>.Result()
{
    var simpleMatchData = TryCons(_enumerator);

    if (!simpleMatchData.head.HasValue)
    {
        return _emptyValue.supplied
            ? _emptyValue.value
            : throw new NoMatchException("No empty clause supplied");
    }

    return _recursiveConsTests.Any() 
        ? CalculateRecursiveResult() 
        : CalculateSimpleResult(simpleMatchData);
}

Оригинальная версия содержала только одно составное выражение с неявным return. Новая версия теперь содержит явное объявление переменной, ifоператор и два явных returns. Он содержит больше операторов и больше строк кода. Тем не менее все, с кем я консультировался, считали, что легче читать и рассуждать, что является ключевыми аспектами «чистого кода».

Таким образом, ответ на ваш вопрос - решительное «да», более подробный может быть чище, чем сжатый код, и, следовательно, является действительным рефакторингом.

1. Отсутствие корреляции между LOC и качеством кода.

Целью рефакторинга является улучшение качества фрагмента кода.

LOC - это очень базовая метрика, которая иногда коррелирует с качеством фрагмента кода: например, метод с несколькими тысячами LOC может иметь проблемы с качеством. Следует отметить, однако, что LOC не является единственным показателем, и во многих случаях отсутствует корреляция с качеством. Например, метод 4 LOC не обязательно является более читабельным или более поддерживаемым, чем метод 6 LOC.

2. Некоторые методы рефакторинга состоят из добавления LOC.

Если вы возьмете список методов рефакторинга , вы легко сможете найти те, которые заключаются в намеренном добавлении LOC. Примеры:

• Замените магическое число символической константой .
• Извлечь переменную .

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

Избегайте использования LOC.

LOC - опасный показатель. Его очень легко измерить и очень трудно правильно интерпретировать.

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

Если вы хотите увидеть конечный результат, сводя к минимуму количество байтов или количество LoC в вашем исходном коде, посмотрите на материалы, представленные на сайте Stack Exchange Code Golf .

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

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

Да, рефакторинг определенно может привести к большему количеству строк кода.

Наиболее распространенный случай IMO - когда вы берете код, который не является универсальным, и вы делаете его более универсальным / гибким . Обобщение кода легко приводит к значительному увеличению строк кода (иногда в два или более раз).

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

Например, вот очень распространенный сценарий, который происходит для каждого разработчика программного обеспечения:

• Вашему продукту необходима срочная новая высокоприоритетная новая функция, исправление или исправление ошибки в течение двух недель (или любой другой период времени, который считается срочным для вашего размера проекта / размера компании / и т.д.)
• Вы усердно работаете и доставляете XYZ вовремя, и это работает. Поздравляем! Отличная работа!
• Пока вы разрабатывали XYZ, существующий дизайн / реализация кода на самом деле не поддерживала XYZ, но вы смогли внедрить XYZ в базу кода.
• проблема в том, что шимон уродлив и имеет ужасный запах кода, потому что вы сделали некоторые хитрые / умные / уродливые / плохие практики, но вроде как работают
• когда вы найдете время спустя, вы реорганизуете код, который может изменить многие классы, или добавить новый слой классов, и ваше новое решение «сделано правильно» и больше не имеет неприятного запаха кода ... однако, делая это, «правильный путь» теперь занимает гораздо больше строк кода.

Некоторые конкретные примеры, которые приходят ко мне из головы:

• для интерфейса командной строки у вас может быть 5000 строк кода if / else-if или вы можете использовать обратные вызовы ... каждый обратный вызов будет намного меньше и проще для чтения / тестирования / проверки / отладки / и т. д., но если вы посчитаете строки закодировать уродливые 5000 строк кода if / else-if, вероятно, будет меньше
• для обработки кода, который поддерживает N методов обработки , вы могли бы снова использовать операторы if / else, которые выглядели бы наиболее уродливо ...
  • или вы могли бы переключиться на обратные вызовы, которые были бы лучше / лучше, но обратные вызовы занимают больше строк кода (хотя все равно время компиляции)
  • или вы можете абстрагироваться дальше и создать плагины, которые можно изменить во время выполнения. Плагины хороши тем, что вам не нужно перекомпилировать основной продукт для каждого нового плагина или модификации существующего плагина. и вы можете опубликовать API, чтобы другие могли расширить продукт. НО снова плагин-подход использует больше строк кода.
• для GUI вы создаете отличный новый виджет
  • Вы или коллега замечаете, что новый виджет будет полезен для XYZ и ABC, но сейчас виджет тесно интегрирован только для работы на XYZ
  • вы реорганизуете виджет для работы с обоими, но теперь общее количество строк кода увеличивается