Чи слід класи, перерахунки та інші об'єкти розміщувати в окремих файлах?

Команда \ архітектор моєї компанії стверджує, що масштабний проект легше зрозуміти, якщо "об'єкти, пов'язані логікою", розміщені в одному файлі .cs.

Цитую:

• "Всю структуру логіки та інтерфейс і клас можна побачити в одному місці. Це аргумент, який неможливо спростувати. Щоб побачити те саме, але з купою файлів, потрібно використовувати інструменти, клас діаграма, R # для навігації тощо. "

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

• "... Що стосується розділення бази коду між розробниками, то зараз це не проблема редагування одного і того ж файлу. Злиття не є проблемою."

Я багато разів чув і читав, що нам потрібно створити один .cs-файл за перерахунком, класом тощо, і це найкраща практика.

Але я не можу його переконати. Він каже, що не довіряє жодним відомим програмістам, таким як Джон Скіт. До речі, тут є думка Скіта на цю тему: Де найкраще знайти типи переліків?

Що ти думаєш? Чи є реальна проблема? Або це питання смаку і має регулюватися стандартом кодування організації?

У аргументі вашої команди є кілька недоліків:

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

2. Класи та перерахунки, які належним чином зафіксовані з коментарями XML, дуже самоописуються, просто наведення курсору на елемент, на який посилається.

3. Ви завжди можете дійти до визначення класу або перерахунку, клацнувши правою кнопкою миші посилання та вибравши "Перейти до визначення", тому це дійсно не має значення, де ви її кладете.

4. Складання об'єктів "логічним" способом є довільним (тобто ви повинні подумати про те, що означає "логічний". Я вважаю за краще витратити ці цикли годин на фактичне програмування).

Встановлення кожного визначення об'єкта у власному файлі створює рівномірне, дисципліноване очікування організації та структури, і не викликає питань на кшталт "чому це тут?" Це дуже приємна річ.

Якщо два або більше об'єктів логічно пов'язані, просто покладіть їх у власну папку в Провіднику проектів.

Швидше за все, ведучий команди різав зуби в більш ранню епоху, коли клацання правою кнопкою миші та вибір "перейти до визначення" не було можливим. Я знаю, що коли я перебуваю у режимі розробки важких шипів, я вирощуватиму досить масивні файли класу, поки не дозволю resharper виправити це для мене.

У будь-якому випадку, якщо ви хотіли взяти команду до виконання завдання, запитайте його, чому ці класи та перерахунки не є дочірніми класами та перерахунками - немає причин оголошувати їх як самостійні структури, якщо вони справді залежні сутності. Це може допомогти йому трохи подумати.