Standardy kodowania zgodne z Zend, cz. 2/3

W drugiej części napi­szę co nieco na temat nazew­nic­twa klas i metod. Jak nazy­wać i czego unikać. Do tego na koniec dodam kilka zale­ceń Roberta C. Martina z Czystego Kodu.1

Klasy

Skład­ni­kiem nazwy klasy nie powi­nien być żaden czasow­nik. Mało tego, nie powi­nien to być również frag­ment nazwy imple­men­to­wa­nego inter­fejsu lub klasy nadrzęd­nej. Stosu­jemy Camel­Case począw­szy od dużej litery. Zgod­nie z Czystym Kodem lepsza jest dłuż­sza nazwa klasy/metody niż krót­sza plus komen­tarz wyjaśniający.

W przy­padku progra­mo­wa­nia zgod­nego z Zend nale­ża­łoby nazwę poroz­dzie­lać podkreśl­ni­kami prowa­dzą­cymi przez struk­turę kata­lo­gów do pliku zawie­ra­ją­cego kod klasy, np. Zend_File_Transfer_Adapter_Http

Pola klas

Krót­kie nazwy zmien­nych typu $i, $j dopusz­czalne są tylko w pętlach lub zmien­nych lokal­nych. Pola klasy również nazy­wamy zgod­nie z Camel­Case z tym, że rozpo­czy­namy od małej litery. Warte zwró­ce­nia uwagi jest to, że pola i metody prywatne w klasie rozpo­czy­nają się od znaku podkre­śle­nia, dzięki czemu od razu widać czy odwo­łu­jemy się do metody publicz­nej czy prywatnej.

Nazwę stałych tworzymy wyłącz­nie za pomocą dużych liter i podkreśl­ni­ków. Poni­żej przy­kład wzięty z Zend_Filter
const CHAIN_APPEND  = 'append';
const CHAIN_PREPEND = 'prepend';

Metody

Przy­jęło się kilka konwen­cji jeżeli chodzi o nazew­nic­two metod. Metody muta­to­rów (tzw. settery) i akce­so­rów (tzw. gettery), czyli usta­wia­jące i pobie­ra­jące zmienne obiektu tworzymy poprzez setNazwa($nazwa)getNazwa().

Innymi powszech­nie znanymi meto­dami są isNazwa()hasNazwa(). Czyli czy obiekt jest czymś lub czy obiekt ma jakąś własność. Muszą one zwra­cać wartość typu boolean.

Pamię­tamy o tym, że PHP oferuje ogra­ni­czone typo­wa­nie para­me­trów. A w tym zakre­sie, jakie oferuje należy je stoso­wać, czyli możemy wymu­sić, że przyj­miemy tylko obiekt okre­ślo­nego typu lub imple­men­tu­jący okre­ślony inter­fejs, czyli np. metoda(Trąbka $trąbka) wymusi nam, że obiekt musi być typu Trąbka. Niestety typów prostych typu int czy bool nie możemy wymu­sić. Zamiast tego pamię­tamy zazna­czyć typ w dokumentacji.

W Zend powszech­nie stoso­wany jest rozdział tworze­nia obiektu od jego inicja­li­za­cji za pomocą metody init(). Jeżeli na etapie tworze­nia obiektu coś się wysy­pie i konstruk­tor wyrzuci wyją­tek, obiekt nie zosta­nie utworzony.

Poni­żej kilka zale­ceń z Czystego Kodu doty­czące metod:

  • metoda powinna zajmo­wać do ok. 20 linii kodu,
  • powinna wyko­ny­wać jedną operację,
  • metoda bez para­me­trów jest zawsze lepsza niż z jednym,
  • dopusz­czalne jest do 3 para­me­trów w meto­dzie; jeżeli jest więcej tzn. że gdzieś popeł­ni­li­śmy błąd,
  • para­metr true/false najczę­ściej ozna­cza, że metoda robi dwie różne rzeczy i najle­piej rozdzie­lić ją na dwie osobne,
  • doda­wa­nie „na pałę” do każdego pola prywat­nego settera i gettera mija się z celem (po co było usta­wiać zmienną na private skoro i tak można robić z nią co się chce poprzez settery/gettery),
  • bloków try/catch nie należy mieszać z normal­nym prze­twa­rza­niem, należy je wydzie­lić do osob­nych funk­cji jako mają­cych za zada­nie obsługę błędów
  1. R. C. Martin : Czysty Kod. Gliwice : Helion, 2010

Podobne wpisy:

  1. Stan­dardy kodo­wa­nia zgodne z Zend, cz. 1/3
  2. Stan­dardy kodo­wa­nia zgodne z Zend, cz. 3/3
  3. Wygrze­bane z GitHuba (3) : Validation
  4. Zend_Date i Zend_Config w Zend Framework

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.

Możesz użyć następujących tagów oraz atrybutów HTML-a: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <p> <pre lang="" line="" escaped=""> <q cite=""> <strike> <strong>