Comments 32
Собственно, почти окончательно определился со своим стилем написания кода. Осталось решить для себя, использовать "_" для private/protected, или нет. Видел много кода, профессионального, и не очень, и все пишут по-своему.
_ было актуально в php 4, когда закрытостью методов управляли при помощи условного соглашения имён. Сегодня этой проблемы нет, смысл сохранять привычку пропал, нужно бороть это в себе.
ps: предпочитаю при написании закрывать private/protected и по мере написания/необходимости открывать необходимые свойства/методы. В случае «открытия» вам придётся проходить весь код для удаления _
ps: предпочитаю при написании закрывать private/protected и по мере написания/необходимости открывать необходимые свойства/методы. В случае «открытия» вам придётся проходить весь код для удаления _
для protected\private свойств пишу $_
У меня такая аннотация:
$mPrivateVar
$ProtectedVar
$PublicVar
$arArgumentVar
$internalVar
publicMethod
ProtectedMethod
PublicMethod
Все открытые относительно класса пишутся с большой буквы, все внутренние с маленькой.
$mPrivateVar
$ProtectedVar
$PublicVar
$arArgumentVar
$internalVar
publicMethod
ProtectedMethod
PublicMethod
Все открытые относительно класса пишутся с большой буквы, все внутренние с маленькой.
publicMethod
имел ввиду: privateMethod
имел ввиду: privateMethod
Довольно редко вижу такий стиль именования. Видимо, до PHP вы писали на чем-то кардинально отличающемся :) У меня так:
ПП: $GLOBAL_VAR; $my_var; my_function();
ООП: $publicVar; $_privateVar; $_protectedVar; publicMethod(); _privateMethod(); _protectedMethod();
ПП: $GLOBAL_VAR; $my_var; my_function();
ООП: $publicVar; $_privateVar; $_protectedVar; publicMethod(); _privateMethod(); _protectedMethod();
Это не стиль, это — ппц.
вери сори, из песни слов не выкинешь.
вери сори, из песни слов не выкинешь.
Афигеть заминусовали )))
Парни и тролли. Я еще хуже чем вы думаете. Я юзаю Microsoft like (С#) оформление кода )))
Парни и тролли. Я еще хуже чем вы думаете. Я юзаю Microsoft like (С#) оформление кода )))
IDE, обычно, само подсказывает какие методы доступны, а какие нет, с нижним подчеркивание или без я не увижу свойство если оно мне не доступно.
А если свойство доступно, то зачем мне нижнее подчеркивание?
Мне кажется это было более востребовано во времена PHP4 и var.
А если свойство доступно, то зачем мне нижнее подчеркивание?
Мне кажется это было более востребовано во времена PHP4 и var.
Программируют не только автокомплитом. Когда смотришь на класс, такой стиль помогает быстро разобраться, что к чему.
Т.е. $_ помогает, а protected $ не помогает?
Чтобы понять что свойство защищенное (при выборе protected $var вместо protected $_var) необходимо будет идти к месту его объявления (это если без IDE).
А в IDE приёдется сделать дополнительные телодвижения, чтобы посмотреть аннотацию (Ctrl+B и т.п.). Для чтения, имхо, лучше $this->_var, так сразу видно.
А в IDE приёдется сделать дополнительные телодвижения, чтобы посмотреть аннотацию (Ctrl+B и т.п.). Для чтения, имхо, лучше $this->_var, так сразу видно.
Помогает protected $_
А особенно помогают разобраться, когда в видишь код вроде:
$this->post = Post::find($this->_post);
$this->post = Post::find($this->_post);
Ужасно не люблю лапшу с подчёркиваниями вроде
Так что myVar, myFunction.
static int __init vga_arb_device_init.Так что myVar, myFunction.
Если не ошибаюсь, стиль именования protected-методов и атрибутов с ведущего подчеркивания пошел из Zend Framework. Хотя на страничке с их coding standard таких указаний я не нашел, странно.
«Для переменных — членов классов, определенных с помощью префиксов области видимости „private“ или „protected“, первый символ имени должен быть символом нижнего подчеркивания. Это единственное допустимое использование символа нижнего подчеркивания в имени. Переменные — члены классов определенные с помощью префикса области видимости „public“ никогда не должны начинаться с символа нижнего подчеркивания.»
framework.zend.com/manual/ru/coding-standard.naming-conventions.html
Раздел «Переменные».
Надо еще помнить, что объявлять свойства типа public считается плохим тоном. Для доступа к свойствам применяются геттеры и сеттеры.
framework.zend.com/manual/ru/coding-standard.naming-conventions.html
Раздел «Переменные».
Надо еще помнить, что объявлять свойства типа public считается плохим тоном. Для доступа к свойствам применяются геттеры и сеттеры.
Вот, собственно, из последнего абзаца вытекает, что в хорошем коде практически все свойства класса должны быть инкапсулированы, соответственно будут иметь "_" в имени. И это уже получается — глупость. С методами немного по-другому, всегда есть и public- и protected-методы, тут "_" не так бесполезен, как в случае со свойствами. Но считаю правильным следовать единому стилю. После размышлений решил все-таки отказаться от "_" в PHP.
Тогда Вам, вероятно, придется поменять свой стиль кодирования, когда перестанете программировать в одну каску, а присоединитесь к группе профессиональных разработчиков (не важно, в офисе или opensource проекте). Как показывает практика, зрелые разработчики все-таки придерживаются стандартов. Ибо не следование стандартам — путь к хаосу.
«Хороший стандарт кодирования важен в любом проекте, и особенно там, где множество разработчиков работают над одним проектом. Наличие стандарта кодирования помогает гарантировать, что код — высокого качества, с меньшим количеством ошибок и легко поддерживается.»
framework.zend.com/manual/ru/coding-standard.overview.html
Стараюсь придерживаться этого стиля, ибо он очень адекватен и помогает лучше читать код. Автоформатер в PHPStorm также у меня настроен под этот стиль. Следование любому стандарту помогает лучше собрать мысли в голове и сосредоточиться на главном.
framework.zend.com/manual/ru/coding-standard.overview.html
Стараюсь придерживаться этого стиля, ибо он очень адекватен и помогает лучше читать код. Автоформатер в PHPStorm также у меня настроен под этот стиль. Следование любому стандарту помогает лучше собрать мысли в голове и сосредоточиться на главном.
Я честно охренел, когда увидел результат!
Это ж почти половина людей не юзает это «джентельменское соглашение», и я считаю что это плохо!
Перед тем как придумывать свои конвеншены посмотрите существующие.
Пожалуй самый популярный стандарт это pear.php.net/manual/ru/standards.php, в котором это соглашение поддерживается. Как Вы думаете почему? Потому что pear это хранилище библиотек(расширений, приложений и тд).
Если Вы решили использовать библиотеку, как можно понять по коду где api, которое предоставляет библиотека, а где ее внутренняя реализация. Самый простой вариант это посмотреть, что начинается с подчеркивания, а что нет.
Именно поэтому стоит использовать это «джентельменское соглашение» и именовать закрытые(protected тоже закрытый) члены и методы классов с нижнего подчеркивания. Более того, нередко в силу определенных обстоятельств появляются открыте методы или члены, которые являются частью внутренней реализации библиотеки и их именуют с нижнего подчеркивания.
Ключевые слова: это языковая конструкция, более низкий уровень абстракции, который не должен решать задачи, описанные мной выше.
Это ж почти половина людей не юзает это «джентельменское соглашение», и я считаю что это плохо!
Перед тем как придумывать свои конвеншены посмотрите существующие.
Пожалуй самый популярный стандарт это pear.php.net/manual/ru/standards.php, в котором это соглашение поддерживается. Как Вы думаете почему? Потому что pear это хранилище библиотек(расширений, приложений и тд).
Если Вы решили использовать библиотеку, как можно понять по коду где api, которое предоставляет библиотека, а где ее внутренняя реализация. Самый простой вариант это посмотреть, что начинается с подчеркивания, а что нет.
Именно поэтому стоит использовать это «джентельменское соглашение» и именовать закрытые(protected тоже закрытый) члены и методы классов с нижнего подчеркивания. Более того, нередко в силу определенных обстоятельств появляются открыте методы или члены, которые являются частью внутренней реализации библиотеки и их именуют с нижнего подчеркивания.
Ключевые слова: это языковая конструкция, более низкий уровень абстракции, который не должен решать задачи, описанные мной выше.
Да вы что, PEAR это такой дедушка-ветеран больной радикулитом, вечно краяхтящий и ноющий. В PEAR ещё слишком много библиотек с PHP4. На дворе уже 5.4, а им нужно поддерживать свой стандарт, для соблюдения стиля, который давно должен был бы стать deprecated.
С тех пор как в PHP появился полноценный ООП, все эти _ стали просто неуместными.
Ну опять таки, это не помогает, а только мешает коду. Например, очень хорошо получается, если в классе есть два свойства, одно: $this->_property, а другое $this->property…
Другой пример. Набираешь в IDE $this->property, не находишь свойства, ругаешься, лезешь в исходники и находишь, что оно на самом деле _property. Ну и зачем такие подставы делать?
Третее. Любое изменение публичности доступа ведет то ли к рефакторингу то ли к mass-replace.
А в четвертых: зачем?
С тех пор как в PHP появился полноценный ООП, все эти _ стали просто неуместными.
Ну опять таки, это не помогает, а только мешает коду. Например, очень хорошо получается, если в классе есть два свойства, одно: $this->_property, а другое $this->property…
Другой пример. Набираешь в IDE $this->property, не находишь свойства, ругаешься, лезешь в исходники и находишь, что оно на самом деле _property. Ну и зачем такие подставы делать?
Третее. Любое изменение публичности доступа ведет то ли к рефакторингу то ли к mass-replace.
А в четвертых: зачем?
Я использую подчёркивание по нескольким причинам, одна из которых очень примитивна, но потрясающе удобна — это сортировка методов и свойств в IDE.
Т.е. просто отсортировав всё по алфавиту, я сразу же вижу все защищённые свойства/методы и все публичные.
> Ну опять таки, это не помогает, а только мешает коду.
Не ощутил этого (:
> Например, очень хорошо получается, если в классе есть два свойства, одно: $this->_property, а другое $this->property
Мммм… Это говорит о не корректном именовании, либо проектировании, т.к. по идее зачем в классе два одноимённых свойства?
И если всё-таки они есть, то я предпочитаю не ломать голову, решая какое из них защищённое.
>Набираешь в IDE $this->property, не находишь свойства, ругаешься, лезешь в исходники и находишь, что оно на самом деле _property. Ну и зачем такие подставы делать?
Аналогично: набираешь $this->_property, не находишь свойства, ругаешься, лезешь в исходники и находишь, что оно на самом деле property. Ну и зачем такие подставы делать?
> Третее. Любое изменение публичности доступа ведет то ли к рефакторингу то ли к mass-replace.
Далее, вот тут говорят, что мол «если внезапно потребуется открыть все свойства» (подразумевая и все классы).
Я извиняюсь, но что это за случаи такие? За весь свой опыт программирования на РНР (8 лет) ни разу с таким не сталкивался.
Если требуется открыть какое-то свойство, то вам всё равно придётся менять private/protected на public, и один символ тут погоды не делает.
А если вы (обращаюсь не только к Davert) постоянно меняете уровень доступа методов и свойств, то, прошу прощения, но это говорит о кривой архитектуре и отсутствии проектирования (или очень плохой его реализации).
> А в четвертых: зачем?
Мне нравится держать котлеты и мух отдельно, а не мешать всё в одну кучу.
Т.е. просто отсортировав всё по алфавиту, я сразу же вижу все защищённые свойства/методы и все публичные.
> Ну опять таки, это не помогает, а только мешает коду.
Не ощутил этого (:
> Например, очень хорошо получается, если в классе есть два свойства, одно: $this->_property, а другое $this->property
Мммм… Это говорит о не корректном именовании, либо проектировании, т.к. по идее зачем в классе два одноимённых свойства?
И если всё-таки они есть, то я предпочитаю не ломать голову, решая какое из них защищённое.
>Набираешь в IDE $this->property, не находишь свойства, ругаешься, лезешь в исходники и находишь, что оно на самом деле _property. Ну и зачем такие подставы делать?
Аналогично: набираешь $this->_property, не находишь свойства, ругаешься, лезешь в исходники и находишь, что оно на самом деле property. Ну и зачем такие подставы делать?
> Третее. Любое изменение публичности доступа ведет то ли к рефакторингу то ли к mass-replace.
Далее, вот тут говорят, что мол «если внезапно потребуется открыть все свойства» (подразумевая и все классы).
Я извиняюсь, но что это за случаи такие? За весь свой опыт программирования на РНР (8 лет) ни разу с таким не сталкивался.
Если требуется открыть какое-то свойство, то вам всё равно придётся менять private/protected на public, и один символ тут погоды не делает.
А если вы (обращаюсь не только к Davert) постоянно меняете уровень доступа методов и свойств, то, прошу прощения, но это говорит о кривой архитектуре и отсутствии проектирования (или очень плохой его реализации).
> А в четвертых: зачем?
Мне нравится держать котлеты и мух отдельно, а не мешать всё в одну кучу.
Я с ним не соглашался :) А если серьезно, то не понимаю необходимость "_" для определения видимости. Если меня интересует API класса — я буду смотреть public свойства и методы. Если меня интересует его внутренняя логика, то в подавляющем большинстве случаев от того private метод или public ничего не зависит.
А вот как раз для служебных публичных свойств и методов (например чтобы реализовать отношения типа friend или для тестирования), я буду использовать "_", сигнализирующее мне, что использовать их надо с очень большой осторожностью, они не являются частью API.
А вот как раз для служебных публичных свойств и методов (например чтобы реализовать отношения типа friend или для тестирования), я буду использовать "_", сигнализирующее мне, что использовать их надо с очень большой осторожностью, они не являются частью API.
Там это правило работает ввиду архаичности самого PEAR.
Ну да, каждый считает своим долгом форматировать код так как ему нравится и ведь его не переубедишь!
Вот за это люблю python!
Вот за это люблю python!
А где вариант «не использую protected»? :-)
Слабаки! Правильно писать так:
Чтоб уж наверняка никто не ошибся.
private function __privateFoo(){...}
public static function publicStaticBar(){...}
Чтоб уж наверняка никто не ошибся.
Sign up to leave a comment.
Используете ли Вы первый символ подчеркивания для именования private/protected свойств/методов?