Соглашения об именах PHP/MySQL: camelCase vs under_score?

Довольно часто в коде модели PHP (по крайней мере, в моем собственном таком коде) есть прямые ссылки на имена таблиц и полей MySQL, и, поскольку идентификаторы MySQL по большей части нечувствительны к регистру, я обычно использую соглашение об именовании under_score, чтобы сделать эти идентификаторы немного читабельнее.

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

Кроме того, сами встроенные функции PHP несовместимы. Некоторые из них используют camelCase, другие используют under_scores, а третьи используют именование в стиле C (например, «strtolower»).

В результате код становится гораздо менее читабельным, чем мне хотелось бы, из-за смешанных соглашений об именах в стиле camelCase, under_score и C, которые появляются в коде довольно близко друг к другу.

Как другие люди справляются с этим? Возможно, люди нашли какой-то способ организовать свою работу таким образом, чтобы различные соглашения об именах не казались такими близкими друг к другу? Или, возможно, есть библиотеки классов, которые при правильном использовании делают вещи немного чище? Я знаю, что эти дискуссии о стиле могут разгореться — не нужно вдаваться в подробности, просто несколько практических советов, пожалуйста!


mysql php naming-conventions
person rmw    schedule 02.05.2011    source источник
comment
Похоже, что большинство ответов на этот вопрос сводятся к тому, чтобы быть последовательными, но не отвечают на вопрос, что делать с идентификаторами из разных контекстов, появляющимися в одном и том же модуле кода.   -  person rmw    schedule 03.05.2011
comment
Лично у меня нет проблем с тем, чтобы держать их отдельно. При проектировании БД MySQL я использую только строчные буквы. Основные имена функций контроллера/модели в PHP/CI — camelCase. Я стараюсь не использовать подчеркивания в своем коде, но такие плагины, как tank_auth, их используют. Я полагаю, в этом и есть преимущество (и недостаток) гибкости PHP.   -  person Michael B    schedule 03.05.2011
comment
@ Кайл, то же самое здесь. Смешно на самом деле. SQL никогда не бывает верблюжьим и много _. PHP никогда не _ и много верблюдов. Я думаю, что это на самом деле очень ясно: вы можете увидеть происхождение следующим образом: PHP или SQL создали это имя переменной?   -  person Rudie    schedule 03.05.2011
comment
Подчеркивания часто используются в функциях типа _constructor (примером может быть что-то вроде _createuser в tank_auth) для обозначения их функции, но я предпочитаю camelCase и просто думаю над названием функции в течение нескольких минут. Хорошие описания на простом повторяемом английском лучше, чем синтаксические дескрипторы каждый день, IMO.   -  person Michael B    schedule 03.05.2011

Ответы (2)


arrow_upward
7
arrow_downward

Как говорит teresko, имена MySQL чувствительны к регистру на платформах *NIX и нечувствительны к Windows. Если вы разрабатываете код для поддержки обоих (как я), то смешивание ваших случаев может вызвать огромные головные боли: например, выгрузите базу данных в Windows и восстановите ее на *NIX, и все ваши случаи будут потеряны. На самом деле, именно по этой причине нам пришлось загромождать код для обнаружения и исправления случаев в дампе.

Если вы свободны от Windows, то на самом деле не имеет значения, что вы используете, если вы поддерживаете его согласованность.

person Oliver Emberton    schedule 02.05.2011

arrow_upward
2
arrow_downward

Когда дело доходит до моделей и таблиц базы данных, вы можете использовать:

  • CamelCase для названий моделей,
  • форма множественного числа имени вашей модели для таблицы базы данных (с согласованными нижними/верхними регистрами, например, «camelcases»),
  • имена таблиц в алфавитном порядке, разделенные символом подчеркивания (например, «camels_cases» — это таблица соединений между «cases» и «camels»),

Для классов я бы обычно использовал CamelCases (начиная с верхнего регистра) и camelCases для методов (начиная с нижнего регистра).

Но, на самом деле, важны последовательность и удобочитаемость. Может быть хорошей идеей следовать соглашениям об именах некоторых хорошо известных и широко применяемых фреймворков, таких как Zend Framework (это дает довольно точные рекомендации в отношении стандарта кодирования), но, например, . Кохана тоже может быть хорошей идеей. Изобретать велосипед - не лучшая идея ;)

person Tadeck    schedule 02.05.2011