Стиль кодирования в .NET: стоит ли проводить рефакторинг в новый метод или нет? - PullRequest
8 голосов
/ 31 мая 2010

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

public void Button_Click(object sender, EventArgs e)
{
    some logic here..
    some logic there..

    DoSomething();
    DoSomethingThere();

    another logic here..

    DoOtherSomething();
} 

private void DoSomething()
{
}

private void DoSomethingThere()
{
}

private void DoOtherSomething()
{
}

public void DropDown_SelectedIndexChanged()
{
}

public void OtherButton_Click()
{
}

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

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

Я знаю, что такой способ группировки лучше использовать при написании старого ASP или стиля ColdFusion, но я не уверен, что этот стиль лучше для .NET или нет.

Вопрос в том, что лучше при разработке .NET, лучше группировать подобную логику в под-метод (хотя они используют только один раз), или просто соединить их вместе в основной функции и добавить // объяснение здесь в начале. из логики лучше?

Надеюсь, мой вопрос достаточно ясен.

Спасибо.

UPDATE: Спасибо всем за ответ и вклад.

Просто мы объединили всю логику и все в одну функцию (до этого у нас было всего 2-3 разработчика), и внезапно мы превратились в команду из 7-8 разработчиков, и у каждого свой стиль.

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

Ответы [ 11 ]

1 голос
/ 31 мая 2010

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

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

Я предлагаю вам создать новые классы для логики + методы.

Ваш проект

  • YourGUICode.cs
  • Task1Processor.cs
  • Task2Processor.cs
  • TaskNProcessor.cs

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

1 голос
/ 01 июня 2010

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

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

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

1 голос
/ 31 мая 2010

Все дело в удобстве чтения и обслуживания.

Компилятор или среда выполнения .NET Framework не заботятся о том, чтобы вызывать один длинный метод или несколько небольших методов (хорошо, могут быть некоторые минимальные различия производительности, но это не главное).

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

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

1 голос
/ 31 мая 2010

Лично я бы, вероятно, выбрал какой-нибудь шаблон Model-View-Controller (или аналогичный) при написании такого кода.

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

Разбиение вашего кода на небольшие блоки работы определенно упрощает его тестирование и отладку. В зависимости от того, что делают ваши функции «DoSomething», вы можете даже захотеть абстрагировать их в логические слои (часто разделяемые как библиотеки классов в .Net) - например: доступ к данным, службы приложений и т. Д. И т. Д.

1 голос
/ 31 мая 2010

Разбиение таких подпрограмм на множество меньших методов имеет как минимум два преимущества.

(1) Они могут быть легко проверены изолированно как скрытые возможности ... Более важно

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

(3) Когда вы разбиваете вещи на маленькие части, вы можете обнаружить, что некоторые процедуры могут быть статичными. Это означает, что каждый экземпляр класса будет меньше во время выполнения, и, следовательно, вы будете проводить меньше времени в GC. Это означает, что некоторые подпрограммы также будут более производительными.

0 голосов
/ 01 июня 2010

Спасибо всем за ответ и пока.

Просто мы объединили всю логику и все в одну функцию (раньше у нас было всего 2-3 разработчика), и внезапно мы превратились в команду из 7-8 разработчиков, и у каждого свой стиль.

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

0 голосов
/ 31 мая 2010

Нет ничего «неправильного» в этом стиле кодирования, если код работает, прост в обслуживании и может быть протестирован. Отдельные методы облегчают тестирование и изоляцию проблем.

Существует более сложный вопрос об общем дизайне, а другие ответы, в которых упоминается Model-View-Controller и т. Д., Стоят вашего времени.

0 голосов
/ 31 мая 2010

Прочитайте это Руководство по использованию членов класса и, если у вас есть время, взгляните на эту книгу:

Программирование компонентов .NET Автор Juval Lowy Издатель: O'Reilly.Есть целый раздел, в котором говорится о C # Coding Standard с хорошими примерами.

0 голосов
/ 31 мая 2010

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

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

0 голосов
/ 31 мая 2010

По большей части это вопрос личного стиля, поэтому, вероятно, нет правильного ответа.

Тем не менее, может быть несколько причин для рефакторинга в отдельные методы. Как вы уже упоминали, повторное использование является, вероятно, наиболее убедительным. Есть также аргумент для разбиения больших методов на более мелкие блоки - метод должен делать только одно. См. Дядюшку Бобу о теории Чистый код .

Еще одна причина разбиения метода на более мелкие блоки - это модульное тестирование и / или реализация контрактов кода.

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