Удачные имена методов – в копилку php-программиста

В книге С.Макконнелла “Совершенный код” (позже мы хотим написать о ней подробно) приведены интересные рекомендации по именованиям методов, функций и процедур.

Вот некоторые наиболее полезные советы в нашей адаптации терминологии к PHP (а к чему же еще).

Описывайте в названии ВСЕ действия, которые выполняет метод. К примеру, если метод создает отчет о покупках в электронном магазине за день и отправляет его по email владельцам сайта, то он не должен называться просто createDailyReport(), а должен называться createDailyReportAndSendItByEmail(). Не нравится такое длинное и несуразное название? Вывод – нужно создавать красивые методы, выполняющие только одну задачу и не имеющие побочных действий. Таким образом, когда метод получает дикое название – подумайте о его переделке.

Не ограничивайте длину названия метода искусственно. Известно, что оптимальная длина названия переменной – 7-9 символов. Но кто сказал, что и названия методов должны быть такой же длины? Ведь методы гораздо сложнее переменных. Помните – главная задача имени метода – как можно более ясное описание сути метода, а потому длина имени вообще не должна иметь значения. И возможности автоподстановки IDE вам в помощь.

При именовании функции – используйте описание возвращаемого значения.

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

И еще. На последней московской конференции по PHP организаторами был разыгран приз. Победить должен был тот участник, кто привел бы пример самого плохого подхода к программированию на php, с которым он когда-либо сталкивался в своей практике. Было озвучено много уморительных “ляпов”. Однако уверен, что Макконнелл бы выиграл этот приз, если бы привел тот пример, который я вычитал у него в книге. Пример касается подхода к организации кода в методы. Приведем его дословно.

“Один разработчик написал весь свой код в форме единственного объемного метода. Затем он разбил код на фрагменты по 15 строк и создал методы Part1, Part2 и т.д. После этого он создал один высокоуровневый метод, вызывающий каждую часть кода. Подобный способ создания и именования методов глуп до невозможности.”

Итак, нет предела совершенству. Но, похоже, предел несовершенства в программировании найден!