Руководства по кодированию: как вы разделяете свои большие исходные файлы?

Question

Проект, над которым я работаю, только что ударил 4200 строк в главном файле C#, что заставляет IntelliSense занять несколько секунд (иногда до 6 или около того), в течение которых Visual Studio блокируется. Мне интересно, как все остальные расщепляют свои файлы и есть ли консенсус.

Я попытался найти несколько руководств и нашел Google's C++ guide, но я ничего не мог увидеть о семантике, например, о размерах и размерах файлов; может быть, это там - я не смотрел на это какое-то время.

Итак, как вы разделили свои файлы? Вы группируете свои методы с помощью функций, которые они выполняют? По типам (обработчики событий, частные/публичные)? И при каких ограничениях вы разделяете функции?

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

Answer 1

Я думаю, что ваша проблема подытожена термином, который вы используете: «Основной файл C#».

Если вы не имеете в виду главное (как в методе main()), для этой концепции нет места.

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

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

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

Если ваш файл слишком велик, это свидетельствует о том, что ваш класс слишком большой и слишком общий.

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

Иногда это экран, но это становится очень большим.

EDIT:

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

Answer 2

Использование Частичные классы. Вы можете разбить один класс на несколько файлов.

Answer 3

Разделите свои типы, где это естественно, чтобы разделить их - но следите за типами, которые делают слишком много. Около 500 строк (Java или C#) меня беспокоит. Примерно в 1000 строк я начинаю внимательно изучать вопрос о том, следует ли разделить тип ... но иногда его просто не может/не должно быть.

Что касается методов: мне не нравится, когда я не вижу весь метод на экране за раз. Очевидно, что это зависит от размера монитора и т. Д., Но это разумное эмпирическое правило. Я предпочитаю, чтобы они были короче. Опять же, есть исключения - некоторая логика очень трудно распутать, особенно если есть много локальных переменных, которые, естественно, не хотят быть инкапсулированы вместе.

Иногда это имеет смысл для одного типа, чтобы иметь много методов - такие, как System.Linq.Enumerable но частичные классы могут помочь в таких случаях, если вы можете разбить типа на логические группы (в случае Enumerable, группировка путем агрегирования/установки операций/фильтрации и т. д. представляется естественным). Однако такие случаи редки в моем опыте.

Answer 4

Не кодируйте процедурно, и вы не получите 4 200 строк в одном файле.

В C# неплохо придерживаться принципов объектно-ориентированного проектирования SOLID. У каждого класса должна быть одна и только одна причина для изменения. Основной метод должен просто запустить начальную точку для приложения (и сконфигурировать ваш контейнер инъекции зависимостей, если вы используете что-то вроде StructureMap).

я вообще не имеют файлы с более чем 200 строк кода, и я предпочитаю их, если они находятся под 100.

Answer 5

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

Есть очень веские причины для разделения файлов классов на более мелкие файлы (и одинаково веские причины для перемещения файлов в разные проекты/сборки).

Подумайте, какую цель должен достичь ваш класс. Каждый файл должен иметь только одну цель. Если он слишком обобщен в своей цели, например, «Содержать логику корзины покупок», тогда вы идете по неправильному пути.

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

• Общие OOP
• домена управляемых дизайн
• тестирования Unit
• IoC Контейнеры

Удачи вам в поиске.

Answer 6

Книга Мартина Фаулера Refactoring Я думаю, это дает вам хорошую отправную точку для этого. Он инструктирует о том, как идентифицировать «запахи кода» и как реорганизовать ваш код, чтобы исправить эти «запахи». Естественный результат (хотя это не главная цель) заключается в том, что вы получаете более мелкие классы обслуживания.

EDIT

В свете вашего редактирования, я всегда настаивал на том, что хорошая практика для кодирования фоновой коды одинакова в ярусе презентации. Некоторыми очень полезными моделями для рефакторинга UI являются Command, Strategy, Specification и State.

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

Answer 7

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

Функции более 40 строк или около того должны заставить вас подумать, как вы можете разбить его. Особенно посмотрите на вложенные петли, которые запутывают и часто легко переводить на вызовы функций с красивыми описательными именами.

Я разбиваю классы, когда чувствую, что они делают больше, чем 1 вещь, например, представление микса и логику. Большой класс - это не проблема, а большой метод, если класс делает 1 вещь.

Консенсус в руководствах по стилям, которые я видел, заключается в групповом методе доступа, с конструкторами и общедоступными методами сверху. Все, что последовало, великолепен.

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

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

Elements of C# Style является хорошим руководством по дереву на дереве C#, и этот blog post имеет ряд ссылок на хорошие руководства по онлайн-стилю.

Наконец, рассмотрите, используя FxCop и StyleCop. Они не помогут в заданиях, которые вы задали, но можете обнаружить другие стилистические проблемы с вашим кодом. Так как вы окунули свой носок в воду, вы тоже можете вскочить.

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

Answer 8

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

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

Некоторые классы просто должны быть большими. Это неплохой дизайн; они просто реалистичны.

Answer 9

Каждый класс должен делать одну маленькую вещь и делать это хорошо. Является ли ваш класс формой? Тогда в ней не должно быть ЛЮБОЙ бизнес-логики.

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

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

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

Я рекомендую посмотреть, как реально выполнять дизайн OO. Есть много теорий, которые вы, наверное, слышали, которые не имеют смысла. Причина, по которой они не делают, заключается в том, что они не применяются к тому, как вы сейчас программируете.

Лемм найти хороший пост ... Посмотрите это, чтобы начать:

how-do-i-break-my-procedural-coding-habits

are-there-any-rules-for-oop

object-oriented-best-practices-inheritance-v-composition-v-interfaces

Есть также сообщения, которые относятся к вам хорошо OO дизайн книг , Книга «Рефакторинг», вероятно, является одним из лучших мест, где вы можете начать.

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

Удачи.

Answer 10

Вы можете искать мелкие вещи, которые могут меняться и постепенно меняться с течением времени.

• Все ли методы, используемые только в этом классе? Ищите методы поддержки, такие как проверка правильности, манипуляции с строками, которые могут быть перенесены в классы-помощники/утилиты.

• Вы используете какие-либо разделы #области? Логические группировки связанных методов в #region часто поддаются разделению на отдельные классы.

• Является ли класс формой? Рассмотрите возможность использования элементов управления пользователя для элементов управления формы или групп элементов управления формой.

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

Answer 11

Возможно, OP может ответить: это ваш проект с использованием объектно-ориентированного программирования? Тот факт, что вы используете слово «файл», говорит о том, что это не так.

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

Answer 12

Парсер Intellisense в Visual Studio 2008, кажется, значительно быстрее, чем один 2005 (я знаю, что они специально проделали большую работу в этой области), поэтому, хотя вам определенно нужно разбить файл в какой-то момент, другие упомянули, Visual Studio 2008 может решить вашу непосредственную проблему с производительностью. Я использовал его, чтобы открыть файл Linq to SQL 100K + без особых проблем.

Answer 13

В классической книге «Structured Programming» Дейкстра однажды написал раздел, озаглавленный «О нашей неспособности многое сделать». Его точка была проста. Люди не очень умны. Мы не можем манипулировать несколькими понятиями в нашем сознании за один раз.

Очень важно, чтобы ваши классы и методы были небольшими. Когда метод получает более дюжины строк или около того, его следует разбить. Когда класс выходит за пару сотен строк, его следует разбить. Это единственный способ сохранить код хорошо организованным и управляемым. Я программировал почти 40 лет, и с каждым годом, который прошел, я понимаю, насколько важно слово «маленький» при написании программного обеспечения.

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

• Clean Code
• SOLID
• Agile Principles, Patterns, and Pratices in C#

Answer 14

Split код так, чтобы каждый класс/файл/функция/и т.д.. делает только One Thing ™. The Single Responsibility Principle является хорошим ориентиром для разделения функциональности на классы.

В настоящее время самые большие классы, которые я пишу, составляют около 200 строк, а методы в основном составляют 1-10 строк.