case-sensitive имена переменных, не пора ли изменить поведение php?

[Absinthe]

На самом деле разницы заметной нет,
как нет и минусов текущего подхода("можно перепутать" - туфта, недопустимая с современными средствами разработки).

А изменение подхода сломает совместимость.
Поэтому в топку.

 

[Absinthe]

Одна из них - ЕДИНЫЙ СТИЛЬ КОДИРОВАНИЯ. Если у тебя есть переменная $а - НИКОГДА не должно возникнуть переменной $A. Это правило. Написано оно литрами лишне-выпитого кофе.

Не согласен.
var statement = new Statement() - нормальное поведение.

 

[Adelf]

Absinthe
и?
Что мешает в php написать
$statement = new Statement(); ?
В чем твое возражение вообще?

 

[A1x]

как сказал классик, при программировании тратится 90% времени на чтение кода и только 10% на написание (или около того)
это аргумент к тому почему очень важно делать код хорошо читаемым

но эти ваши ребята которые пишут быстрее чем ИДЕ соображает конечно же выше подобной чепухи

а для тех кто привык писать аккуратно, такое изменение только создаст лишние проблемы

 

[fixxxer]

ТЕОРИЯ, my ass.

в помойку please.

Если кто-то достаточно туп, чтобы не понимать, почему именно переменные в php case sensitive - напомню, что большинство имен переменных могут быть ключами массива и обратно, начиная с _GET/_POST и register_globals и заканчивая обычными extract() / compact().

 

[Adelf]

в помойку please.

Done.

Может вообще тему прикрыть? Бесполезная какая-то.

 

[DYPA]

Ндааа ... упёрлись рогом а мозги в отпуске.

не внимательно прочитали суть вопроса, а может и просто ничего не поняли всего пару нормальных ответов на тему...

Ах да. А с индексами массивов что делать будем? Тоже регистро-независимость вводить ? А то ж ведь я и так могу $GLOBALS['v']

нет конечно индексы массивов трогать не следует, для $GLOBALS массива правда придется её ввести, но хуже не станет.

Если кто-то достаточно туп, чтобы не понимать, почему именно переменные в php case sensitive - напомню, что большинство имен переменных могут быть ключами массива и обратно, начиная с _GET/_POST и register_globals и заканчивая обычными extract() / compact().

register_globals - не актуально
$GLOBALS - очень специфичный массив
extract() - будет жить вполне нормально из-за значения по умолчанию EXTR_OVERWRITE
compact() - ключ массива задается самими аргументами функции, не думаю что с этой функцией будут какие либо проблемы

 

[Adelf]

>> - как вы считаете является ли эта возможность php способом "выстрелить себе в ногу"?
Нет
>> - считаете ли вы для себя это багом?
Нет
>> - готовы ли вы поддержать багрепорт?
Нет
>> - готовы ли вы предоставить патч?
Нет

Я заколебусь читать код, где смогут вместе находиться Static, sTatic и sTATIC.

З.Ы. Эта тема вообще неактуальна. У разработчиков PHP с мозгами то все в порядке. Не будут даже дискуссировать на эту тему.

 

[Alexandre]

лично я считаю,что для такого нестрогого языка как РНР, большие и малые буквы в имене переменной большой роли не должны
действительно, из-за невнимательности можно огрести грабли
и не надо кивать в сторону, что мол IDE сделает за вас всю грязную работу, а мы такие чистенькие будем только красиво кодить.
Нет, IDE не идеальна и может тоже подвести - это раз, и второе - есть люди или ситуации, когда нет возможности использовать IDE.

Господи, все так подсели на эти IDE, что на собеседовании человеку даешь консоль, и он не знает что с ней делать...

 

[DYPA]

Я заколебусь читать код, где смогут вместе находиться Static, sTatic и sTATIC.

я тебя огорчу уже сейчас ничего не мешает писать function(), Function() и FuNcTiOn() - так повального использования такой возможности языка я не замечаю, а вот проблем это позволяет избежать

 

[Adelf]

а вот проблем это позволяет избежать

Каких?

 

[DYPA]

Каких?

например банальных опечаток

 

[Adelf]

Все мои очепятки отлавливались E_ALL | E_STRICT и подробно показываются Коханой в dev режиме

 

[Вурдалак]

например банальных опечаток

Ты предлагаешь фактически забивать на опечатки. Говнокодер

 

[DYPA]

Ты предлагаешь фактически забивать на опечатки. Говнокодер

забивать на опечатки? тогда текущая реализация функций, классов и методов просто провоцируют писать говнокод!

 

[Вурдалак]

о, отлично - тогда давайте вкрутим подобны

А ведь тебе автокомплит не помешает.

 

[DYPA]

Все мои очепятки отлавливались E_ALL | E_STRICT и подробно показываются Коханой в dev режиме

код из сообщения тоже поймает?

 

[shureen]

код из сообщения тоже поймает?

ну вообще да. Ты свой код запускал сам? Выдаст нотис, что и следовало ожидать

 

[Вурдалак]

забивать на опечатки? тогда текущая реализация функций, классов и методов просто провоцируют писать говнокод!

У меня нет твоих проблем, чувак. И мне они неинтересны. Я тебе повторю простую вещь: если у тебя случайно (ты не хотел этого, блять!) набрана переменная в неверном регистре, то лучше это увидеть на этапе тестирования, а не пополнять код говном. Если ты этого не хотел, то исправь ошибку, б####!

Если же ты сознательно набрал в неверном регистре, то ты ССЗБ.

 

[fixxxer]

не внимательно прочитали суть вопроса, а может и просто ничего не поняли всего пару нормальных ответов на тему...


нет конечно индексы массивов трогать не следует, для $GLOBALS массива правда придется её ввести, но хуже не станет.


register_globals - не актуально
$GLOBALS - очень специфичный массив
extract() - будет жить вполне нормально из-за значения по умолчанию EXTR_OVERWRITE
compact() - ключ массива задается самими аргументами функции, не думаю что с этой функцией будут какие либо проблемы

Ну да, ну да.

// $_GET['user_id'] = 22;
$USER_ID = 10;
extract($_GET);
echo $USER_ID;

Про опечатки полная чушь т.к. все php errors в т.ч. notice все нормальные люди давно завернули в исключения.

Как по мне - так наоборот НЕчувствительность к регистру имен классов - недостаток. Разрабатывая на нечувствительной к регистру ФС (windows, mac os x), легко словить проблему с autoload только на production (да, разрабатывать надо на той же ОС что на продакшене, спасибо капитаны)