Pary_anime
Tworzenie nazw
Nazwy s± jednym z kluczowych elementów kodu PHP - sercem aplikacji..
Nazwy powinny opisywaæ to co nazywaj± i do czego s³u¿± w sposób jak najbardziej jednoznaczny.
Zaleca siê unikanie w opisowej czê¶ci wiêcej cz³onów ni¿ trzy, gdy¿ zazwyczaj utrudnia to zrozumienie kodu ni¿ poprawê jego czytelno¶æ. Poza tym takie nazwy s± bardziej przemy¶lane i rzadko potrzebuj± wiêcej cz³onów ni¿ 3.
Pakiety
Wszystkie, rozdzielane podkre¶lenie, cz³ony nazwy pakietu powinny byæ pisane wszystkim du¿ymi literami.
Np.
codeDivStart() OPEN_SOURCE
Klasy
Klasy powinny byæ jak najdok³adniejszymi ich opisami. Je¶li to mo¿liwe to zaleca siê unikanie skrótów. Ka¿dy cz³on nazwy powinien byæ pisany z du¿ej litery, a cz³ony powinny byæ rozdzielane za pomoc± podkre¶lenia.
Np.
codeDivStart() Logowianie, Logowanie_Uzytkownika, Wprowadzenie_Nowego_Szablonu.
W przypadku korzystania z biblioteki klas, jako prefiksu nale¿y u¿yæ nazwy pakietu.
Np.
codeDivStart() OPEN_SOURCE_Wprowadzenie_Nowego_Szablonu
Funkcje i Metody
System ten nazywany jest "camel caps". Nazwa pochodzi od wygl±du napisu, który przypomina garby wielb³±da. Pierwszy cz³on nazwy jest pisana z ma³ej litery, a ka¿dy nastêpny wyraz z du¿ej, a dodatkowo brak jest znaku (spacja to te¿ znak) rozdzielaj±cego. W przypadku funkcji nale¿y stosowaæ (a przynajmniej siê zaleca) prefiksów okre¶laj±cych nazwê pakietu, z którego pochodz± funkcje, co zapobiegnie kolizji miêdzy pakietami.
Np.
codeDivStart() polacz(), pobierzDane(), OPEN_SOURCE_specyfikujPotrzeby()
Zalecane skróty sufiksy
Max - maksymalna mo¿liwa warto¶æ
Cnt - aktualnie zliczona warto¶æ
Key - warto¶æ kluczowa
Np.
OdpowiedziMax - maksymalna liczba mo¿liwych odpowiedzi,
OdpowiedziCnt - aktualna warto¶æ odpowiedzi
- Zalecane skróty prefiksów (na pocz±tku du¿e litery! ):
Is - do zadawania pytania, czy cos jest.
Get - w celu pobrania warto¶ci
Set - w celu ustalenia warto¶ci.
Np.
IsOdpowiedz - Czy jest odpowied¼?
- * ¯aden z cz³onów nie powinien sk³adaæ siê z du¿ych liter, nawet gdy ten cz³on jest skrótem, lub powszechnie uznawan± form± zapisu.
Np.
Poprawnie: GetHtmlStatystyka
Niepoprawnie: GetHTMLStatystyka
- * W przypadku funkcji w tzw. klasach prywatnych zaleca siê je poprzedzaæ pojedyñczym podkresleniem.
_sortuj(), _inicjujDrzewko(), $this ->_status
Warto¶ci sta³e
Wszystkie cz³ony nazwy powinny byæ pisane wszystkimi wielkimi literami ³±czonymi podkre¶leniami. W przypadku, gdy warto¶æ ma zwi±zek z nazw± klasy/pakietu to jej/jego nazwa powinna byæ zapisana wielkimi literami.
Zmienne
Wszystkie cz³ony pisane ma³ymi literami i rozdzielone podkre¶leniem.
Elementy tablic
Pisane podobnie jak zmienne. Nigdzie nie u¿ywaj my¶lnika "-". Zawsze u¿ywaj apostrofów lub cudzys³owów do wyodrêbnienia elementów.
codeDivStart() $myarr['foo_bar'] = 'Hello'; //poprawnie
$myarr['foo-bar'] = 'Hello'; //niepoprawnie
Warto¶ci globalne
W razie potrzeby definiowania warto¶ci globalnych ich nazwa powinna byæ poprzedzona prefiksem w postaci pojedynczego podkre¶leniem, nazwy pakietu oraz kolejnego podkre¶lenia.
Np.
codeDivStart() $_OPEN_SOURCE_jaki_ladny_jest_swiat
Warto¶ci predefiniowane
Takie warto¶ci jak true, false, null powinny byæ pisane z ma³ej litery.
Nazwy w bazach danych SQL
- klucz podstawowy
- * Ka¿da tabela musi mieæ ustawiony serial index jako jej klucz podstawowy (primary key), a w nazwie powinien zawieraæ cz³on id.
- Nazwy tabel
- * Nazwami tabel nie mog± byæ samodzielnie (tzn. jako jedyne cz³ony, bez prefiksów, etc) s³owa zarezerwowane dla SQL, tj.:
- * Nazwy tablel s± zapisane w ca³o¶ci ma³ymi literami, a poszczególne s³owa rozdzielone s± podkre¶leniami
- * Nazwy tabels± podawane w liczbie mnogiej zgodnie z tym co zawieraja, tj. zawsze nale¿y pisac uzytkownicy zamiast uzytkownik
codeDivStart() abort add all allocate alter analyze and any are as asc assertion at authorization avg begin between binary bit bit_length both by cascade cascaded case cast catalog char character character_length char_length check close cluster coalesce collate collation column commit connect connection constraint continue convert copy corresponding count create cross current current_date current_session current_time current_timestamp current_user cursor date datetime deallocate dec decimal declare default delete desc describe descriptor diagnostics disconnect distinct do domain drop else end escape except exception exec execute exists explain extend external extract false fetch first float for foreign found from full get global go goto grant group having identity in indicator inner inout input insert intersect interval into is join last leading left like listen load local lock lower max min module move names national natural nchar new no none not notify null nullif numeric octet_length offset on open or order out outer output overlaps partial position precision prepare preserve primary privileges procedure public references reset revoke right rollback rows schema section select session session_user set setof show size some sql sqlcode sqlerror sqlstate substring sum system_user table temporary then timespan to trailing transaction translate translation trim true union unique unknown unlisten until update upper usage user using vacuum value values varchar varying verbose view when whenever where with without work write
- Nazwy pól
- * Nazwy pól s± zapisane w ca³o¶ci ma³ymi literami, a poszczególne s³owa rozdzielone s± podkre¶leniami
- * Nazwy pól s± podawane w liczbie pojedynczej, chyba ¿e zawieraj± tre¶æ wskazuj±c± na wiele elementów
- * Nazwy pó³ s± poprzedzone prefiksem sk³adaj±cym siê z pierwszych liter poszczególnych cz³onów nazwy tabeli, np. dla tabeli kategorie_uzytkownokow - ku_id
- * W przypadku nazw pól to nie jest zabronione stosowanie nazw zastrzezonych, gdy¿ zgodnie z niniejsza propozycja nazwy pól s± zawsze poprzedzane prefiksem od nazwy tablicy. W innym przypadku nazwy nie moglyby zawierac nazw zastrze¿onych.
!" border="0" /> G³osowanie rozpoczête !
Po d³ugotrwa³ych dyskusjach, przekonywaniu sie (co tu ukrywac) za¿artych k³ótniach postanowili¶my poddaæ projekt standardu pod g³osowanie. Uznali¶my, ¿e lepsze jest wrogiem dobrego, a nasze akademickie dyskusje mog± siê ci±gn±æ w nieskoñczono¶æ. Zawsze mo¿na niedoci±gniêcia poprawiæ pó¼niej.
Bardzo proszê zwolenników PHP i Open Source do wziêcia udzia³u w niniejszym g³osowaniu. Koniec g³osowania planowany na 20 grudnia 2002, a wiêc jeszcze przed
Bo¿ym Narodzeniem.
Myslê, ¿e to przyczyni siê do ruszenia dalszych projektów.
Zg³oszone od dzi¶ propozycje zmian bêd± mog³y byæ g³osowane w po¼niejszym czasie.
No fajnie, ale moze ktos by dokladniej wyjasnil czym sa poszczegolne rodzaje nazw. Boje sie, ze beda tacy, ktorzy nie beda rozrozniali zmiennych od stalych. Zreszta ja czasami tez mam z tym problemy. Niby wiem, ale jakos mi to nie pasuje.
