Я использую подчёркивание по нескольким причинам, одна из которых очень примитивна, но потрясающе удобна — это сортировка методов и свойств в IDE.
Т.е. просто отсортировав всё по алфавиту, я сразу же вижу все защищённые свойства/методы и все публичные.
> Ну опять таки, это не помогает, а только мешает коду.
Не ощутил этого (:
> Например, очень хорошо получается, если в классе есть два свойства, одно: $this->_property, а другое $this->property
Мммм… Это говорит о не корректном именовании, либо проектировании, т.к. по идее зачем в классе два одноимённых свойства?
И если всё-таки они есть, то я предпочитаю не ломать голову, решая какое из них защищённое.
>Набираешь в IDE $this->property, не находишь свойства, ругаешься, лезешь в исходники и находишь, что оно на самом деле _property. Ну и зачем такие подставы делать?
Аналогично: набираешь $this->_property, не находишь свойства, ругаешься, лезешь в исходники и находишь, что оно на самом деле property. Ну и зачем такие подставы делать?
> Третее. Любое изменение публичности доступа ведет то ли к рефакторингу то ли к mass-replace.
Далее, вот тут говорят, что мол «если внезапно потребуется открыть все свойства» (подразумевая и все классы).
Я извиняюсь, но что это за случаи такие? За весь свой опыт программирования на РНР (8 лет) ни разу с таким не сталкивался.
Если требуется открыть какое-то свойство, то вам всё равно придётся менять private/protected на public, и один символ тут погоды не делает.
А если вы (обращаюсь не только к Davert) постоянно меняете уровень доступа методов и свойств, то, прошу прощения, но это говорит о кривой архитектуре и отсутствии проектирования (или очень плохой его реализации).
> А в четвертых: зачем?
Мне нравится держать котлеты и мух отдельно, а не мешать всё в одну кучу.
В контексте языков программирования, можно решить определённые части, компоненты холивара.
Т.е. ответить точно, что, скажем, один язык выполняет определённые операции на порядок шустрее (сорри за примитивный пример).
В данной же инфографике, берём простоту изучения.
Видим чисто субъективное мнение, практически ничем не подкреплённое.
И так почти по всем именно холиварным вопросам.
1. Откровенно удивило утверждение, что python рекомендуется новичкам.
Честно, ни разу не встречал такого. Не имею ничего против python, но всё-таки чаще, если речь о web, слышу рекомендации в сторону рнр.
2. +1 к непонятно как юзабилити оценивали.
p.s.
И сдаётся мне, что эта инфографика ну никак не решает вопрос холиваров этих языков.
Надо понимать, что само по себе ревью кода не делает код лучше (разве что учёт чужих «фишек») — для его эффективности нужен постоянный контроль со стороны тимлида. Сталкивался с такой ситуацией, когда ревью проводилось, ошибки, недочёты и советы были указаны, но код не исправлялся (это я в контексте ревью, при котором код не исправляется просматривающим, а только добавляются соотв. комментарии в код).
Ещё мысли лезут в сторону кросс-ревью — в этом случае, полагаю, надёжность повышается ещё на порядок.
Спасибо, с удовольствием и интересом прочитал статью. Очень понравилась последовательность и структурность.
Теперь по теме, но прежде капля о себе:
Я закончил технический вуз, специалист.
Во многом с Вами соглашусь, особенно теперь, когда мне периодически необходимо выступать в роли преподавателя. К слову, это действительно безумно увлекательно — строить процесс обучения, передавать свой опыт.
Однако, в нескольких аспектах не совсем разделяю Вашу точку зрения.
Как например, что «проектировщикам интерфейсов» высшее образование не нужно.
Нужно и даже очень. Иначе приходят «специалисты», которым приходится объяснять чуть ли не что такое функция и как в неё передать параметры.
Высшее образование даёт фундамент, площадку, на которой уже можно развернуться, подготовиться к дальнейшим действиям.
Без вузовского образования знания, как правило, носят стихийный характер, в результате чего, зачастую, приходится тратить немало времени на то, чтобы объяснить такому человеку, почему нужно сделать так, а не по-другому.
В качестве заключения:
ещё раз спасибо за статью, надеюсь увидеть их ещё от Вас по данной теме.
Т.е. просто отсортировав всё по алфавиту, я сразу же вижу все защищённые свойства/методы и все публичные.
> Ну опять таки, это не помогает, а только мешает коду.
Не ощутил этого (:
> Например, очень хорошо получается, если в классе есть два свойства, одно: $this->_property, а другое $this->property
Мммм… Это говорит о не корректном именовании, либо проектировании, т.к. по идее зачем в классе два одноимённых свойства?
И если всё-таки они есть, то я предпочитаю не ломать голову, решая какое из них защищённое.
>Набираешь в IDE $this->property, не находишь свойства, ругаешься, лезешь в исходники и находишь, что оно на самом деле _property. Ну и зачем такие подставы делать?
Аналогично: набираешь $this->_property, не находишь свойства, ругаешься, лезешь в исходники и находишь, что оно на самом деле property. Ну и зачем такие подставы делать?
> Третее. Любое изменение публичности доступа ведет то ли к рефакторингу то ли к mass-replace.
Далее, вот тут говорят, что мол «если внезапно потребуется открыть все свойства» (подразумевая и все классы).
Я извиняюсь, но что это за случаи такие? За весь свой опыт программирования на РНР (8 лет) ни разу с таким не сталкивался.
Если требуется открыть какое-то свойство, то вам всё равно придётся менять private/protected на public, и один символ тут погоды не делает.
А если вы (обращаюсь не только к Davert) постоянно меняете уровень доступа методов и свойств, то, прошу прощения, но это говорит о кривой архитектуре и отсутствии проектирования (или очень плохой его реализации).
> А в четвертых: зачем?
Мне нравится держать котлеты и мух отдельно, а не мешать всё в одну кучу.
В контексте языков программирования, можно решить определённые части, компоненты холивара.
Т.е. ответить точно, что, скажем, один язык выполняет определённые операции на порядок шустрее (сорри за примитивный пример).
В данной же инфографике, берём простоту изучения.
Видим чисто субъективное мнение, практически ничем не подкреплённое.
И так почти по всем именно холиварным вопросам.
Я имел в виду это.
p.s. Неужели я уже настолько стар, что в памяти для начала изучения программирования остались лишь рекомендации паскаля, си и бейсика…
Честно, ни разу не встречал такого. Не имею ничего против python, но всё-таки чаще, если речь о web, слышу рекомендации в сторону рнр.
2. +1 к непонятно как юзабилити оценивали.
p.s.
И сдаётся мне, что эта инфографика ну никак не решает вопрос холиваров этих языков.
Про систему учёта ревью — это верно, нужна такая.
Ещё мысли лезут в сторону кросс-ревью — в этом случае, полагаю, надёжность повышается ещё на порядок.
Очень красиво и порадовали комментарии в сорсе.
Правда, под конец немного притормаживало
Тема для холивара, поэтому прошу просто учесть, что это личный опыт.
Теперь по теме, но прежде капля о себе:
Я закончил технический вуз, специалист.
Во многом с Вами соглашусь, особенно теперь, когда мне периодически необходимо выступать в роли преподавателя. К слову, это действительно безумно увлекательно — строить процесс обучения, передавать свой опыт.
Однако, в нескольких аспектах не совсем разделяю Вашу точку зрения.
Как например, что «проектировщикам интерфейсов» высшее образование не нужно.
Нужно и даже очень. Иначе приходят «специалисты», которым приходится объяснять чуть ли не что такое функция и как в неё передать параметры.
Высшее образование даёт фундамент, площадку, на которой уже можно развернуться, подготовиться к дальнейшим действиям.
Без вузовского образования знания, как правило, носят стихийный характер, в результате чего, зачастую, приходится тратить немало времени на то, чтобы объяснить такому человеку, почему нужно сделать так, а не по-другому.
В качестве заключения:
ещё раз спасибо за статью, надеюсь увидеть их ещё от Вас по данной теме.
«Талантливый человек талантлив во всём» — без «должен быть».
На мой взгляд довольно удобно, что все имеющиеся у человека устройства по-тихоньку интегрируются между собой.