Сколько параметров - слишком многие? [закрытый]

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

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

1. , Ваш Метод делает слишком много, и необходимо осуществить рефакторинг.
2. Вы могли бы хотеть рассмотреть использование набора или некоторой структуры данных.
3. Переосмысление Ваш дизайн класса, возможно, некоторые вещи не должны быть розданы.

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

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

В конце, все это сводится к персональному вкусу.

Я соглашусь с 3, хорошо, 4 слишком многие как инструкция. С более тогда 3 параметрами Вы неизбежно делаете более тогда одну задачу. Более тогда задачи должны быть разделены на отдельные методы.

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

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

Если бы у меня есть 7-10 параметров в одной стандартной программе, я смотрю на связывание их в новый класс но не, если тот класс был бы только набором полей с методами get и методами set - новый класс имеет к , делают что-то другое, чем перестановка оценивает в и. Иначе я скорее выносил длинный список параметров.

Я основывал бы свой ответ о том, как часто функция вызвана.

, Если это - функция init, которая только когда-либо вызывается когда-то тогда, позволяют ему взять 10 детских колясок или больше, кто заботится.

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

По словам Jeff Bezos известности Amazon, не больше, чем может питаться две пиццы :

Это - известное то, что в среднем люди могут сохранить 7 +/-2 вещи в их голове за один раз. Мне нравится использовать тот принцип с параметрами. Предполагая, что программисты являются всеми необычными умными людьми, я сказал бы, что все 10 + является слишком многими.

BTW, если параметры подобны всегда, я поместил их в вектор или список, а не структуру или класс.

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

Я потянул бы предел для государственных функций в 5 параметрах сам.

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

Функция может только иметь слишком много параметров, если некоторые параметры избыточны. Если все параметры используются, функция должна иметь корректное количество параметров. Берите это часто используемая функция:

HWND CreateWindowEx
(
  DWORD dwExStyle,
  LPCTSTR lpClassName,
  LPCTSTR lpWindowName,
  DWORD dwStyle,
  int x,
  int y,
  int nWidth,
  int nHeight,
  HWND hWndParent,
  HMENU hMenu,
  HINSTANCE hInstance,
  LPVOID lpParam
);

Это - 12 параметров (9, если Вы связываете x, y, w и h как прямоугольник) и существуют также параметры, полученные из имени класса также. Как Вы уменьшили бы это? Вы хотели бы сократить главное количество?

не позволяют количеству параметров побеспокоить Вас, просто удостоверьтесь, что это логично и хорошо зарегистрированное, и позвольте intellisense <глоток> * помогают Вам.

<глоток> * Другие помощники кодирования доступны!

В Чистый Код , Robert C. Martin посвятил четыре страницы предмету. Вот суть:

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

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

не делайте этого!

(Обычно).

Если Вы начинаете иметь необходимость мысленно отсчитать параметры в подписи и соответствовать им к вызову, то пора осуществить рефакторинг!

Большое спасибо за все Ваши ответы:

• было немного удивительно найти людей, которые также думают (как, я делаю), что 5 параметров являются хорошим пределом для исправности кода.

• Обычно люди склонны соглашаться, что предел между 3 и 4 является хорошим эмпирическим правилом. Это разумно, поскольку люди обычно переживают тяжелое время, считая больше чем 4 вещи.

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

• Некоторые люди полагают, что стандартная программа должна иметь столько аргументов, сколько она должна. Я соглашаюсь, но только для нескольких конкретных случаев (звонит в API ОС, стандартные программы, где оптимизация важна, и т.д.). Я предлагаю скрыть сложность этих стандартных программ путем добавления слоя абстракции чуть выше этих вызовов, когда это возможно.

• Nick имеет некоторые интересные мысли на этом. Если Вы не хотите читать его комментарии, я подвожу итог для Вас: короче говоря это зависит :

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

  мораль здесь, не боятся показа Вашего кода Вашим коллегам, обсуждают с ними и пробуют к , "определяют области, где у Вас есть низкое сцепление и плотное соединение" .

• Наконец, я думаю , wnoise очень соглашается с Nick и завершает его сатирический вклад с это поэтическое видение (см. комментарии ниже) искусства программирования:

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

Этот ответ принимает язык OO. Если Вы не используете один - пропускают этот ответ (это - не совсем агностический языком ответ, другими словами.

, Если Вы передаете больше чем приблизительно 3 параметра (особенно внутренние типы/объекты), не то, чтобы это - "Слишком многие", но что можно упускать шанс создать новый объект.

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

Тогда Вы осуществляете рефакторинг функциональность в свой новый объект, и Вы не верили бы, насколько это помогает и Вашему коду и Вашему пониманию программирования OO.

Кажется, что существуют другие соображения, чем простое число, вот некоторые, которые приходят на ум:

1. логическое отношение к основной цели функции по сравнению с одноразовыми настройками

2. , Если они - просто флаги среды, связывание может быть очень удобно

Одна из известных эпиграмм программирования Alan Perlis (рассказанный в Уведомлениях ACM SIGPLAN 17 (9), сентябрь 1982) указывает, "Если у Вас есть процедура с 10 параметрами, о вероятных пропавших без вести некоторых".

По словам Steve McConnell в Код, Завершенный , Вы должны

Предел количество параметров стандартной программы к приблизительно семи

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

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

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

void *
mmap(void *addr, size_t len, int prot, int flags, int fildes, off_t offset);

существует 6 аргументов, и каждые из них важны. Кроме того, нет никакой общей ссылки между ними для выравнивания по ширине связывания их. Возможно, Вы могли определить "структуру mmapargs", но это будет хуже.

Согласно Лучшие практики Perl , 3 хорошо, 4 слишком многие. Это - просто инструкция, но в нашем магазине это - то, чего мы пытаемся придерживаться.

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

Для меня это равно примерно 5, но я не настолько умный . Ваш пробег может отличаться.

Вы можете создать объект со свойствами для хранения параметров и передать их, если вы превысите установленный вами предел. См. Книгу Мартина Фаулера Refactoring и главу, посвященную упрощению вызовов методов.

В Худшие 5 фрагментов кода проверьте второй: «Это конструктор». У него более 37 ⋅ 4 ≈ 150 параметров:

Здесь программист написал этот конструктор [...] Некоторые из вас могут подумать, что да, это большой конструктор, но он использовал инструменты автоматической генерации кода eclipse [.] НЕТ, в В этом конструкторе я обнаружил крошечную ошибку, которая заставила меня сделать вывод, что этот конструктор был написан вручную. (кстати, это только верхняя часть конструктора, она не полная).

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

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

В случае установки флагов, отличный способ обработать эту ситуацию состоит в том, чтобы перечислить значения и ИЛИ их вместе.

IMO, выравнивание для длинного списка параметрического усилителя состоит в том, что данные или контекст являются динамичными по своей природе, думайте о printf (); хороший пример использования varargs. Лучший способ обработать такие случаи путем передачи потока или структуры XML, это снова минимизирует количество параметров.

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