PHP5_nachinayushim

6

Создание высококачественного кода

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

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

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

В главе 5 было показано, как сделать обработку ошибок более изящной, более безо+ пасной и эффективной. В данной главе продолжается обсуждение темы создания каче+ ственного кода, описываются стандарты кодирования, а также использование функций, объектов и операторов include/require. Кроме того, в данной главе дан краткий об+ зор процессов разработки и оптимизации кода. Очевидно, что создание высококачест+ венного кода связано с большими трудозатратами, однако качественный код того стоит.

Создание высококачественного кода 265

Планирование разработки

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

Формальный процесс разработки программного обеспечения

Существует множество формальных процессов разработки программного обеспе+ чения, которые можно использовать; все они имеют определенные общие черты, такие как написание спецификации, разработка протоколов тестирования и т.д. Ком+ пания, разрабатывающая программное обеспечение для правительственных учреж+ дений, должна придерживаться процесса разработки программного обеспечения, определенного в таком стандарте, как ISO 12207 (ISO, International Standards Organi+ zation ++++++ Международная организация по стандартизации). Если же в компании ис+ пользуется менее формальный подход, например, так называемая ‘‘быстрая разработка приложений’’ (Rapid Application Development, RAD), несколько разработчиков несут общую ответственность за быстрое создание и модификацию работы приложения.

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

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

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

Написание спецификации

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

Какими должны быть спецификации для различных приложений? Рассмотрим не+ сколько аналогий с работой фотографов и кинематографистов.

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

266Глава 6

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

Реклама. Рекламные ролики стоят гораздо дороже, они делаются профессио+ нально и для них пишутся сценарии. Они во многом похожи на небольшие, но профессионально разработанные приложения для решения специфиче+ ских задач. В них не много импровизации, и достаточно просто предопределить (и обеспечить в ходе производства) все аспекты процесса, так чтобы финальный продукт очень близко соответствовал исходному сценарию и целям производства. Такие приложения как системы подготовки и e+mail+рассылки новостей похожи на рекламные ролики ++++++ они весьма просты в проектировании и структуре. Мож+ но еще до производства создать хорошую спецификацию и придерживаться ее без каких+либо значительных отклонений вплоть до завершения проекта.

Кинофильм. Кинофильм подобен очень сложному приложению, поскольку не+ смотря на продуманный от начала и до конца сценарий окончательное дейст+ вие может сильно отличаться от того, которое было запланировано первона+ чально. Это происходит потому, что окончательные решения принимаются после завершения съемки и зависят от реакции режиссера на то, что он видит на пленке. Это очень похоже на разработку сложного приложения, потому что часто разработчик не знает, что в созданном приложении хорошо, а что плохо (или не нужно), до тех пор, пока бета+тестеры или пользователи основательно не испытают приложение в работе. И как в случае любого дорогого проекта, чтобы сделать данное приложение правильно, может потребоваться множест+ во изменений (с точки зрения пользователя ‘‘сделать приложение правильно’’ может в итоге означать ‘‘заставить его работать’’).

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

Процесс написания кода

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

Создание высококачественного кода 267

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

Учитывая то, что существует множество инструментов, облегчающих быстрое соз+ дание рабочей модели приложения, не удивительно, что такие методики, как RAD и экстремальное программирование (Extreme Programming), столь популярны. Суще+ ствует несколько определений RAD, однако, по существу, эта методика предполагает быструю разработку пользовательского интерфейса, решающего необходимые зада+ чи, и демонстрацию этого интерфейса пользователям на ранней стадии цикла разра+ ботки. Это относительно недорогой процесс, и поскольку он многократно и быстро повторяется, разработчик за очень короткое время может отшлифовать дружествен+ ный по отношению к пользователю дизайн интерфейса. А как только появляется яс+ ное понимание всех аспектов, необходимых для удовлетворения основных целей приложения, можно приложить усилия к правильной организации, документирова+ нию и оптимизации приложения.

Экстремальное программирование подобно RAD, но, как правило, предполагает совместную работу двух программистов, которые попеременно пишут код и могут ассистировать друг другу, замещая друг друга в перерывах на обед (или после уволь+ нения одного из них), и, таким образом, ускоряя создание решения. ‘‘Одна голова хо+ рошо, а две лучше’’ ++++++ экстремальное программирование на практике часто доказыва+ ет это реальными результатами.

Тестирование, отладка и сопровождение

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

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

вприложение новые функции.

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

Оптимизация кода

Предположим, что существует 1000 Web+страниц, на каждой из которых необхо+ димо отображать текущую дату и соответствующее ей приветственное сообщение. С помощью PHP можно было бы значительно сократить работу по обновлению данных

268 Глава 6

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

К тому же необходимо найти способ написать код и в дальнейшем вставлять его во все страницы динамически, с тем чтобы в случае редактирования сообщения измене+ ния распространялись сразу на все страницы. Эта широко распространенная про+ блема легко решается различными способами с помощью таких PHP+функций, как include и require.

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

В оставшейся части главы основное внимание уделяется подробному описанию практических приемов, которые помогают сэкономить время, а также сделать код бо+ лее устойчивым. Эти приемы включают в себя формальные стандарты написания ко+ да, написание программной логики в виде функций, а также использование PHP+ функций require() и require_once().

Использование стандартов написания кода

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

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

В книге обсуждаются (и используются в примерах) соглашения PEAR (PHP Extension and Add+on Repository ++++++ репозиторий PHP+расширений и приложений). Написание ко+ да с соблюдением данных стандартов делает код готовым для включения в репозиторий. (Несколько соглашений относятся к файлам классов; объекты и классы более подробно описываются в последнем разделе данной главы, а также в главах 12 и 13, изучение ре+ позитория PEAR ++++++ тема главы 14). Рассмотрим основные PEAR+стандарты.

Отступы. Использовать четыре пробела, а не табуляцию. Некоторые текстовые редакторы позволяют настроить клавишу Tab так, чтобы она вместо символа та+ буляции вставляла четыре пробела. Подобные настройки могут значительно

Создание высококачественного кода 269

облегчить работу тем, кто привык использовать клавишу Tab для создания от+ ступов. Стандарт написания кода PEAR также рекомендует ограничивать длину строк 75++++85 символами, однако жесткого правила на этот счет нет.

Соглашения по именованию. В стандарте кодирования PEAR имеются согла+ шения по именованию классов, функций и переменных.

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

Функции и методы: начинайте имя функции со строчной буквы, а каждое последующее слово в многословном имени функции ++++++ с прописной буквы. Например, имя getData() хорошо подходит для метода, который получает данные, а имя calcTax() ++++++ для функции, вычисляющей сумму налога. (Кроме того, для разделения слов в именах функций и методов можно также использовать символы подчеркивания, хотя этот способ именования не яв+ ляется стандартным для PEAR: например, array_combine()).

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

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

Глобальные переменные: начинать имя глобальной переменной рекоменду+ ется с символа подчеркивания.

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

Формат вызовов функций. Согласно данному стандарту между именем функ+ ции и открывающей скобкой, а также между открывающей скобкой и первым аргументом не должно быть пробела. После каждой запятой, отделяющей аргу+ менты друг от друга, ставится один пробел:

$somevariable = myFunction($arg1, $arg2, $arg3);

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

Формат структур управляющей логики. Между началом оператора и услови+ ем следует использовать один пробел:

if (условие) { //другие операторы;

}

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

Комментарии. Для комментирования одиночных строк кода следует использо+ вать двойную косую черту (//):

//это комментарий

270 Глава 6

Чтобы закомментировать блок кода, рекомендуется использовать символы /* и */, например:

/*

несколько строк кода несколько строк кода несколько строк кода несколько строк кода

*/

Для записи внутренних комментариев для объектов классов следует использо+ вать стандарты PHPDoc.

Подключение кода. Подробности подключения файлов, содержащих код (или текстовое наполнение), с помощью функций include() или require() рассмат+ риваются далее в настоящей главе. Стандарт кодирования PEAR рекомендует ис+ пользовать функцию require_once() для безусловного подключения файлов классов, а функцию include_once ++++++ для условного подключения таких файлов.

Разделители. Используйте символы <?php в начале блока PHP+кода, а ?> ++++++

в конце.

Определения функций. При написании функций рекомендуется размещать имя функции и определение ее аргументов в одной строке, в следующей строке ста+ вится открывающая фигурная скобка, а после всего кода функции ставится за+ крывающая фигурная скобка. Это соглашение называется единственно правильной скобкой. Кроме того, в определении функции любые аргументы, имеющие стан+ дартные значения, следует размещать в конце перечня аргументов. Функции все+ гда следует программировать так, чтобы они возвращали выразительные значе+ ния (если они вообще должны возвращать какие+либо значения), например:

function myFunction($arg1, $arg2 = '')

{

if (условие верно) { какие-то операторы;

}

return true;

}

Примеры URL. В случае, когда требуется указать фиктивный URL (например, http://www.fake_url.com), используйте URL example.com, example.net и т.д., например: http://www.example.com.

Написание пользовательских функций в PHP

ВPHP имеется множество встроенных функций, таких как isset(), strlen() и т.д.

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

Любая создаваемая в PHP функция называется определенной пользователем (user*defined) или пользовательской функцией. Для того чтобы определить функцию, используется клю+ чевое слово function. Сразу после определения функция становится доступной в лю+ бой точке кода и ее можно вызывать по имени. А возможность подключать файлы с ко+ дом делает функции весьма мощным средством в арсенале программиста.

Создание высококачественного кода 271

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

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

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

Структурафункций

Функции представляют собой блоки кода, которые определяются пользователем для выполнения конкретных задач и имеют имя для обращения к ним. Известно, что функ+ ция может принимать входные значения, которые называются аргументами, выполнять определенные операции, а затем может возвращать другое значение (результат). Зна+ чения всех аргументов функция переносит в новые переменные, которые называ+ ются параметрами и обычно используются внутри самой функции. В примерах кода на страницах книги до сих пор очень часто использовались встроенные PHP+функции, предназначенные для разнообразных операций, например, для определения типа дан+ ных переменной (gettype()) или сортировки массивов (sort()). Написание пользо+ вательской функции предполагает назначение этой функции придуманного имени, од+ нако вызываются пользовательские функции так же, как и встроенные PHP+функции.

Рассмотрим поэтапно процесс работы с пользовательскими функциями.

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

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

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

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

вфункцию.

4.В функции может использоваться ключевое слово return, для того чтобы после завершения обработки данных функция передавала значение обратно вызывающему коду. Функции не обязательно должны возвращать значения; некоторые функции просто выполняют свою работу, а затем завершаются,

272 Глава 6

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

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

Определение и вызов функций

Создание функции начинается с написания ключевого слова function с после+ дующим пробелом и именем функции, по которому она будет вызываться. Если нужно, чтобы функция принимала какие+либо аргументы (это необязательно), то их необхо+ димо перечислить в круглых скобках после имени функции. Затем необходимо помес+ тить в фигурные скобки код, который выполняется при вызове функции. Код функ+ ции обрамляется фигурными скобками так же, как блоки кода в условных структурах. Ниже представлен синтаксис определения функции:

function functionname (parameters) { //код функции

}

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

function bonus($sales)
{
$bonus = $sales * 0.15;	return $bonus;
}

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

$my_total_sales = 120499;

//вычислить размер премии на основе общего объема продаж $my_bonus = bonus($my_total_sales);

В этом примере возвращается результат обработки входного значения (которое в данном случае записано в переменную $my_total_sales и равно 120 499), поэтому переменной $my_bonus в итоге будет присвоено возвращаемое функцией значение.

Функция может содержать любое количество строк кода, а каждая строка может вы+ полнять любую операцию в пределах возможностей PHP: подключаться к базе данных, открывать файл, проверять регулярное выражение и т.д. Кроме того, можно заставить функцию выводить на экран какой+либо текст с помощью операторов echo или print.

Сам по себе оператор return не отображает значение; он лишь передает резуль+ тат (если он есть) из функции. Процесс выполнения содержимого функции внутри PHP+сценария называется вызовом функции.

Функции можно непосредственно передавать число:

echo (bonus(120499));

или имя уже созданной переменной:

$total_sales=120499;

echo (bonus($total_sales));

Создание высококачественного кода 273

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

function bonus($total_sales, $bonus_factor)

{

$bonus = $total_sales * $bonus_factor; return $bonus;

}

Теперь, чтобы вызывать модифицированную функцию расчета премии, необхо+ димо передать ей два значения: total_sales и bonus_factor.

$total_sales = 120000; $bonus_factor = 0.15;

echo (bonus($total_sales, $bonus_factor));

Функции можно определять в любом месте PHP+программы. Обычно функции оп+ ределяют в отдельном файле и просто подключают его (с помощью функций include или require) в начале главного файла сценария. Определять или инициализировать переменные перед тем, как определяется функция, необязательно; однако необходимо убедиться, что они определены или проинициализированы перед вызовом функции.

Например, следующий код работает:

<?php

$total_sales = 190999; // здесь начинается выполнение

$bonus_factor = 0.15;

echo (bonus($total_sales, $bonus_factor)); // здесь функция вызывается function bonus($total_sales, $bonus_factor) // здесь функция определяется {

$bonus = $total_sales * $bonus_factor; return $bonus;

}

?>

Но и представленный ниже код работает также хорошо:

<?php

function bonus($total_sales, $bonus_factor) // здесь функция определяется { $bonus = $total_sales * $bonus_factor;

return $bonus;

}

$total_sales = 190999; // здесь начинается выполнение

$bonus_factor = 0.15;

echo (bonus($total_sales, $bonus_factor)); // здесь функция вызывается ?>

Необходимо сделать важное замечание о работе функций. Чтобы передавать значения в функцию, можно использовать любые имена переменных. Например, предположим, что вместо использования одних и тех же имен ($total_sales и $bonus_factor) как вне, так и внутри функции, используются имена $out_total_sales и $out_bonus_factor для переменных, существующих за пределами функции, а внутри функции использу+ ются имена $in_total_sales и $in_bonus_factor. Такой код работал бы, и выгля+ дел бы он следующим образом:

<?php

function bonus($in_total_sales, $in_bonus_factor) // здесь функция определяется { $bonus = $in_total_sales * $in_bonus_factor;

return $bonus;

}

$out_total_sales = 190999; // здесь начинается выполнение

$out_bonus_factor = 0.15;

echo (bonus($out_total_sales, $out_bonus_factor)); // здесь функция вызывается ?>