camelCase — это отстой. Или нет?

ravlio

Новичок
Каким боком вы справляетесь с конвертацией underscore в camelCase? Вот пример. PHP-ORM-объект, у которого свойства — это поля БД:

Код:
$user->firstName='Илья';
$user->lastName='Петров';
$user->update()
Всё хорошо. Но вот только у БД стандарт — это underscore. Соответственно, писать в БД надо firstName=>first_name, lastName=>last_name. А читать наоборот — firstName<=first_name, lastName<=last_name

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

Но идём дальше. HTML и именование полей, которое также идёт underscore.

HTML:
<form action="/user/update">
    <input name="first_name" id="first_name" value="{$user.firstName}">
    <input name="last_name" id="last_name" value="{$user.lastName}">
</form>
Как быть здесь? Также конвертировать имена входящих полей в camelCase? А если имена полей заранее неизвестны? Бывает и такое.

Теперь берём JavaScript. Вроде как тоже всё должно быть camelCase? Но давайте поработаем хотя бы с формой выше. Заполним её, подгрузив данные юзера через ajax. Там они будут в camelCase:

{firstName:'Илья',lastName:'Петров'}

Если не знать, что first_name=firstName, то неизвестно, какое значение куда вставлять. Нужно делать специальные таблицы соответствий или парсить имена переменных. В любом случае, всё приходится пускать через какую-то прокладку.

И наоборот, давайте обработаем форму через JavaScript. К примеру, так:

Код:
$.extend(this,$("form").serializeObject()); // Конвертируем элементы формы в объект
this.homeAddress='Московский пр., 31'; // Добавляем ещё одно свойство
console.log(this);

{first_name:'Илья',last_name:'Петров',homeAddress:'Московский пр., 31'} // Получаем смесь underscore и camelCase
(не смотрите, что так топорно, это лишь для примера).

Ну и что это за белиберда получилась? Это мне надо предусмотреть, чтобы serializeObject также делал мэппинг underscore<->camelCase? Ну вот примерно так:

Код:
for (var name in this)
{
   $("#"+some_clever_mapper(name)).val(this[name]); // вместо $("#"+name).val(this[name]);
}
Я ещё не проверял, но очень надеюсь, что в каждом языке есть возможность прочитать у переменной её имя собственное, чтобы понять, underscore она или нет и сконвертить её. Иначе придётся задавать фиксированные таблицы для всех переменных, а это вообще дурдом.

И это ещё не самый страшный пример. Есть следовать этим стандартам, то есть просто нерешаемые задачи. И когда соединяются DB, PHP, HTML и JS, то получается очень весело, нужно постоянно следить за подобными конверсиями.

И вот я читаю сейчас, тот же Yii рекомендует в PHP именоваться camelCase, в DB — underscore. При этом никаких бехиверов и мепперов для удобной работы из коробки не предоставляет.

Кто как решает проблему? Я решил просто: у меня изначально вообще всё в underscore, в том числе имена классов и файлов. И я горя не знаю, есть только проблемы с autoload. Но сейчас надо отдавать проект команде, а ведь все пишут в этом camelCase. Очень хочется следовать всем PSR, W3C и прочим стандартам, но я привёл конкретные примеры, которые ничего кроме головной боли и потери кучи времени не доставляют.
 

CoolKid

Новичок
собственного фреймворка ради стандартов
Очень хочется следовать всем PSR
как-то не очень вяжется с
Я решил просто: у меня изначально вообще всё в underscore
К тому же PSR не ограничивает никого в наименовании полей класса и переменных:
This guide intentionally avoids any recommendation regarding the use of $StudlyCaps, $camelCase, or $under_score property names.
 
Последнее редактирование:

ravlio

Новичок
Не надо вязать. Это всего лишь значит, что я хочу отрефакторить фреймворк под общепринятые стандарты. А вопрос был в том, кто как решает проблему, описанную мной.
 

hell0w0rd

Продвинутый новичок
Потому что не надо всякой хренью пользоваться. В Doctine(тоже хрень) есть даже выделенный интерфейс и две реализации - в лоб и с конвертацией.
Ну и по поводу api ты не прав, нет какого-то стандарта дефакто, ориентируясь на советы от Heroku, надо использовать underscore в rest-api https://github.com/interagent/http-api-design#downcase-paths-and-attributes
ЗЫ
PHP:
"helloWorld".replace(/([a-z0-9])([A-Z])/, function (match, a, b) {
    return a + '_' + b.toLowerCase()
});
 
Последнее редактирование:

ravlio

Новичок
Потому что не надо всякой хренью пользоваться.
Какой хренью пользоваться? PHP, HTML, JS, программированием, своими фреймворками?

Ну и по поводу api ты не прав, нет какого-то стандарта дефакто, ориентируясь на советы от Heroku, надо использовать underscore в rest-api https://github.com/interagent/http-api-design#downcase-paths-and-attributes
В чём я не прав? Апи или роутинг делаются в большинстве случаев через underscore (посмотреть любой проект, будь то твиттер или ВК), а реализация его делается через camelCase, что только подкидывает дров в топку. Вы, ребята, один другого краше. Был задан конкретный вопрос — как соединить в себе два стандарта, как это делаете вы. Если вы этого не делаете, не сталкивались или не знаете решения — зачем отвечать? Или мне конкретизировать и спрашивать, как вы это делаете в каком-нибдь Yii, где де-факто вы обязаны писать camelCase, нет мэппинга с underscore, а все мои описанные проблемы — актуальны?
 

AmdY

Пью пиво
Команда форума
Никакие это не стандарты, а рекомендации. Подчёркивание использовалось из-за вероятности допустить ошибку в регистрочувствительных системах. С айдешками эта беда не такая большая, так что можно смело переходить на камелкейс, никаких проблем это не вызывает. Здесь главное единый подход, тогда и опечаток не будет.
 
Последнее редактирование:

ravlio

Новичок
PHP:
"helloWorld".replace(/([a-z0-9])([A-Z])/, function (match, a, b) {
    return a + '_' + b.toLowerCase()
});
Шедевр. Вы посты набиваете на форуме впопыхах или что — я даже не знаю. Уж изысканный способ сконвертить camelCase в underscore я найду, об этом можно не переживать.

Никакие это не стандарты, а рекомендации. Подчёркивание использовалось из-за вероятности допустить ошибку в регистрочувствительных системах. С айдешками эта беда не такая большая, так что можно смело переходить на камелкейс, никаких проблем это не вызывает. Здесь главное единственный подход, тогда и опечаток не будет.
Спасибо за экскурс в историю underscore. Но это, к сожалению, оффтоп. При чём тут опечатки? Опечатки — это когда символ пропустил или не тот вставил. А я спрашиваю, как люди совмещают camelCase и underscore в проектах, где соединяются оба подхода! Я даже специально привёл примеры вместе с моими вариантами решения этой проблемы, но я надеюсь, что за столько времени люди более умные хоть как-то это систематизировали и мне таки откроют глаза что, мол, да, есть паттерны для этого или в каких-то фреймоврках это встроено.
 
Последнее редактирование:

CoolKid

Новичок
в каком-нибдь Yii, где де-факто вы обязаны писать camelCase
А можно ссылку на конвеншн , где это написано?
Или при скачивании дистрибутива Yii надо ставить галочку "Я обязуюсь использовать camelCase АБСОЛЮТНО ВО ВСЕХ случаях, даже в тех где это нахрен не нужно?"
 

ravlio

Новичок
А можно ссылку на конвеншн , где это написано?
Или при скачивании дистрибутива Yii надо ставить галочку "Я обязуюсь использовать camelCase АБСОЛЮТНО ВО ВСЕХ случаях, даже в тех где это нахрен не нужно?"
Нельзя ссылку. Ты можешь писать там underscore, можешь даже форкнуть underscore-версию, никто тебя не заставит не делать этого.
Но я лично не понимаю такой эклектики — мешать и underscore и camelCase. В Yii, насколько я понимаю, underscore допускается только в model. Но проблемы это не отменяет.

Вот мне интересно. Все, кто тут отписываются, вы как сами то пишите? В underscore, весь проект в одном index.php-файлике, спагетти-стайл? Или есть что-то посерьёзнее? Не верю я что-то, что ни у кого не было дилемм подобных моей.
 
Последнее редактирование:

CoolKid

Новичок
Все, кто тут отписываются, вы как сами то пишите?
Пишу, пытаясь соблюдать PSR-1, PSR-2
underscore использую для имен переменных и полей класса, для методов использую methodName(), для классов ClassName {}, для констант - CONSTANT_NAME
Еще пробелами отступы делаю :)
 

ravlio

Новичок
В этом есть толика истины. Если писать все свойства и переменные через underscore, то проблема вроде как исчезнет. А для тех, кто ещё не понял, с чем связано моё беспокойство, показываю пример прямо из официальной доки Yii:

PHP:
protected function beforeSave()
{
    if(parent::beforeSave())
    {
        if($this->isNewRecord)
            $this->create_time=time();
        return true;
    }
    else
        return false;
}
Не стоит зарываться в стандартах, имхо.
 

hell0w0rd

Продвинутый новичок
ТС, у тебя бомбит, от того, что фреймворк взял? То, как выглядит API - по сути задача view. А значит во view и должен происходить меппинг модельки в json.
Код выше пример отборного говнокода ;)
 

AmdY

Пью пиво
Команда форума
ravlio, ещё раз, откуда ты взял эти стандарты? нет никаких стандартов, пиши как угодно, всё будет работать, дело только в удобстве и привычках.
 

antson

Новичок
Партнер клуба
ravlio, ну нет жестких стандартов . Тут в самом php черте, что
Камел ничем не плох (см. Зенд).

Просто выбери фрейморк под задачу и следуй рекомендациям авторов.

Под твой стиль codeIgnitor подходит .
идентификаторы в нижнем регистре через подчеркивание. открывающая скобка на следующей строке
 

cDLEON

Онанист РНРСlub
Вот были времена, когда каждый разработчик пользовался underscore, потом пришел какой то нехороший человек и придумал свой дурацкий camelСase. Зачем придумал ? Какие проблемы решались ? А самое главное - что движет всеми его последователями мне не понятно.
Не вижу ни каких плюсов от сего нововведения ( ну кроме экономии 1 байта на имя в коде исходника ).
А минусов хоть отбавляй. ОченьНаглядныйТомуПример - эта фраза. А_вот_так_уже_лучше. Хотя да. Печатается это немного дольше. Но блин... Программирование это же не кружок по скоростному набору текста. Здесь думать надо когда печатаешь.....
 

Вурдалак

Продвинутый новичок
хз, меня вот бесит underscore. С camelCase выглядит компактнее, да и экономия на практике может быть реальна полезна, особенно если в проекте по соглашению жесткое ограничение на длину строки.

Что касается проблемы: ну, нехер напрямую маппить. Всегда должен быть промежуточный слой, описывающий маппинг, позволяющий как задавать дефолтную стратегию нейминга, так и ручное именование. Для сериализации/десериализации в/из JSON тоже существуют готовые библиотеки, позволяющие задавать какую угодно стратегию именования, включая camelCase.

Правда, каэш, говорить о каких-то промежуточных слоях адептам Active Record трудно. У них вся жизнь — это боль. Пользователи Active Record должны страдать.
 
Последнее редактирование:

cDLEON

Онанист РНРСlub
хз, меня вот бесит underscore. С camelCase выглядит компактнее, да и экономия на практике может быть реальна полезна, особенно если в проекте по соглашению жесткое ограничение на длину строки.

Что касается проблемы: ну, нехер напрямую маппить. Всегда должен быть промежуточный слой, описывающий маппинг, позволяющий как задавать дефолтную стратегию нейминга, так и ручное именование. Для сериализации/десериализации в/из JSON тоже существуют готовые библиотеки, позволяющие задавать какую угодно стратегию именования, включая camelCase.

Правда, каэш, говорить о каких-то промежуточных слоях адептам Active Record трудно. У них вся жизнь — это боль. Пользователи Active Record должны страдать.
А вот про отдельный слой по-подробнее :) Это как это вы собрались рендерить вьюху с формой через промежуточный слой, описывающий маппинг ? :))
ПС. Альтернатива AR - в чем ? Запросы от руки на каждый чих ? :)
 

Вурдалак

Продвинутый новичок
А вот про отдельный слой по-подробнее :) Это как это вы собрались рендерить вьюху с формой через промежуточный слой, описывающий маппинг ?
Я че-то не понимаю проблемы, промежуточным слоем я тут назвал хрень, аналогичную http://martinfowler.com/eaaCatalog/metadataMapping.html, только в более общем смысле.

ПС. Альтернатива AR - в чем ? Запросы от руки на каждый чих ? :)
DataMapper.
 

cDLEON

Онанист РНРСlub
Я че-то не понимаю проблемы, промежуточным слоем я тут назвал хрень, аналогичную http://martinfowler.com/eaaCatalog/metadataMapping.html, только в более общем смысле.
Ну и зачем эта хрень нужна вообще ? У объекта должен быть единый интерфейс. А то, что здесь предлагается сделать мешанину. Костыль. За который по-хорошему нужно бить по рукам.
Не вижу принципиальной разницы на уровне выше уровня ОРМ.
 
Сверху