C#, Пишущий более длинный метод или более короткий метод?

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

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

Источник, который говорит, что методы должны быть длинными, неверен , на многих уровнях.

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

Нет единого простого правила относительно размера функции. Руководство должно быть функция должна делать «одну вещь». Это немного расплывчато, но становится легче с опытом. Небольшие функции обычно приводят к удобочитаемости. Большие из них иногда необходимы.

Беспокойство по поводу затрат на вызовы методов является преждевременной оптимизацией.

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

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

. лучший единственный критерий, который поможет вам в методах определения размеров, - это сохранять их хорошо проверяемыми . Если вы можете (и на самом деле делаете! -) тщательное модульное тестирование каждого метода, ваш код, скорее всего, будет достаточно хорошим; если вы экономите на тестировании, ваш код, вероятно, будет в лучшем случае посредственным. Если метод трудно тщательно протестировать, то этот метод, вероятно, будет «слишком большим» - пытаться делать слишком много вещей, и, следовательно, его будет сложнее читать и поддерживать (а также плохо протестированы и, следовательно, вероятны ошибки).

Как всегда, речь идет о поиске хорошего баланса. Самое главное, что метод делает только одну вещь . Более длинные методы имеют тенденцию делать больше чем одно.

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

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

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