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

Question

Что вы думаете об этом виде преобразования кода в файлы?

~/proj/MyClass.ext  
~/proj/MyClass:constructors.ext  
~/proj/MyClass:properties.ext  
~/proj/MyClass:method-one.ext  
~/proj/MyClass:method-two:int.ext
~/proj/MyClass:method-two:string.ext

На языке, который более функционально ориентирован:

~/proj/definitions.ext  
~/proj/function-one.ext  
~/proj/function-two:int.ext  
~/proj/function-two:string.ext  
...

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

У нас может быть какой-нибудь демон-процесс, который синхронизирует зеркальный MyClass.ext файл с этой группой файлов, или наш любимый редактор кода видит их все, но показывает их как их логическое объединение, или этот тип преобразования происходит только как набор хуков pre + post-commit.

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

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

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

EDIT

Из всех ответов, особенно Скотта, я пришел к выводу, что единственный реальный способ, которым моя идея может быть полезна, - это возможность автоматически вносить список измененных пар class:method в подробную часть каждого коммита. to-vcs message. Этого гораздо проще достичь с помощью небольших скриптов, запускаемых перед фиксацией, чтобы соответствующим образом обновить шаблон сообщения.

Answer 1

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

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

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

Answer 2

CON

Class-per-file позволяет вам обернуть свой мозг вокруг класса в целом. Если ваши классы велики до такой степени, что они представляют собой многостраничные уродства, вам, возможно, придется разделить методы на отдельные файлы, но вы также можете провести рефакторинг и избавить себя от головной боли при обслуживании. Это один из аргументов против #region.

Answer 3

Некоторые системы контроля версий, в частности Git (и, возможно, BitKeeper), работают на этом уровне не на уровне файлов, а на уровне разработки.

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

---

Con: Я думаю, что вам действительно нужна VCS, которая поддерживает его специально, вместо того, чтобы пытаться прикрепить ее к VCS на основе файлов (Git не очень хорошо работает в Windows, а BitKeeper - коммерческое программное обеспечение ). Другим недостатком является то, что вы, вероятно, не можете сделать это не зависящим от языка способом. AFAIK, Git использует некоторую расширенную эвристику для отслеживания отдельных частей содержимого в файле, но это не является непогрешимым, и могут быть некоторые языки с нестандартным (не C-подобным) синтаксисом функции / метода, где обычная эвристика может дать сбой (предикаты Prolog) .

Answer 4

PRO:

Я заметил, что многие библиотеки GNU C разбивают свой источник на 1 функцию на файлы модулей перевода. Из того, что я понял, это помогает при статическом связывании библиотеки в двоичный файл. По-видимому, при поиске символа компоновщик будет включать всю единицу перевода, в которой находится символ (что имеет смысл, поскольку в единице, от которой зависит символ, могут быть статические функции и данные). Поэтому, если вы разделите свой код на гранулированные файлы, возможно, вы сможете свести размер статически связанных файлов к минимуму.

Я бы предположил, что в C ++ меньше преимуществ, особенно для классов с виртуальными членами, поскольку виртуальная таблица вводит множественные символьные зависимости.

---

CON:

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

Answer 5

Я согласен, это слишком детально.

Однако я рассмотрел разделение элементов по объему:

ClassA-interface.cs      (public members)
ClassA-implementation.cs (non-public members)

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

Answer 6

Место на жестком диске.

При установке Windows по умолчанию каждый файл занимает не менее 4 КБ. Другие файловые системы могут занять больше или меньше, но почти всегда есть минимальный размер. Я мог внезапно увидеть большой программный проект, занимающий большое количество дискового пространства в этой системе. Это может не быть большой проблемой на машинах разработчика, но я бы беспокоился о сервере управления исходным кодом, поскольку кажется, что серверам никогда не хватает места на диске.

Answer 7

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

aka Camping vs. Rails и др.

Уровень детализации, который вы наметили выше, кажется мне немного выше. Я предвижу рефакторинг как кошмар. Даже в таких средах, как ASP.net и Ruby on Rails, я постоянно очищаю свое рабочее пространство, потому что у меня слишком много открытых файлов, и это вызывает проблемы с производительностью.

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

Извините - я хочу предложить профи здесь, но он просто не приходит ко мне

Answer 8

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

Answer 9

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

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

Answer 10

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

Я был бы обеспокоен крупными проектами с огромным количеством файлов.