Стиль кодирования в.NET: осуществить ли рефакторинг в новый метод или нет?

Как Вы знающий, в коде.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, группируете подобную логику в подметод лучше (хотя они только используют однажды), или просто поместите их вместе в основной функции и добавьте//, объяснение здесь на запуске логики лучше?

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

Спасибо.

ОБНОВЛЕНИЕ: Спасибо все для ответа и входа до сих пор.

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

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

8
задан Matt Busche 27 February 2015 в 20:44
поделиться

11 ответов

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

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

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

1
ответ дан 5 December 2019 в 23:13
поделиться

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

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

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

1
ответ дан 5 December 2019 в 23:13
поделиться

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

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

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

Ваш проект

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

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

1
ответ дан 5 December 2019 в 23:13
поделиться

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

0
ответ дан 5 December 2019 в 23:13
поделиться

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

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

Другой причиной для разбиения метода на более мелкие блоки может быть юнит-тестирование и/или внедрение кодовых контрактов.

0
ответ дан 5 December 2019 в 23:13
поделиться

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

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

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

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

1
ответ дан 5 December 2019 в 23:13
поделиться

В таком стиле кодирования нет ничего "плохого", если код работает, его легко поддерживать и можно тестировать. Раздельные методы облегчают тестирование и изоляцию проблем.

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

0
ответ дан 5 December 2019 в 23:13
поделиться

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

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

0
ответ дан 5 December 2019 в 23:13
поделиться

Прочитайте это Class Member Usage Guidelines и, если у вас есть время, посмотрите эту книгу:

Programming .NET Components By Juval Lowy Publisher: O'Reilly. Там есть целый раздел о стандарте кодирования C# с хорошими примерами.

0
ответ дан 5 December 2019 в 23:13
поделиться

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

(1) Их легче протестировать изолированно как дискретные возможности ... Что еще более важно

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

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

1
ответ дан 5 December 2019 в 23:13
поделиться

Спасибо всем за ответы и вклад до сих пор.

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

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

0
ответ дан 5 December 2019 в 23:13
поделиться
Другие вопросы по тегам:

Похожие вопросы: