Wprowadzenie do Zend Framework

     Nauka Zend Framework

    appendix

     Przewodnik po Zend Framework


  • Zend_Gdata
  • Zend_Http
  • Zend_InfoCard
  • Zend_Json
  • Zend_Layout
  • Zend_Ldap
  • Zend_Loader
  • Zend_Locale
  • Zend_Log
  • Zend_Mail
  • Zend_Markup
  • Zend_Measure
  • Zend_Memory
  • Zend_Mime
  • Zend_Navigation
  • Zend_Oauth
  • Zend_OpenId
  • Zend_Paginator
  • Zend_Pdf
  • Zend_ProgressBar
  • Zend_Queue
  • Zend_Reflection
  • Zend_Registry
  • Zend_Rest

  • Zend_Search_Lucene
  • Zend_Serializer
  • Zend_Server
  • Zend_Service
  • Zend_Session
  • Zend_Soap
  • Zend_Tag
  • Zend_Test
  • Zend_Text
  • Zend_TimeSync
  • Zend_Tool
  • Zend_Tool_Framework
  • Zend_Tool_Project
  • Zend_Translate
  • Zend_Uri
  • Zend_Validate
  • Zend_Version
  • Zend_View
  • Zend_Wildfire
  • Zend_XmlRpc
  • ZendX_Console_Process_Unix
  • ZendX_JQuery
  • Translation 21.3% Update 2011-11-16 - Revision 24356 - Version ZF 1.11.x

    C.3. Konwencje nazewnictwa

    C.3.1. Klasy

    Zend Framework używa takiej konwencji nazewnictwa, w której nazwy klas bezpośrednio odpowiadają katalogom, w których się znajdują. Głównym katalogiem standardowej biblioteki ZF jest katalog "Zend/", a głównym katalogiem dodatkowej biblioteki ZF jest katalog "ZendX". Wszystkie klasy Zend Framework są przechowywanie hierarchicznie w tych katalogach.

    Nazwy klas mogą zawierać tylko znaki alfanumeryczne. Liczby są dozwolone w nazwach klas, jednak ich użycie jest odradzane w większości przypadków. Użycie znaków podkreślenia jest dozwolone tylko w przypadku gdy są separatorami ścieżek; plik "Zend/Db/Table.php" musi odpowiadać nazwie klasy "Zend_Db_Table".

    Jeśli nazwa klasy składa się z więcej niż jednego słowa, pierwsza litera każdego kolejnego słowa powinna być wielka. Zapisanie wyrazów w całości wielkimi literami jest niedozwolone, przykładowo nazwa klasy "Zend_PDF" jest niedozwolona, a nazwa "Zend_Pdf" jest już akceptowalna.

    Te konwencje określają mechanizm pseudo-przestrzeni nazw dla Zend Framework. Zend Framework będzie używać funkcjonalności przestrzeni nazw PHP gdy będą już dostępne dla programistów do użycia w swoich aplikacjach.

    Zobacz nazwy klas znajdujące się w standardowej lub dodatkowej bibliotece aby zobaczyć przykłady konwencji nazewnictwa klas. WAŻNE: Kod który musi być rozwijany wraz bibliotekami ZF, a nie jest częścią standardowych lub dodatkowych bibliotek (np. kod aplikacji lub biblioteki nie rozpowszechniane przez firmę Zend) nigdy nie może zaczynać się przedrostkiem "Zend_" oraz "ZendX_".

    C.3.2. Nazwy plików

    W nazwach innych plików dozwolone jest użycie jedynie znaków alfanumerycznych, znaków podkreślenia ("_") oraz myślnika ("-"). Użycie spacji jest zabronione.

    Nazwa każdego pliku zawierającego jakikolwiek kod PHP powinna być zakończona rozszerzeniem ".php", nie dotyczy to skryptów widoków. Poniższe przykłady pokazują akceptowalne nazwy plików zawierających klasy Zend Framework:

    Zend/Db.php

    Zend
    /Controller/Front.php

    Zend
    /View/Helper/FormRadio.php

    Nazwy plików powinny odpowiadać nazwom klas, tak jak to pokazano powyżej.

    C.3.3. Funkcje i metody

    Nazwy funkcji mogą zawierać tylko znaki alfanumeryczne. Znaki podkreślenia są niedozwolone. Użycie liczb w nazwach funkcji jest dozwolone, ale odradzane w większości przypadków.

    Nazwy funkcji zawsze muszą zaczynać się małą literą. Jeśli nazwa funkcji składa się z więcej niż jednego wyrazu, pierwsza litera każdego następnego wyrazu powinna być wielka. Jest to powszechnie zwane formatowaniem "camelCase".

    Zalecane jest dobieranie szczegółowych nazw funkcji. Powinny one być tak szczegółowe, jak to możliwe, aby w pełni opisać ich zachowanie i zastosowanie.

    Oto przykłady akceptowalnych nazw funkcji:

    filterInput()

    getElementById()

    widgetFactory()

    W programowaniu zorientowanym obiektowo metody dostępowe dla instancji lub statycznych zmiennych powinny zawsze zaczynać się od słów "get" lub "set". Jeśli implementujesz wzorzec projektowy, na przykład wzorzec "singleton" lub "factory", nazwa metody powinna zawierać nazwę wzorca, dzięki czemu wzorzec będzie można łatwo rozpoznać.

    Pierwszy znak w nazwach metod zadeklarowanych jako "private" lub "protected" musi być znakiem podkreślenia. Jest to jedyne akceptowalne użycie podkreślenia w nazwach metod. Metody zadeklarowane jako "public" nigdy nie powinny zawierać znaku podkreślenia.

    Definiowanie funkcji w przestrzeni globalnej (tzw. "latające funkcje") jest dozwolone, ale odradzane w większości przypadków. Zalecane jest, aby takie funkcje były ujęte w statycznej klasie.

    C.3.4. Zmienne

    Nazwy zmiennych mogą zawierać tylko znaki alfanumeryczne. Znaki podkreślenia są niedozwolone. Użycie liczb w nazwach zmiennych jest dozwolone, ale odradzane w większości przypadków.

    Nazwy zmiennych instancji, które są zadeklarowane używając modyfikatora "private" lub "protected", powinny zaczynać się od znaku podkreślenia. Jest to jedyny dozwolony przypadek użycia znaków podkreślenia w nazwach funkcji. Zmienne klas zadeklarowane jako "public" nie mogą nigdy zaczynac się od znaku podkreślenia.

    Tak jak nazwy funkcji (zobacz powyżej sekcję 3.3), nazwy zmiennych muszą się zawsze zaczynać małą literą i muszą być zgodne z metodą "camelCaps".

    Zalecane jest dobieranie szczegółowych nazw zmiennych. Powinny one być tak szczegółowe, jak to możliwe, aby w pełni opisać dane które programista wewnątrz nich przechowuje. Lakoniczne nazwy zmiennych takie jak "$i" czy "$n" są odradzane, ich użycie jest dopuszczalne tylko w kontekście najkrótszych pętli. Jeśli pętla zawiera więcej niż 20 linii kodu, nazwy indeksów powinny być bardziej opisowe.

    C.3.5. Stałe

    Nazwy stałych mogą zawierać znaki alfanumeryczne oraz znaki podkreślenia. Liczby są dozwolone w nazwach stałych.

    Nazwy stałych powinny składać się tylko z wielkich liter.

    Aby zwiększyć czytelność, słowa w nazwach stałych muszą być oddzielone znakiem podkreślenia. Na przykład, nazwa stałej EMBED_SUPPRESS_EMBED_EXCEPTION jest dozwolona, a nazwa EMBED_SUPPRESSEMBEDEXCEPTION nie jest.

    Stałe muszą być definiowane jako stałe klas przez użycie konstrukcji "const". Definiowanie stałych w przestrzeni globalnej za pomocą konstrukcji "define" jest dozwolone, ale odradzane.

    digg delicious meneame google twitter technorati facebook

    Comments

    Loading...