ugrás a tartalomhoz

Case sensitive programozási stílus

inf · 2010. Jún. 6. (V), 04.19
Sziasztok!

Nem csak php-vel kapcsolatban szeretnék kérdezni, hanem úgy overall a technikákkal kapcsolatban, amiket leírok..

Egy php osztály-t meg lehet feleltetni egy SQL adatbázis táblának meg egy XML Schema elementnek is. Az osztály példányváltozóit pedig meg lehet feleltetni az adatbázis tábla mezőinek és complexType-ba ágyazott (nested) Schema elementeknek.
Továbbá az osztályokat fájlokban szokás tárolni, és onnan betölteni őket, a fájlokat pedig éredemes ugyanolyan névvel ellátni, mint az osztályok nevei és a namespaceszel (package) megegyező nevű mappákba tenni, mert így egyszerűen importálhatóak.
Továbbá egy Soap Envelope-ban az elementek tagNamejei szintén az osztályok neveivel egyeznek meg.

Szeretnék az osztályoknak, a példányváltozóknak és a metódusoknak olyan neveket adni, amiket a fent említett helyeken fel tudok használni átalakítás nélkül.
-php
-XML Schema
-XML(SoapEnv)
-SQL
-fileSystem(windows,linux stb..)
(A private, protected, public módosítókat a változó- és metódus nevekben nem szeretném feltűntetni.)

Tudtok valamit ajánlani?

Egyelőre három változatot találtam ki, de még nem próbálgattam őket.

new NameSpace\TestClass()->callMethod();
new Name-Space\Test-Class()->call-method();
new Name_Space\Test_Class()->call_method();
(Bocs a szintaktikai hibáért, de így egy sorba kifértek.)
 
1

Kis kiegészítő

inf · 2010. Jún. 6. (V), 04.30
Nyilván itt arra gondolok, hogyha a stílus nem alkalmazható valamelyik helyen, akkor valami olyan elnevezési formája kéne hogy legyen, ami nagyon könnyen átalakítható az adott helyen használható formára.

Mondjuk ha valamelyik rendszer nem szereti a nagybetűket, akkor az első stílus kapásból ugrott, mert a kisbetűsre alakításnál elvesznek a szóhatárok.
2

Inflektálás

Joó Ádám · 2010. Jún. 6. (V), 15.35
Miért kéne elvetni a camelcase-t a case insensitive rendszerek miatt? A BlogPost osztályból például kiválóan lehet blog_posts táblát csinálni, nem olyan bonyolult. És még csak nem is azért, mert az SQL nem kezeli, pusztán csak azért, mert így szokás.
3

Bizonyos SQL szerverek

inf · 2010. Jún. 6. (V), 17.38
Bizonyos SQL szerverek kezelik a kis és nagybetű eltérést, a MySQL is konfigurálható úgy, hogy kezelje. A camelcase-nél végig kell menni regex-el a szövegen, viszont ha alkalmazol valamilyen elválasztót (_ vagy -), akkor elég egy sima string függvény az átalakításhoz. A legjobb az lenne, ha egyáltalán átalakítani sem kéne, mert rengetegszer lenne meghívva az átalakító függvény. Persze, tudom, hogy nem a tervezésnél kéne optimalizálni, de nem feltétlen az optimalizálás a célom, inkább próbálom elkerülni a felesleges munkát. Mondjuk ha lehetne olyan kódot írni, ami ugyanúgy megy case sensitive és insensitive SQL vagy fájlrendszer változatokon a nevek transzformációja nélkül, akkor attól boldog lennék.

Nem feltétlen jó dolog a szokást követni.. nem case sensitivity-s példa: ha csinálsz egy DAO-t az blog_posts tábláról, akkor kapsz egy BlogPost class-t. Az egyes és többesszám elég nehezen összeegyeztethető, és nincs is sok értelme, mert nagyon egyértelmű az analógia az osztályok és a táblák között. Szóval én inkább BlogPost-ot használnék táblanévnek is. A camelcase átalakításához egy regex kell, ami szóhatárra beteszi az underscoret, ha viszont alapból bent van az underscore, akkor nem is kell transzformáció, mert a szóhatárok jelölve vannak.