Аргументы функции — это переменные, от которых зависит исходный результат функции.
Функцию F = X+Y+Z нельзя сократить до F = X+Y. Вот так же и в программировании, есть случаи, в которых критически важных аргументов много.
Например, функция отправки емейла в PHP. Для отправки корректного (а не похожего на спам) письма надо использовать как минимум 5 аргументов: отправитель, получатель, тема, тело и дополнительные заголовки. 
Можно лично для себя все это инкапсулироть в маленькую функцию, добавляя заголовки автоматически, но в корне все равно будет та же функция.
Без 5 аргументов разработчикам PHP пришлось бы создать класс, геттеры и метод отправки. Или же некие другие системные функции для изменения заголовков, вставляемых в будущее письмо. В общем получилось бы неудобно и убого.
В данном случае функция с 5-6 аргументами - это как раз самое оптимальное решение в плане удобства и реализации.
И это только один пример.

Arantir, 
любое число аргументов можно объединить в структуру и передать одним аргументом

Arantir, для этого существуют структуры и классы. По хорошему, для отправки письма необходимо только три параметра: адрес, тема и текст письма. Все остальное необязательно или общее для всех отправляемых писем. Именно поэтому логичнее всего объединить все это в структуру или класс.

ZZZkoderZZZ, 
bsa, 
Заставлять компьютер создавать структуру на долю секунды при каждой отправке письма только ради того, чтобы это вам угодило, — не есть айс.

Не приводите частное к общему.
semdmail() в PHP — это функция, которая позволяет отправить корректный мейл на любом сервере, сайте, домене и при других переменных условиях. 
Я привел ее как пример той цели, которую она выполняет, а не как подспорье для обсуждения необязательных аргументов при отправке письма. Несомненно, для конкретного сайта или даже сервера заголовки будут настроены в угоду админу, документации, целевому получателю или звездам на небе... А для отправки регистрационного письма так и вовсе получателя и текста достаточно, остальное — константы.

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

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

какова разница в прочтении ручного заполнения структуры? что насчет числа параметров конструктора?

другое дело, что часто



исключения бывают. правило остается

Слишком много исключений получается =)
Существует такое выражение — "слепое следование правилам"...

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

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

Статья про оформление кода это мнение о best practices, а не свод догматов.

И вообще, тему числа параметров функции надо рассматривать в контексте конкретной задачи. А "правило трех" должно соседствовать и перекликаться с принципом "одна задача - одна функция (класс)".


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


а как же mysql vs mysqli?
впрочем php (до последней версии) громоздок для таких описаний. а вот что-то типа
представляется вполне изящным

А в чем собственно вопрос?

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

ZZZkoderZZZ, я вас разочарую OOP можно реализовать без классов

Добавлено через 43 секунды

нельзя

Добавлено через 5 минут и 31 секунду

чтобы мозги у писателей чаще включались

ZZZkoderZZZ, я тебя расстрою но, в ООПе главное не оказаться в ПОПе, если уж за это взялся. Все остальное решается чисто технически и еще, при помощи мозгов. 

Зачем все усложнять и перед каждым вызовом функции заполнять структуру? А если в числе параметров большие обьекты? Иж можно передать по const& в функцию и избежать копирования. А со структурой придется использовать указатели или написать конструктор(с тем же количеством параметров) и инициализировать константные ссылки. Так чем этот подход лучше простой передачи параметров в функцию? Так ведь и программисту будет легче понять что/где/как.

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

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

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

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

Согласен. При определённых условиях создавать отдельный обьект, только для того чтобы передать методу допустим 8 параметров, чего хорошего? Как такое облегчает лoгику программы, да и производительность тоже?

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