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

Question

[tushev]

Сейчас подавляющем числе проектов PHP + MySQL принято использовать верблюжью нотацию для скриптов, и нотацию с подчеркиванием для баз данных. Да и на других платформах ситуация примерно такая же. Почему одновременно используют две разных нотации в одном проекте? Это не удобно, часто приходится делать преобразования типа:

$forScripts['someVariable'] = $fromDatabase['some_variable'];
$forScripts['someOtherVariable'] = $fromDatabase['some_other_variable'];

Меня это утомляет. Да можно автоматизировать эти преобразование, но это лишние действия.
Во всяких ORM и ActiveRecord подобных приемах тоже приходится делать преобразования.
К тому же, если переменная сотоит из одного слова, то не понятно в какой нотации она написана.

У меня есть желение использовать в новом большом проекте везде вербюлюжью нотацию. Т.е. таблицы, поля, хранимые процедуры баз данных писать в camelCase. Хотелось бы узнать ваше мнение. Есть какие нибудь в этом минусы?

Answer 1

[Виталий Желтяков]

Лично я беру за правило нотации из синтаксиса языка.
Для php: верблюжья нотация для методов, для всего остального нотация через подчёркивание.
Для js: верблюжья нотация для методов, для отдельных функций через "БольшиеБуквы".
Для css: через дефисы.

Answer 2

[Андрей Павленко]

Должен рассказать о забавном баге, с которым как-то столкнулся.
Таблицы в MyISAM хранятся в виде одноименных файлов, а регистр файлов в Linux чувствительный, поэтому случилось так, что в части кода у меня таблица называлась `MyCoreUsers`, а в части "mycoreusers".
Короче, потом пришлось немало повозиться.
Может, там есть настройка, которая отключает подобное поведение, но после этого в SQL названиях таблицх-полей использую исключительно нижний регистр и подчеркивания.

Comments

[Александр Зеленин]

очень забавный баг, что вы не учитываете регистр.

[m-haritonov]

@Akdmeh, Вы при создании таблицы как её называли: "mycoreusers" или "MyCoreUsers"?

Answer 3

[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).

Answer 4

[Михаил Шатилов]

https://github.com/d4rkr00t/PSR-Translations/blob/...

А вообще - переменные через _, а методыТак.