winforms .Net Относительно использования небольших методов

Question

Я работаю над разработкой приложения с использованием winforms в C #. При разработке я хочу использовать много небольших методов, например, resetPerticularCombo (), поэтому код остается максимально чистым. Но проблема в том, что создание методов для 3-5 строк кода может привести к слишком большому количеству вызовов методов, я слышал, что при компиляции Visual Studio 2008 об этом позаботится, используя вставку кода.

Мой вопрос таков: должен ли я полагаться на эту функцию и продолжать использовать небольшие вспомогательные методы или мне следует использовать встраивание самостоятельно?

Answer 1

Вам не нужно беспокоиться о большом количестве вызовов методов, пока вы не докажете , что это проблема.Очень маловероятно (IMO), что это на самом деле вызовет проблему, и если это даст вам более читаемый код, это самое важное.

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

По моему опыту, микрооптимизация в "использовать меньше методов: «подобный уровень почти всегда бессмыслен по сравнению с изменениями более высокого уровня (например, переход от поиска к списку к поиску по словарю и т. д.).

Answer 2

Я согласен с Джоном Скитом.

Относительно корпоративных приложений Я могу сказать вам следующее

Я возглавляю небольшую команду разработчиков (5 разработчиков).У нас есть приложение с 500k loc.

Мы всегда стараемся найти наиболее специфическую проблему, которую должен иметь метод.Таким образом, мы получили много маленьких и «самообъяснимых» методов.В результате у нас есть много методов, и это никогда не приводит к проблеме.

В большинстве случаев узкие места возникают при доступе к ресурсам, таким как SQL Server, файлы и т. Д. ... или об отсутствии асинхронности.

Кроме того, у вас есть работа, которую вы можете профилировать с помощью Ants Profilder.

Мне также нравятся эти "правила" оптимизации, которые я нашел недавно в Интернете

FirstRuleOfOptimization - нет.

SecondRuleOfOptimization - не ... пока.P

ThirdRuleOfOptimization - ProfileBeforeOptimizing

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

Answer 3

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

resetPerticularCombo() и resetAnotherCombo(), возможно, стоит преобразовать в resetCombo(PerticularCombo) и resetCombo(AnotherCombo), если процедуры в остальном совпадают.

С анонимными лямбдами это можно использовать даже для объединения других похожих алгоритмов: _{(потенциально плохой пример, но для продолжения использования кода ОП)} ProcessCombo(PerticularCombo, (c)=>c.Reset()) и ProcessCombo(PerticularCombo, (c)=>c.SelectFirst())

_{Я программист VB.NET, и этот код был введен непосредственно в SO без какой-либо проверки синтаксиса.}