Имена методов и функций

Еще можно дополнить про is/has/was/have в методах, которые возвращают булевское значение (истину или ложь).
Примеры: hasChildren(), isPrime() и т.д.

Статья про программирование? Такое ощущение, что пришёл на IT-ресурс.

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

Когда я начал изучать PHP, мне было непривычно отсутствие точечной нотации.
Думаю, что с введением namespaces ситуация начнет меняться, и базовые функции будут приводиться к единому виду.
Хотя, все сразу все равно не сделяют, потому что это равносильно созданию нового языка.

думал предложите решение для преодоления данной неприятной особенности php, a так за пыху стало ещё обиднее…
жаль что разработчики не продумали это :(

"
Неочевидность аргументов и их порядка в функциях. Например, искомая строка идет в функции str_replace на последнем месте, а в функции strpos. Если бы искомая строка, например, всегда занимала первую позицию — было бы более удобно.
"

4 раза перечитал…

Спасибо за очень полезную статью. Для себя отменил некоторые моменты.

groups.remove({ name: name }).remove({ status: 'deleted' }).remove( function( item ){ return item.cost > 53 } )

cars.get({ month: 'april', year: '2008' })

$string( 'blahblah' ).split( 'foo' ).join( 'bar' ).spit( 5 ).trim( /[\s,]+/ ).$

методы возвращающие булины — это предикаты

Частичный пересказ Java Coding Standards в вольной форме? Хм. ;_)

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

Не уверен в этом пункте, как вы. Современные IDE, тот же Zend Studio, говорит в каком порядке и какие аргументы у функции (при достаточном комментировании конечно же). Для стандартных функций это тем более доступно. Поэтому вопрос: зачем засорять имя функции такой информацией?

Очень правильным мне кажется решение проблемы названия функций в Objective-C, где сигнатура метода выглядит подобным образом:
— (id)initWithTitle:(NSString *)title style:(UIBarButtonItemStyle)style target:(id)target action:(SEL)action

То есть при использовании:
[[UIBarButtonItem alloc] initWithTitle:@«GetAll» style:UIBarButtonItemStyleBordered target:self action:@selector(downloadAll)];

мы сразу видим какой аргумент что обозначает.

Интересно было бы использовать в PHP концепцию селекторов, как в jQuery. Попытка такое реализовать есть в atomikframework.com.
Кто-нибудь подобные решения знает?

Интересно было бы использовать в PHP концепцию селекторов, как в jQuery. Попытка такое реализовать есть в atomikframework.com.
Кто-нибудь подобные решения знает?

Интересно было бы использовать в PHP концепцию селекторов, как в jQuery. Попытка такое реализовать есть в atomikframework.com.
Кто-нибудь подобные решения знает?

Интересно было бы использовать в PHP концепцию селекторов, как в jQuery. Попытка такое реализовать есть в atomikframework.com.
Кто-нибудь подобные решения знает?

Я не хочу кидать очередной камень в огород автора, но есть такой вопрос, точней комментарий. Он относится ко многим авторам статей.

Почему нельзя избавиться от мании предупреждать, что статья может быть «паршивой»? Если автор сомневается в своих знаниях, то не вижу смысла существования статьи вообще, а если боится комментариев и критиков, то последнее надо воспринимать адекватно и с чувством достоинства (ну и юмора). Статья на то и статья, чтобы научить чему-нибудь, качественно передать проанализированную информацию читателю.

А книжка Стива Макконнелла обязательна к прочтению каждому себя уважающему программисту, менеджеру и т, д.

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

>>Нам нужна замена подстроки в строке. Самым очевидным вариантом будет такой: string.replace(from, to).

from-to — это очевидно? o_O
имхо, имена $needle, $search и $replace яснее выражают смысл, хотя needle и search здесь, в сущности, одно и то же. from может обозначать источник, например, при копировании.

>>Например, искомая строка в функции str_replace идет на последнем месте, а в функции strpos — на первом (str_replace($search, $replace, $subject[, $&count]) vs strpos($haystack, $needle[, $offset])).

По-моему, искомая строка в функции str_replace идёт как раз на первом месте, а в функции strpos — на втором, но это не важно, так как в общем вы правы.

Отличный комикс в тему

www.geekherocomic.com/2008/11/12/real-programmers-dont-write-documentation/

чего только одна функция mktime в php стоит, со своим необычным чередованием аргументов… порядок которых [цензура] запомнишь…

Не понравилась манера написания… переборщили с «ага».

Немного не согласен с автором, функции (и методы, как современные потомки оных), должны указывать действие, которое они производят, и тип данных (имеется ввиду не тип ЯП, а-ля integer/string/float, а в общем), а уже какие аргументы они принимают — это доп.информация, в приведенном примере cars.getByMonthAndYear(month, year) совершенно непонятно что должен вернуть метод, объект cars? Но раз из него вызывается метод — он уже существует. Он не возвращает ничего, а воздействует на себя? Тогда он должен называться не get, а что-то вроде init.
Почему указание типа возвращаемых данных важнее указание параметров? Потому что при последующем чтении кода можно будет отследить логическую цепочку операций над данными

$result = $object->getByDateAndTime($date, $time);
$someobject->someaction($result);

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

$result = $object->getDateObject($date, $time);
$someobject->someaction($result);

А в данном случае из названия метода мы видим какие данных были получены в переменную $result, и соот-но можем понять какие данных были отправлены в последствии в метод someaction();

У Макконелла главная мысль при именовании методов и переменных состоит в том, что если у вас есть методы вроде: «getEvensItemByIdAndSortThemByDateBeforeCallThisMethodCallDBPrepare», то не стоит их переименовывать, стоит их переписать.

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

Хотя это уже немного другой случай, и тут не какие правила именования не помогут…

и?
java convention
google code convention
В любой серьезной конторе, где бы вы ни работали, пользуются какими либо понятными и удобными правилами…
… можетм опять это камень в сторону… сами знаете когО?)

Вы предлагает выносить в имя метода все параметры, аргументируя это тем, что сложно запомнить порядок и назначение аргуменов.
Но что это нам дает? Ведь теперь просто нужно помнить другие вещи — имя метода

Например:

getByMonthAndYear

а не

getByYearAndMonth

Так что, имхо, проблему это не решает (да и проблема ли это). Такой подход делает имена методов более громоздкими (что с IntelliSense не проблема) и не несущими дополнительной полезной информации в своем имени (что плохо).

> Имена некоторых функций неочевидно передают назначение. Например, basename.

basename — это часть Open Group Base Specifications для Unix-команд, и она там достаточно давно.
То же самое и с touch, chmod, chown и прочими именами, «неочевидно передающими значение».

Скажите, а что за шрифт на скриншоте с кодом?..

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

Мне кажется зашивать информацию об аргументах в имя метода будет лишним.
Главное сами аргументы грамотно назвать.
Factory::getCar($year, $month)
Factory::getCar(DateTime $date)
Factory::getCar(Color $color, Model $model)

вместо
getCarByYearAndMonth
getCarByDate
getCarByColorAndModel

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

PHPDoc и IDE редакторы вам помогут :) И само описываемый код МИФ

Что-то я не согласен. PHP не знаю, поэтому могу ошибаться. Как уже сказали basename — стандартная команда и с ней (и наверное многими другими) проблем нет. Читать имена типа AVeryFuckingLongButSurelyDamnDescriptiveItentifierPSIDontReallyLikeCamelCase конечно прикольно, но писать без подсказок со стороны IDE довольно грустно, а с подсказками лучше сразу аргументы видеть.

Незнаю как вы, а я привык чтобы имя функции отражало то ЧТО ОНА ДЕЛАЕТ а не то С КАКИМИ ПАРАМЕТРАМИ она работает. Причем это не только мое ИМХО.

Или вы собрались переписывать стандарты? :)

Да, в PHP это проблема, действительно, но изначальная задумка очень даже хороша.

в str_replace, кстати правильная последовательность. Объясняю. Вы заметили название аргументов $needle, $haystack? Это всем известная поговорка: „Искать иголку (needle) в стоге (haystack) сена“. Так расположены параметры во многих функциях массивов, (например, array_search).

Распологали бы везде в таком порядке: „ЧТО ГДЕ КОГДА и при каких ОБСТОЯТЕЛЬСТВАХ“, то не было бы никаких путаниц вобще.

такую последовательность я использую всегда в своём коде.

Пример нормальной архитектуры/именования:

Book.all(:created_on => (last_income_at..Time.today), :cost.gt => 500).destroy!

Может быть это болезнь С, но все же там в пределах одной библиотеки нет таких разнобоев.

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

Ситуацию спасает правильный выбор языка: есть C# 3.0 со всеми функциональными плюшками и LINQ'ом; есть Boo:
rjCustomers = [customer.Name for customer in customers if customer.State == "RJ"]
есть, в конце концов, LISP (см. Десятое правила Гринспуна).

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

Мне вот не сама статья понравилась, а комментарии. Автору можно даже сделать уже опрос на тему — «а какой метод в данном случае предпочтете Вы?» +1

Пошел заказывать книгу «Совершенный Код»

Честно говоря никогда не читал статьей на тему оформления, но как начал изучать MVC и тд и тп, само собой как то прибилось. Спасибо за статью, побольше теории!

Автору статьи несомненно понравится система именования функций, принятая в OpenGL :-)

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

www.rsdn.ru/article/opengl/ogltut2.xml#EBF

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

Что до меня — мне больше нравится, как это сделано в C++

1. Нам нужна замена подстроки в строке. Самым очевидным вариантом будет такой: string.replace(from, to). Жаль, что в PHP он не осуществим.

Ну, во-первых, «неосуществим» пишется слитно. А во-вторых, очень даже осуществим:

<?php
class Str
{
  public $value;

  public function __construct($value)
  {
    $this->value = $value;
  }

  public static function create($value)
  {
    return new self($value);
  }

  public function __toString()
  {
    return '' . $this->value;
  }

  public function replace($what, $with)
  {
    return self::create(str_replace($what, $with, $this->value));
  }
}

function S($value)
{
  return new Str($value);
}

$source = '1234567890';

$result1 = Str::create($source)->replace('456', 'xxx');

$result2 = S($source)->replace('89', 'ZZ');

echo "<pre>\n";
echo "source: '$source'\n";
echo "result1: '$result1'\n";
echo "result2: '$result2'\n";
echo "</pre>\n";
?>

Результат:

source: '1234567890'
result1: '123xxx7890'
result2: '1234567ZZ0'