ВерблюжьяНотация vs нотация_через_подчеркивание

Сейчас подавляющем числе проектов PHP + MySQL принято использовать верблюжью нотацию для скриптов, и нотацию с подчеркиванием для баз данных. Да и на других платформах ситуация примерно такая же. Почему одновременно используют две разных нотации в одном проекте? Это не удобно, часто приходится делать преобразования типа:
$forScripts['someVariable'] = $fromDatabase['some_variable'];
$forScripts['someOtherVariable'] = $fromDatabase['some_other_variable'];
Меня это утомляет. Да можно автоматизировать эти преобразование, но это лишние действия.
Во всяких ORM и ActiveRecord подобных приемах тоже приходится делать преобразования.
К тому же, если переменная сотоит из одного слова, то не понятно в какой нотации она написана.

У меня есть желение использовать в новом большом проекте везде вербюлюжью нотацию. Т.е. таблицы, поля, хранимые процедуры баз данных писать в camelCase. Хотелось бы узнать ваше мнение. Есть какие нибудь в этом минусы?
  • Вопрос задан
  • 3022 просмотра
Пригласить эксперта
Ответы на вопрос 4
Лично я беру за правило нотации из синтаксиса языка.
Для php: верблюжья нотация для методов, для всего остального нотация через подчёркивание.
Для js: верблюжья нотация для методов, для отдельных функций через "БольшиеБуквы".
Для css: через дефисы.
Ответ написан
Комментировать
Akdmeh
@Akdmeh
PHP, Yii2, Music
Должен рассказать о забавном баге, с которым как-то столкнулся.
Таблицы в MyISAM хранятся в виде одноименных файлов, а регистр файлов в Linux чувствительный, поэтому случилось так, что в части кода у меня таблица называлась `MyCoreUsers`, а в части "mycoreusers".
Короче, потом пришлось немало повозиться.
Может, там есть настройка, которая отключает подобное поведение, но после этого в SQL названиях таблицх-полей использую исключительно нижний регистр и подчеркивания.
Ответ написан
@m-haritonov
Ориентируйтесь исключительно на технические требования. Если используемые Вами программные продукты не предъявляют технических требований к именованию идентификаторов, то используйте тот стиль, который Вам нравится (если, конечно, не требуется вести совместную разработку с другими разработчиками; тогда надо учитывать и их мнение). Ваше желание унифицировать правила именования идентификаторов (и выкинуть таким образом из головы лишнюю информацию) более чем естественно и правильно.

P.S.: в Вашем решении я вижу только плюсы, т.к. я сам перешёл на подобное унифицированное именование идентификаторов (variableName, fieldName, constantName, ClassName, ConstructorFunctionInJavaScript, simpleFunctionInJavaScript, cssClassName, someNamespace-elseNamespace-cssClassName, но some-domain.com/some-page/some-subpage?some-param, /images/some-image.png).
Ответ написан
Комментировать
iproger
@iproger
Безответственный гений
https://github.com/d4rkr00t/PSR-Translations/blob/...

А вообще - переменные через _, а методыТак.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы