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

36

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

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

dukeofgaming
источник
Ваш партнер говорит вам после просмотра кода. «Вы не можете определить это сами, потому что вы знаете больше, чем автор, а сам код не говорит. Компьютер не может сказать вам по тем же причинам, по которым он не может определить, является ли картина искусством или нет. Следовательно, вам нужен другой человек, способный о поддержке программного обеспечения - посмотреть на то, что вы написали, и высказать свое мнение ... "
Gnat
Некоторые компиляторы имели странные ограничения на размер исходного кода: максимальная длина строки или максимальное количество строк. Когда компилятор жалуется, это объективный показатель того, что код слишком велик (или пришло время обновить).
Mouviciel
2
Разделите как можно больше, но не нарушая целостности файлов. Каждый файл (или пара файлов заголовка / источника) всегда должен быть округленным целым, независимо от внутренней реализации других файлов. Если это означает, что некоторые файлы будут большими, потому что они реализуют что-то сложное, пусть будет так.
Амброз Бизжак
Обратите внимание, что сложность заключается не только в числах, но и в структуре. Например, я бы хотел заявить, что Python Zen «плоский лучше, чем вложенный»: плоский список из 100 случаев проще, чем иерархия (вы не помните все 100 случаев, но вы легко помните, что существует 100 альтернатив) , И «обычная» иерархия, где ветви имеют одинаковую структуру, чем их братья и сестры, проще, чем иерархия с нерегулярной подструктурой.
Juh_
"Это исходный код?" «Нет, это make-файл, исходный код находится в грузовиках, следующих за ним».
mckenzm

Ответы:

26

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

Правило 1

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

Правило 2

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

Правило 3

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

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

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

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

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

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

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

Джорджио
источник
1
Я бы также стремился к методам не более 10 строк ... помогает с удобочитаемостью / пониманием того, что делает метод, и снижает сложность, которая легко может возникнуть в больших методах ...
Зак Макомбер,
4
Правило 2 абсурдно, если вы будете следовать ему до конца. У вас не должно быть более 7 файлов в каталоге, поэтому вы должны держать ваши файлы большими, чтобы не запутаться между десятками или сотнями файлов в вашем проекте. Точно так же глубоко вложенная структура каталогов слишком запутана, поэтому лучше хранить несколько больших файлов в одном каталоге, чем разбрасывать все вокруг.
hasen
1
Извините, этот ответ основан на совершенно произвольных показателях. «7 пунктов» - явная ерунда, иначе вы не сможете использовать алфавит. Размер объекта должен основываться на разделении интересов, единоличной ответственности, высоком сцеплении, слабой связи и подобных принципах, а не на произвольных числах.
JacquesB
1
@JacquesB 7 пунктов обычно указывают на 7 частей несвязанной информации. Если ваш мозг может ассоциировать или группировать информацию, в реальном смысле это 1 часть информации, которая может привести к большему, если вы попытаетесь вспомнить (на самом деле «алфавит» - это символ, а не все 26 букв). Лучшим примером будет попытка запомнить 7-значный номер, который вам сообщают по телефону, без ручки и бумаги. Методы явно не являются произвольными числами, но если эти методы имеют отношение к тому, что вы кодируете, вы можете ожидать после 7, вам придется искать его, прежде чем вы сможете правильно вспомнить.
Нил
3
@Neil: Если методы в классе - это случайные несвязанные фрагменты информации, то у вас есть большие проблемы в дизайне вашего класса, чем количество методов.
JacquesB
33

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

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

Мартин Беккет
источник
2
Разве класс с сотнями методов не будет признаком зависти класса, отсутствия сплоченности, плохого замысла, нарушения принципа единой ответственности и т. Д.?
Тулаинс Кордова
2
@ user1598390: обычно, но не всегда.
whatsisname
4
@ user1598390 - в распространенном, скажем, gis / 3d моделировании много операций, которые вы можете выполнять, а затем перегружать их для сигналов 2d, 3d, 4d, 3d +, затем float / double / integer и т. д. - шаблоны помогают немного, но для эффективности много операций часто лучше, чем симпатичная классная иерархия
Мартин Беккет
2
@ tp1 - а вы используете маленький шрифт, чтобы они не занимали столько места?
Мартин Беккет
2
@ tp1 Чувак, извини, я действительно не имею в виду неуважение, но мне жаль тех, кто работает с тобой. Если у вас 1200 классов, используйте соглашение о каталогах, если у вас слишком много каталогов, разделите их на независимые модули / библиотеки.
Dukeofgaming
8

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

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

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

Zjr
источник
2

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

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

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

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

Вилле Лайтила
источник
-1

Учти это 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, если язык поддерживает это. Функции утилит следует рассматривать как отличный способ улучшить читаемость кода. Избегайте тяжелого вложения.

GetBackerZ
источник
Не отрицатель, но твоя аналогия немного утеряна для меня. Вы говорите, что лучше распределить код по нескольким строкам и иметь меньше слов в каждой строке?
Фураж
Распределите код и помощник по нескольким строкам и файлам как можно больше. Сосредоточиться на удобочитаемости. Не бросайте 8 или 9 классов в одном файле. Это делает код трудным для чтения и сложным в обслуживании. Если у вас большой код условия или циклы. Преврати их в коммунальные услуги. Избегайте тяжелого вложения. Пожалуйста, дайте мне знать, если это поможет объяснить это.
GetBackerZ
Возможно, вам следует отредактировать это в своем ответе, так как это прояснит, что вы имеете в виду.
Корм
Я использовал сценарий для Джеки Брауна в качестве критерия для модульных программ z / OS COBOL. Вы знаете, для
шутки
"имеет смысл для 5-летнего, когда мы можем." - для проблем реального мира, которые оплачивают счета, это редко возможно, и стремится к неправильной вещи
whatsisname