C #, Написание более длинный метод или более короткий метод?

Question

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

Итак, какая сторона верна?

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

Answer 5

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

Answer 6

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

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

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

Answer 7

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

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

Answer 8

Лично я не боюсь длинных методов, пока человек, пишущий их, пишет их хорошо (каждый фрагмент подзадачи разделен 2 новыми строками и хорошим комментарием, предшествующим этому, и т. Д. Кроме того, идентификация очень важна.) , Фактически, много раз я даже предпочитаю их (например, при написании кода, который делает вещи в определенном порядке с последовательной логикой).

Кроме того, я действительно не понимаю, почему разбиение длинного метода на 100 частей улучшит читабельность (как полагают другие). Только наоборот. В конечном итоге вы будете просто перепрыгивать повсюду и удерживать фрагменты кода в своей памяти, чтобы получить полную картину того, что происходит в вашем коде. Объедините это с возможным отсутствием комментариев, неправильных имен функций, множества похожих имен функций, и вы получите идеальный рецепт хаоса. Кроме того, вы можете пойти другим путем, пытаясь уменьшить размер методов: создать МНОГИЕ классы и МНОГИЕ функции, каждая из которых может принимать МНОГИЕ параметры. Я не думаю, что это также улучшает читабельность (особенно для начинающего проекта, который не имеет ни малейшего представления о том, что делает каждый класс / метод).

И требование, чтобы «функция выполняла« одну вещь »», очень субъективно. «Одной вещью» может быть увеличение переменной на единицу до выполнения тонны работы, предположительно для «той же самой вещи».

Мое правило - только повторное использование: Один и тот же код не должен появляться много раз во многих местах. Если это так, вам нужна новая функция. Все остальное - просто философские разговоры. На вопрос «почему вы делаете ваши методы такими большими», я отвечаю: «Почему нет, если код простой?».

(только мое мнение - проголосуйте, сколько хотите)