Пространства имен
Пространства имен должны должны именоваться "ВерхнимКэмелКейсом".
Не могут содержать в названии никаких символов, кроме букв латинского алфавита.
Название класса должно быть существительным. Надо стараться избегать ненужных сокращений и аббревиатур.
Примеры:
namespace Bitrix\Main\Localization;
namespace Bitrix\Main\Entity\Validator;
Классы
Классы должны должны именоваться "ВерхнимКэмелКейсом".
Не могут содержать в названии никаких символов, кроме букв латинского алфавита.
Название класса должно быть существительным. Надо стараться избегать ненужных сокращений и аббревиатур.
Примеры:
class User;
class UserInformation;
Методы
Методы, в том числе методы класса, должны именоваться "нижнимКэмелКейсом".
Не могут содержать в названии никаких символов, кроме букв латинского алфавита.
Использование цифр допускается, если избежать иного не получается. Например: encodeBase64, getSha1Key.
Название метода должно начинаться с глагола.
Длина названия должна быть не менее 3-х символов.
Примеры:
run();
setImage();
getName();
Константы
Константы, в том числе константы класса, должны быть написаны в ВЕРХНЕМ_РЕГИСТРЕ_С_РАЗДЕЛИТЕЛЕМ_ПОДЧЕРКИВАНИЕМ.
Могут содержать буквы латинского алфавита, знак подчеркивания и числа (не в первой позиции).
Примеры:
DATE_TIME_FORMAT
LEVEL_7
Члены класса, параметры методов и переменные
Должны именоваться "нижнимКэмелКейсом".
Не должны содержать префиксов означающих членство в классе, принадлежность параметрам, тип и прочие бессодержательные вещи. Пример лишних префиксов: $this->mAge, function setName($pName), $arrArray.
Могут содержать буквы латинского алфавита и числа (не в первой позиции).
Примеры:
$firstName = '';
$counter = 0;
Общепринятые сокращения в названиях переменных и методов
Сокращения на первой позиции должны быть написаны маленькими буквами, на не первой позиции - должны начинаться с большой буквы, а все остальные - маленькие.
В именах классов - с большой, остальные маленькие.
Пример:
$xmlDocument
$mainXmlDocument
HttpParser
Сокращения, не являющиеся общепринятыми (в Битриксе), использовать нельзя.
То есть, $arResult уже не будет?
Хорошо подобранное имя переменной гораздо лучше говорит о ее содержимом, чем префикс.
Кроме того, многостраничный скрипт, не поделенный на функции и классы, - это плохо. Как правило. И надо стараться от этого избавляться. В коротких и простых методах, к параметрам которых применен контроль типов, префиксы особо не нужны для понимания логики работы с переменными.
В крайних случаях всегда можно применить подсказку phpDoc, которая к тому же хорошо воспринимается средствами разработки.
По крайней мере к таким выводам ведет наш опыт разработки. И мы не претендуем на абсолютную истину
А что нужно хорошо подбирать имена переменных, это понятно, но и они не всегда хорошо отражают их содержимое, например:
public function offsetSet($offset, $value)
public function getEntityByPrimary(\Bitrix\Main\Entity\Base $entity, $primary, $select)
- здесь нельзя сказать, что имена подобраны плохо, но в то же время не сразу понятно, где ожидается строка, где целое число, а где массив, нужно покопаться во внутренностях метода.
В общем, подсказка типа никому не мешала, правда не понятно, зачем от нее было отказываться.
Часть типов можно указывать в параметрах:
public static function checkFields(Result $result, $primary, array $data)
Часть типов указывается в phpDoc:
/**
* Checks data fields before saving to DB. Result stores in $result object
*
* @param Result $result
* @param mixed $primary
* @param array $data
* @throws \Exception
*/
IDE в принципе нормально ориентируются в типах. Поэтому мы решили, что префиксы только засоряют код.
Хотя в полях классов наверно все же и лишними будут они, да...
а так - пока догадаешься нормальное это поведение для переменной или нет...
phpDoc конечно круто, только народ иногда и пару строчек коммента вписать ленится, (а уж как долго документация обновляется это вообще ужс). Т.е. именование типа arXXX, bXXX, и т.п. вполне себе удобно.
ИМХО
Несколько раз подходил к NetBeans, но в итоге остался на Notepad++.
Причины:
- Та IDE не поддерживает исходников одного проекта в разных кодировках. Соответственно (форум для партнеров; да и мне они интересны, и я ядре тоже).
- Не увидел нормально работающей подсказки по существующим классам нового и старого ядра (пробовал в последний раз в марте 2013-го, тогда новые исходники уже были).
Перечисленные проблемы сводят на нет все усилия по настройке IDE.Видел несколько раз, что PHPStorm используется в недрах самого Битрикс. Он что решает все эти проблемы? А если нет, то зачем навязывать IDE?
$calendarEvent
либо написать
public function f(array $param)
либо подсказать
/** @var $param \MyCompany\Catalog\User */
Я про это:
'NAME' => array( 'data_type' => 'string', 'required' => true, 'title' => Loc::getMessage("culture_entity_name"), ),И такое сплошь и рядом. Жутко раздражает, правда.
Двойная кавычка - это совершенно другая форма записи строкового литерала в PHP. Обрабатывается такая строка по-другому. Кстати, дольше это должно быть. Т.е. где явно не нужны возможности "" лучше использовать ''.
Если миллисекундный выиграш по производительности и будет, то его никто не заметит, а вот разработчику приятнее и органичнее смотреть на двойные кавычки, даже на уровне психологии, одна кавычка чем-то похожа на знак восклицания и привлекает лишнее внимание там где это не нужно, а двойная расслабляет, мол, все нормально, это обычная строка.
Насчет указанного примера - да, это странность, которую надо лечить.
И ведь если поправить на одинарные, то Битрикс модулем Переводы все равно потрет эту работу и сделает двойные ...
например для файла /local/modules/my.test/lib/helloworld.php