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

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

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

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

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

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

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

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

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

РЕДАКТИРОВАТЬ:

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

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

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

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

• Чистый код
• ТВЕРДЫЙ
• Agile-принципы, шаблоны и методы в C #

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

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

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

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

ИЗМЕНИТЬ

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

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

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

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

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

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

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

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

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

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

person RossFabricant    schedule 03.03.2009