В какой точке / диапазоне файл кода слишком велик?

Я нахожу много файлов по 2-3 тыс. Строк, и на самом деле не кажется, что они должны быть такими большими.

Что является хорошим критерием, чтобы объективно называть файл исходного кода «слишком большим»? Существует ли такая вещь, как максимальное количество строк, которое должен иметь файл исходного кода?

В качестве идеальной модели я использую следующие критерии (с обоснованием, аналогичным предложенному Мартином Беккетом, т. Е. Думать с точки зрения логической структуры, а не с точки зрения строк кода):

Правило 1

Один класс на файл (в C ++: один класс -> один заголовок и один файл реализации).

Правило 2

Семь считается количеством предметов, которые наш мозг может наблюдать одновременно, не запутавшись. Выше 7 нам трудно следить за тем, что мы видим. Следовательно: в каждом классе не должно быть более 7-10 методов. Класс, имеющий более 10 методов, вероятно, слишком сложен, и вы должны попытаться разделить его. Разделение - очень эффективный метод, потому что каждый раз, когда вы разделяете класс, вы уменьшаете сложность каждого отдельного класса, по крайней мере, в 2 раза.

Правило 3

Тело метода, которое не помещается на одном или двух экранах, слишком велико (я предполагаю, что окно экрана / редактора занимает около 50 строк). В идеале вы можете увидеть весь метод в одном окне. Если это не так, вам нужно лишь немного прокрутить вверх и вниз, не забывая о скрытой части метода. Итак, если вам нужно прокрутить несколько экранов вверх или вниз, чтобы прочитать все тело метода, ваш метод, вероятно, слишком велик, и вы можете легко потерять обзор.

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

Составляя эти очень приблизительные оценки:

• Максимум один класс на исходный файл.
• Максимум 10 публичных методов в классе.
• Максимум 10 частных методов в классе.
• Максимум 100 строк на метод.

Таким образом, исходный файл, который содержит более 2000 строк, вероятно, слишком велик и начинает слишком грязно.

Это действительно очень грубая оценка, и я не следую этим критериям систематически (особенно потому, что не всегда достаточно времени для правильного рефакторинга). Кроме того, как предположил Мартин Беккет, существуют ситуации, в которых класс представляет собой большой набор методов, и нет смысла разбивать их каким-либо искусственным образом, просто чтобы сделать класс меньше.

В любом случае, по моему опыту, файл начинает становиться нечитаемым, когда один из вышеперечисленных параметров не соблюдается (например, тело метода с 300 строками, охватывающее шесть экранов, или исходный файл с 5000 строками кода).

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

Если бы у вас был класс, который на законных основаниях имел несколько сотен методов (не исключено, скажем, 3D-моделирование), было бы гораздо менее удобно разбить его на произвольные файлы. Раньше мы делали это, когда память была меньше, а процессоры - медленнее - и это было мучительно, мы постоянно искали определение функции.

Когда код в нем становится неуправляемым. То есть: вы не можете просто наблюдать за кодом, есть ли метод / класс / функция, которую вы ищете (и должны редактировать / отлаживать), там или нет, и если да, то где он находится.

Однако выбор и функции IDE / Editor будут влиять на фактическую количественную оценку этого верхнего предела. Свертывание кода , листинг функции / метода и поиск отложат момент, когда появится этот сценарий разработки.

Но когда это произойдет, пришло время разделить это.

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

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

Большая опасность заключается в наличии кода копирования-вставки. Кодирование с копированием-вставкой, естественно, также ускоряет рост LOC. Я думаю, что исключить копирование-вставку еще важнее, чем держать LOC ниже некоторого магического числа. В дополнение к чистому копированию и вставке, в больших файлах есть и другая опасность: перекрывающаяся функциональность. Чем больше размер файла, тем больше вероятность, что вы переопределите какой-то фрагмент, который уже находится в каком-то другом разделе того же файла.

Таким образом, до тех пор, пока коэффициент исправления ошибок (отношение фиксаций исправлений ошибок ко всем коммитам) низок для больших файлов, ситуация терпима. Пожалуйста, попробуйте git logи просмотрите, сколько коммитов связано с ошибками. Или используйте инструмент, который может автоматически анализировать и визуализировать его, например, Softagram .

Учти это Metaphor. Когда дело доходит до длины кода, я думаю, что мы должны учитывать следующее:

The Cat in The Hat (50 pp.)

а также

Lord of The Rings (1,178 pp.)

В этом нет ничего плохого Lord of the Rings. Это невероятная книга. The Cat in the Hatтоже отличная книга. Оба могут быть понятны 5-летним детям, но только один лучше подходит по содержанию.

На мой взгляд, написание кода должно иметь смысл для пятилетнего ребенка, когда мы можем. Cyclomatic Complexityявляется важной концепцией, которую разработчики могут учитывать при создании кода. Использование и создание библиотек для максимально возможного расширения функциональности и возможности повторного использования кода. Таким образом, наш код может говорить больше, чем то, что мы видим написанным.

Большинство из нас не пишут ассемблерный код . Но корень нашего кода - это сборка. Поиск по 10000 строкам строк сложнее, чем 10000 строк Python, если все сделано правильно.

Но некоторые работы требуют написания от 500 до 1000 строк. Наша цель с кодом должна состоять в том, чтобы написать 300 строк чистого кода.

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

Разработчики не хотят документировать код (лично мне нравится документированный код, я не настолько эгоистичен). Так что не пишите код, который только вы можете понять / прочитать. Написать Cat in the Hatкод.

Мы все знаем, что вы Дж.Р.Р. Толкен (в вашей голове). Помните, что вам нечего доказывать с помощью кода без ошибок.

Еще одна причина метафоры.

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

Все любят перебазировать.

-> Никто никогда не говорил!

TL; DR Фокус на удобочитаемости. Распределите ваш код и помощник по нескольким строкам и файлам как можно больше. Не бросайте 8 или 9 классов в один файл, это затрудняет чтение и поддержание кода. Если у вас большой код условия или цикл, попробуйте заменить их на Lambdas, если язык поддерживает это. Функции утилит следует рассматривать как отличный способ улучшить читаемость кода. Избегайте тяжелого вложения.