Кодирование руководств: Как Вы разделяете свои большие исходные файлы?
Попробуйте отследить выполнение, левая часть (=>) указывает на новый вызов одной из функций, правая часть указывает, какие шаги предпринимаются для определения конечного результата.
is_odd(1) => not is_even(1)
is_even(1) => is_odd(0)
is_odd(0) => not (is_even(0))
is_even(0) => True
=> not (True)
=> False
=> False
=> not (False)
=> True
Или это могло бы помочь больше,
is_odd(1)
=> not is_even(1)
=> not (is_odd(0)
=> not (not (is_even(0))
=> not (not (True))
=> not (False)
=> True
FWIW, эти функции являются так называемыми «взаимно рекурсивными» (то есть более чем одна функция вызывает друг друга). Если вас не устраивает рекурсия, вам, вероятно, следует начать с простой единственной рекурсии, распространенными примерами которой являются числа Фибоначчи или факториальная функция.
def fact(n):
if n == 0:
return 1
else:
return n * fact (n-1)
def fib(n):
if n == 0:
return 1
elif n == 1:
return 1
else:
return fib (n-1) + fib (n-2)
14 ответов
Я думаю, что Вашей проблеме подводят итог с термином, который Вы используете: "Основной файл C#".
Если Вы не имеете в виду основной (как в основном методе ()) нет никакого места для того понятия.
Если у Вас есть всеобъемлющий служебный класс или другие общепринятые методики, необходимо повредить их в подобные функциональные компоненты.
Обычно мои файлы являются просто непосредственными отображениями классов.
Иногда классы, которые очень связаны, находятся в том же файле.
Если Ваш файл является слишком большим, это - признак, Ваш класс является слишком большим и слишком общим.
Я пытаюсь сохранить свои методы на половину экрана или меньше. (Когда это - код, я пишу с нуля, что это обычно - 12 строк или меньше, но в последнее время я работал в существующем коде от других разработчиков и имел необходимость осуществить рефакторинг 100 функций строки...),
Иногда это - экран, но это становится очень большим.
Править:
Для рассматривания размера ограничивают вопрос о функциях - для меня это меньше о размере (хотя это - хороший индикатор проблемы), и больше о выполнении только одной вещи и хранении каждого ПРОСТОГО.
Если у Вас есть регионы кода в классе, простой метод состоит в том, чтобы использовать partial ключевое слово и выход, что определение класса в тот файл. Я обычно делаю это для больших классов.
Конвенция, которую я использую, состоит в том, чтобы иметь ClassName_RegionName.cs. Например, если я хочу вспыхнуть класс, который управляет схемой для соединения с базой данных, и я назвал класс DatabaseConnection, я создам файл по имени DatabaseConnection.cs для основного класса и затем DatabaseConnection_Schema.cs для функциональности схемы.
Некоторые классы просто должны быть большими. Это не плохой дизайн; они просто тяжелы реализацией.
Разделите код так, чтобы каждый класс/файл/функция/и т.д. делает только Один Thing™. Единственный Принцип Ответственности является хорошей инструкцией для разделения функциональности в классы.
В наше время самые большие классы, которые я пишу, являются приблизительно 200 строками долго, и методы являются главным образом 1-10 строками долго.
Синтаксический анализатор Intellisense в Visual Studio, 2008, кажется, значительно быстрее, чем один 2005 (я знаю их конкретно, сделал большую работу в этой области), поэтому хотя необходимо определенно изучить разделение файла в какой-то момент, как другие упомянули, Visual Studio, 2008 может разрешить непосредственную проблему производительности. Я использовал его для открытия 100K + строка Linq в файл SQL без большого количества проблемы.
Возможно, OP может ответить: Ваш проект использует Объектно-ориентированное программирование? То, что Вы используете слово "файл", предполагает, что это не.
Пока Вы не понимаете объектную ориентацию, нет никакой надежды на улучшение Вашего кода никаким важным способом. Вы добились бы большего успеха для не разделения файла вообще, ожидали бы, пока это не растет, чтобы быть невыносимо медленным и ошибочным, затем вместо того, чтобы больше перенести его, пойдите, изучают OO.
Ну, я боюсь сказать, что у Вас может быть больший текущий вопрос, чем медленное время загрузки. Вы собираетесь поразить выпуски сильно связанного кода и проблем пригодности для обслуживания/удобочитаемости.
Существуют очень серьезные основания разделить файлы класса на меньшие файлы (и одинаково серьезные основания переместить файлы в различные проекты/блоки).
Думайте о том, что цель, которой Ваш класс, как предполагается, достигает. Каждый файл должен действительно только иметь единственную цель. Если это слишком обобщено в его цели, например, "Содержите Логика Корзины Покупок", затем Вы направляетесь вниз неправильный путь.
Кроме того, как упомянуто, термин Вы используете: "Основной файл C#" просто сильно пахнет, что у Вас есть очень процедурное мышление. Мой советовать должен был бы остановиться, отступить и иметь быстрое чтение по некоторым следующим темам:
- Общие принципы ООП
- Управляемый доменом дизайн
- Поблочное тестирование
- Контейнеры МОК
Удача с Вашими поисками.
Можно искать мелочи, чтобы изменить и изменять каждого медленно со временем.
Все методы используются в том классе только? Ищите методы поддержки, такие как проверка, обработка строк, которая может быть выселена в helper/util классы.
Вы используете какие-либо разделы #region? Логические группировки связанных методов в #region часто предоставляют себя тому, чтобы быть разделенным на отдельные классы.
Действительно ли класс является формой? Рассмотрите использование Пользовательских элементов управления для средств управления формой или групп средств управления формой.
Иногда большие классы развиваются со временем из-за большого количества разработчиков, делающих быстрые исправления / новые возможности, не рассматривая общего замысла. Пересмотрите некоторых других ссылок теории дизайна, обеспечили здесь и полагают, что продолжающаяся поддержка осуществляет их, такие как обзоры кода и семинары команды для рассмотрения дизайна.
Используйте Частичные классы. Можно в основном повредить единый класс в несколько файлов.
Нет никаких жестких правил, но существует генеральное соглашение, что больше, более короткие функции лучше, чем единственная большая функция, и больше меньших классов лучше, чем 1 большой класс.
Функции, больше, чем приблизительно 40 строк, должны заставить Вас рассмотреть, как можно разбить его. Особенно взгляд на вложенные циклы, которые сбивают с толку и часто легки перевести в вызовы функции с хорошими описательными именами.
Я разбиваю классы, когда я чувствую, что они делают больше чем 1 вещь, как презентация соединения и логика. Большой класс является меньшим количеством проблемы, чем большой метод, пока класс делает 1 вещь.
Согласие в руководствах по стилю, которые я видел, к групповым методам доступом с конструкторами и открытыми методами для вершины. Что-либо последовательное является большим.
Необходимо читать на стиле C# и осуществляющий рефакторинг для реального понимания проблем, которые Вы решаете.
Рефакторинг является превосходной книгой, которая имеет подсказки для перезаписи кода так, чтобы поведение было сохранено, но код более четкий и легче работать с.
Элементы Стиля C# являются хорошим мертвым древовидным руководством по стилю C#, и это сообщение в блоге имеет много ссылок на хорошие руководства по стилю онлайн.
Наконец, рассмотрите использование FxCop и StyleCop. Они не помогут с вопросами, которые Вы задали, но можете обнаружить другие стилистические проблемы со своим кодом. Так как Вы опустили палец ноги в воду, Вы могли бы также вскочить.
Это много, но разрабатывающий вкус, стиль и ясность существенное различие между хорошими разработчиками и плохими.
Не кодируйте процедурно, и Вы не закончите с 4 200 строками в одном файле.
В C# это - хорошая идея придерживаться некоторых ТВЕРДЫХ объектно-ориентированных принципов разработки. Каждый класс должен иметь одну и только одну причину измениться. Основной метод должен просто запустить начальную точку для приложения (и настроить Ваш контейнер внедрения зависимости при использовании чего-то как StructureMap).
У меня обычно нет файлов больше чем с 200 строками кода, и я предпочитаю их, если они находятся под 100.
Книжный Рефакторинг Martin Fowler я думаю, дает Вам хорошую начальную точку для этого. Это сообщает о том, как определить "запахи кода" и как осуществить рефакторинг Ваш код для фиксации этих "запахов". Естественный результат (хотя это не основная цель) состоит в том, что Вы заканчиваете с меньшим больше удобных в сопровождении классов.
Править
В свете Вашего редактирования я всегда настаивал, что хорошая практика кодирования для кода бэкенда является тем же на уровне представления. Некоторые очень полезные шаблоны для рассмотрения для рефакторингов UI являются Командой, Стратегией, Спецификацией и состоянием.
Короче говоря, Ваше представление должно только иметь код в нем, чтобы обработать события и присвоить значения. Вся логика должна быть разделена на другой класс. После того как Вы делаете это, Вы найдете, что становится более очевидно, где можно осуществить рефакторинг. Сетки делают это немного более трудным, потому что они делают слишком легким разделить Ваше состояние презентации между логикой представления и представлением, но с некоторой работой, можно вставить косвенность для уменьшения боли, вызванной этим.
Разделите свои типы, где естественно разделить их - но не упустить типы, которые делают слишком много. Приблизительно в 500 строках (Java или C#) я заинтересован. Приблизительно в 1 000 строк я начинаю выглядеть твердым на то, должен ли тип быть разделен..., но иногда это просто не может быть.
Что касается методов: Мне не нравится он, когда я не вижу целый метод на экране за один раз. Очевидно, это зависит от размера монитора и т.д., но это - разумное эмпирическое правило. Я предпочитаю, чтобы они были короче все же. Снова, существуют исключения - некоторую логику действительно трудно распутать, особенно если существует много локальных переменных, которые естественно не хотят инкапсулироваться вместе.
Иногда имеет смысл для единственного типа иметь много методов - такой как System.Linq.Enumerable но частичные классы могут помочь в таких случаях, если можно разбить тип в логические группы (в случае Enumerable, группировка агрегированием / операции присвоения / фильтрующий и т.д. казалась бы естественной). Такие случаи редки, по моему опыту, все же.
В классической книге "Структурное программирование" Dijkstra однажды записал наделенный правом раздел: "На нашей неспособности сделать много". Его точка была проста. Люди не очень умны. Мы не можем манипулировать больше, чем несколько понятий в наших умах когда-то.
Очень важно сохранить Ваши классы и методы маленькими. Когда метод добирается выше приблизительно дюжины строк, он должен быть разбит. Когда класс добирается выше нескольких сотен строк, он должен быть разбит. Это - единственный способ сохранить код хорошо организованным и управляемым. Я программировал в течение почти 40 лет, и с каждым годом, который прошел, я понимаю, насколько важный "небольшое" слово при записи программного обеспечения.
Относительно того, как Вы делаете это, это - очень большая тема, которая была записана во многие различные разы. Это - все об управлении зависимостью, сокрытии информации и объектно-ориентированном дизайне в целом. Вот список чтения.
Каждый класс должен сделать одну мелочь и сделать это хорошо. Действительно ли Вашим классом является Форма? Затем это не должно иметь НИКАКОЙ бизнес-логики в нем.
Это представляет единственное понятие, как пользователь или состояние? Затем это не должно иметь никакого рисунка, загружать/сохранять и т.д...
Каждый программист проходит этапы и уровни. Вы распознаете проблему со своим текущим уровнем, и Вы готовы приблизиться к следующему.
Из того, что Вы сказали, это кажется, что Ваш текущий уровень "Решает проблему", скорее всего, с помощью процессуального кода, и необходимо начать больше смотреть на новые способы приблизиться к нему.
Я рекомендую изучить, как действительно сделать дизайн OO. Существует много теорий, что Вы, вероятно, услышали, что не имеют смысла. Причина, которую они не делают, состоит в том, что они не относятся к способу, которым Вы в настоящее время программируете.
Позвольте мне найти хорошее сообщение... Просмотрите их для запуска:
how-do-i-break-my-procedural-coding-habits
object-oriented-best-practices-inheritance-v-composition-v-interfaces
Существуют также сообщения, которые будут относиться, Вы к хорошему OO разрабатываете книги. Книга "Рефакторинга" является, вероятно, одним из самых лучших мест, которые Вы могли запустить.
Вы в положительной стороне прямо сейчас, но Вы не верили бы, как далеко необходимо пойти. Я надеюсь, что Вы взволнованы этим, потому что часть этого материала в Вашем ближайшем будущем является частью лучшего программирования "Полезный опыт", который Вы будете когда-либо иметь.
Удачи.