Какое количество кода должно быть в одном файле?

Question

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

Лично я стараюсь держать свои файлы достаточно маленькими (особенно заголовочные файлы при работе с C / C ++). То есть, как правило, у меня будет только один класс или набор функций в данном файле, так что файл в общем & Lt; 500 строк. Тем не менее, все связанные вещи обычно имеют одно и то же пространство имен.

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

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

Например, моя система частиц разбита на system.h, emitter.h, load.h, частицы.h и т. д. и содержит файлы .cpp для каждого из них. Однако некоторые системы частиц, на которые я смотрел, похоже, поместили весь источник в одну .h и .cpp тысячи строк.

Answer 1

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

Answer 2

Вы должны идентифицировать программные модули с точки зрения логически, а не физически. Поэтому вы должны разрабатывать классы / функции в зависимости от ответственности.

Вы можете использовать подход CRC, чтобы определить ответственность каждого класса.

Answer 3

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

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

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

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

Answer 4

Слишком мало в каждом исходном файле так же плохо, как и слишком много - беспорядок только перемещается из отдельного исходного файла в сам проект.

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

Я также разделю его, если у меня есть ощущение, что он содержит функции, которые, вероятно, будут сильно изменены в будущем, а также функции, которые, вероятно, будут стабильными.

Answer 5

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

Однако во время разработки это ужасная идея по причинам, которые вы упомянули, а также потому, что она почти гарантирует, что будут проблемы слияния RCS, когда над проектом работает более одного программиста.

Answer 6

Я разбил все разные части моего проекта на разные файлы, в основном на время компиляции, которое с ним связано. Когда объекты для файлов CC, которые мне нужно связать, уже существуют, мне не нужно перекомпилировать их с нуля.

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

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

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