Конвенции за именуване на PHP/MySQL: camelCase срещу under_score?

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

В същото време обаче изглежда, че повечето хора използват конвенциите на camelCase, когато създават PHP библиотеки с класове, и аз също се опитвам да направя това.

На всичкото отгоре, самите вградени в PHP функции са непоследователни. Някои от тях използват camelCase, други използват under_scores, а трети използват наименуване в стил C (например "strtolower").

Резултатът е, че кодът има тенденция да бъде много по-малко четим, отколкото предпочитам, какво със смесените конвенции за именуване в стил CamelCase, under_score и C-стил, които се показват доста близо един до друг в кода.

Как другите хора се справят с това? Може би има някакъв начин, по който хората са намерили да организират работата си така, че различните конвенции за именуване да не изглеждат толкова близо едно до друго? Или може би има библиотеки с класове, които, ако се използват правилно, правят нещата малко по-чисти? Знам, че тези дискусии за стил могат да станат разгорещени - няма нужда да ходите там, моля, само някои практически предложения!


person rmw    schedule 02.05.2011    source източник
comment
Изглежда, че повечето от отговорите на този въпрос се свеждат до Бъдете последователни - но не успявате да отговорите на въпроса какво да правите с идентификатори от различни контексти, появяващи се в един и същ кодов модул.   -  person rmw    schedule 03.05.2011
comment
Лично аз нямам истински проблем да ги държа отделно. Когато проектирам MySQL DB, използвам само малки букви. Основните имена на функции на контролер/модел в PHP/CI са camelCase. Правя всичко възможно да запазя долните черти извън моя код, но плъгини като tank_auth ги използват. Това е забавлението (и недостатъкът) на гъвкавостта на PHP, предполагам.   -  person Michael B    schedule 03.05.2011
comment
@Kyle същото тук. Смешно всъщност. 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)


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

Ако нямате Windows, няма особено значение какво използвате, стига да го поддържате последователно.

person Oliver Emberton    schedule 02.05.2011

Когато става въпрос за модели и таблици на бази данни, можете да използвате:

  • CamelCase за имена на модели,
  • форма за множествено число на името на вашия модел за таблицата на базата данни (с последователни малки/главни букви, като напр. „camelcases“),
  • имена на таблици по азбучен ред, разделени с долна черта (напр. 'camels_cases' е таблица за връзка между 'cases' и 'camels'),

За класове обикновено бих използвал CamelCases (започващи с главни букви) и camelCases за методи (започващи с малки букви).

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

person Tadeck    schedule 02.05.2011