Сколько параметров слишком много?

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

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

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

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

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

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

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

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

В конце концов, все сводится к личному вкусу.

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

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

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

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

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

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

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

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

Когда что-то считается настолько непристойным, что может регулироваться, несмотря на гарантию свободы слова Первой поправкой? По словам судьи Поттера Стюарта: «Я знаю это, когда вижу». То же самое и здесь.

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

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

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

В Чистый код Роберт К. Мартин посвятил этой теме четыре страницы. Вот суть:

The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification -- and then shouldn't be used anyway.

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

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

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

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

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

Пожалуйста, не делай этого!

(Как правило.)

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

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

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

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

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

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^* помочь вам.

^* Доступны и другие помощники по кодированию!

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

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

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

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

Кстати, если параметры в чем-то похожи, я бы поместил их в вектор или список, а не в структуру или класс.

Одна из хорошо известных программных эпиграмм Алана Перлиса (изложенная в ACM SIGPLAN Notices 17 (9), сентябрь 1982 г.) гласит: «Если у вас есть процедура с 10 параметрами, вы, вероятно, пропустили некоторые».

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

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

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

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

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

• Ник имеет несколько интересных мыслей на этом. Если вы не хотите читать его комментарии, я резюмирую для вас: в двух словах, По-разному:

  I hate making hard and fast rules like this because the answer changes not only depending on the size and scope of your project, but I think it changes even down to the module level. Depending on what your method is doing, or what the class is supposed to represent, it's quite possible that 2 arguments is too many and is a symptom of too much coupling.

  Мораль здесь - не бойтесь показывать свой код коллегам, обсуждать с ними и пытаться «определить области, где у вас низкая сплоченность и тесная связь».

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

  Programming is not engineering. Organization of code is an art because it depends on human factors, which depend too much on context for any hard rule.

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

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

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

По словам Джеффа Безоса, известного на Amazon, две пиццы можно накормить не более чем:

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

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

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

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

По словам Стива МакКоннелла в Код завершен, вам следует

Limit the number of a routine's parameters to about seven

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

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

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

Я согласен с цитатой Роберта Мартина из «Чистого кода» (как указано выше): чем меньше параметров, тем лучше. Сложно понять более 5-7 параметров и вызовов методов. Ситуация становится особенно плохой, если некоторые параметры являются необязательными (и поэтому принимают нулевые значения) или если все параметры имеют один и тот же тип (что еще больше затрудняет определение того, какой параметр является каким). Если вы можете объединить параметры в связанные объекты домена, такие как Customer и Account, с вашим кодом будет намного приятнее работать.

Есть крайний случай: если у вас есть вызов метода, который принимает переменное количество параметров которые образуют логический набор, меньше когнитивных издержек при большем количестве параметров. Например, вам может понадобиться метод, определяющий количество повторных попыток HTTP-запроса, выраженное в миллисекундах между повторными попытками. Три попытки с интервалом в 1, 2 и 3 секунды могут быть указаны как:

retries(1000, 2000, 3000)

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

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

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

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

Here a programmer wrote this constructor [... S]ome of you may think yes its a big constructor but he used eclipse automatic code generation tools[.] NOO, in this constructor there was a tiny bug that I discovered, which made me conclude that this constructor was written by hand. (by the way this is only the top part of the constructor, its not complete).

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

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

Семь вещей в краткосрочной памяти?

1. Название функции
2. Возвращаемое значение функции
3. Назначение функции
4. Параметр 1
5. Параметр 2
6. Параметр 3
7. Параметр 4

97 звучит примерно правильно.

Меньше - и вы теряете гибкость.