#php #mysql #naming-conventions
#php #mysql #соглашения об именовании
Вопрос:
Довольно часто в коде модели PHP (по крайней мере, в моем собственном таком коде) есть прямые ссылки на имена таблиц и полей MySQL, и поскольку идентификаторы MySQL по большей части не чувствительны к регистру, я обычно использую соглашение об именовании under_score, чтобы сделать эти идентификаторы немного более читаемыми.
В то же время, однако, кажется, что большинство людей используют соглашения camelCase при создании библиотек классов PHP, и я тоже пытался это сделать.
Кроме того, сами встроенные функции PHP несовместимы. Некоторые из них используют camelCase, другие используют under_scores, а третьи используют именование в стиле C (например, «strtolower»).
В результате код становится гораздо менее читабельным, чем я предпочитаю, из-за смешанных соглашений об именовании в стиле camelCase, under_score и C, которые отображаются в коде совсем рядом друг с другом.
Как другие люди справляются с этим? Возможно, люди нашли какой-то способ организовать свою работу так, чтобы различные соглашения об именовании, как правило, не выглядели так близко друг к другу? Или, возможно, существуют библиотеки классов, которые при правильном использовании, как правило, делают вещи немного чище? Я знаю, что эти обсуждения стиля могут быть горячими — не нужно туда заходить, просто несколько практических предложений, пожалуйста!
Комментарии:
1. Похоже, что большинство ответов на этот вопрос сводятся к «Быть последовательным» — но не решают вопрос о том, что делать с идентификаторами из различных контекстов, появляющимися в одном и том же модуле кода.
2. Лично у меня нет реальной проблемы с разделением их. При разработке MySQL DBs я использую только нижний регистр. Основными именами функций контроллера / модели в PHP / CI являются camelCase. Я делаю все возможное, чтобы исключить подчеркивания из моего кода, но плагины типа tank_auth их используют. Я полагаю, что это забавно (и недостаток) гибкости PHP.
3. @Kyle здесь то же самое. Забавно на самом деле. В SQL никогда не бывает camel case и много
_. PHP никогда_и много верблюдов. Я думаю, что на самом деле это очень ясно: вы можете увидеть исходные данные следующим образом: PHP или SQL создали это varname?4. Символы подчеркивания часто используются в функциях типа _constructor (примером может быть что-то вроде _createuser в tank_auth) для обозначения их функции, но я настоятельно предпочитаю camelCase и просто размышлять над именем функции в течение нескольких минут. Хорошие описания на простом, повторяющемся английском языке превосходят дескрипторы, основанные на синтаксисе, каждый день, ИМО.
Ответ №1:
Как говорит Тереско, имена MySQL чувствительны к регистру на платформах * NIX и нечувствительны к Windows. Если вы разрабатываете код для поддержки обоих (как это делаю я), то смешивание ваших обращений может вызвать огромную головную боль: например, дамп базы данных в Windows и восстановите ее в * NIX, и все ваши обращения будут потеряны. На самом деле нам пришлось собирать код для обнаружения и исправления обращений в дампе только по этой причине.
Однако, если вы свободны от Windows, на самом деле не имеет значения, что вы используете, до тех пор, пока вы поддерживаете его согласованность.
Ответ №2:
Когда дело доходит до моделей и таблиц базы данных, вы можете использовать:
- camelCase для имен моделей,
- форма множественного числа имени вашей модели для таблицы базы данных (с согласованными строчными / прописными буквами, например, ‘camelcases’),
- имена таблиц в алфавитном порядке, разделенные символом подчеркивания (например, ‘camels_cases’ является таблицей соединения между ‘cases’ и ‘camels’),
Для классов я бы обычно использовал CamelCases (начиная с верхнего регистра) и camelCases для методов (начиная со строчных регистров).
Но, на самом деле, что имеет значение, так это согласованность и удобочитаемость. Может быть хорошей идеей следовать соглашениям об именовании некоторых хорошо известных и широко реализованных фреймворков, таких как Zend Framework (этот предоставляет довольно точные рекомендации в отношении стандарта кодирования), но, например. Kohana также может быть хорошей идеей. Изобретать велосипед, возможно, не лучшая идея 😉