Nyolc ok, hogy használni phpdoc
Nem, ez nem éppen PHP szintaxis. Vagy inkább, hogy nincs kapcsolatban a legtöbb PHP és a PHP értelmező maga soha nem értelmezi. Ez phpdoc-blokk született több mint JavaDoc és alakítjuk phpDocumentor
Amíg mi kódot, hogy ezek a fickók világít:
de próbáld megérteni.
Mindezek a dolgok, mint a neve is mutatja, valamilyen módon kapcsolódik a dokumentációt. Belőle, és kezdődik.
kód dokumentáció
Ha megnézzük az API Reference a kódot az osztály látni fogjuk ugyanezt:
Most már értem, hogy a webhely változik olyan gyorsan, minden alkalommal, amikor frissíti a forrást. Kiderült, hogy ez nem történik meg a kezét, és automatikusan létrehozott kódot keretet.
Tehát már megfogalmazni az első bónusz, hogy megadja nekünk phpdoc-blokk:
Alkalmazás egy: Az a lehetőség, egy parancsot a konzolban, hogy létrehoz dokumentációt minden osztályban, mezők és módszerek a projekt.
De más, mint hogy milyen hasznos a valós életben? Nézzük néhány alkalmazást.
Virtuális területén
A modellben ez hasznos azonos autogeneration osztálya a modell, de amit használnak predstvaleniyah, amelyek nem jelennek meg a dokumentációt?
Például egy osztály nélküli területeken:
és nem világos, hogy van, mint Yii2 veszi az attribútumok táblákat az adatbázisban. Autosubstitution látja, csak a mezők és módszerek az alap osztály ActiveRecord:
És mi területen hangsúlyozza ugyanakkor esküdözött, hogy az objektum nem:
Zamorochitsya tud írni és egy plugin, ami Pars mező az adatbázisból az egyes típusokra. De ez nyilvánvalóan nem könnyű utat.
Most már tudja tetteink és soha nem panaszkodik.
Vagy ha van egy kapcsolat a modell:
A kód segítségével tudjuk használni ezeket egyszerűen mint kategória mezőben. felhasználó és címkék:
De ezeken a területeken az osztályban nincs. Minden működik a virtuális módszerek és a getter. Tehát nincs más választásunk, hogyan kell megadni ezeket pseudofield és típusaik kifejezetten:
Tehát phpdoc blokk előtt az osztály tartalmazhat egy teljes lista, amit az osztály nem.
Alkalmazása a második: Megjegyzés PSEUDOFIELDS osztályban.
A példákban az általunk áttekintett eddig csak a területen. By psevdometodam'll kap később.
Típusai meglévő mezők
Amellett, hogy az osztály blokkot fel lehet használni, és más helyeken.
Tegyük fel, hogy van egy saját mező közelében _user osztály PasswordChangeForm:
És ha mi megmutatjuk, mi van egy modell osztály Felhasználó:
akkor fog működni, mint ez, amit akartunk.
Itt @var kommentárok peredaom egyetlen típus. De általában meg lehet továbbítani a változó nevét, típus vagy mindkettő érvek egyszerre.
Alkalmazása a harmadik: Tip típust a meglévő mezők az osztályban.
visszatérési típus
Hasonlóképpen, ha @return kommentár típusának meghatározása az objektum által visszaadott módszerrel:
hogy ezzel a módszerrel, a rendszer kialakítása fogja érteni, hogy a változó $ user hívása után ez a módszer lesz a modell osztály Felhasználó:
és többé nem esküszik rá mód korábban ismeretlen terhelés és mentse.
Mi van, ha a módszer visszaadja nekünk bármely Felhasználó. vagy null. Ezután át lehet opció egy csövön keresztül:
Az IDE fogja vizsgálni a két esetben.
Alkalmazás negyedik: Tip argumentumtípusoknak és a visszatérési típus az eredmény (ha van ilyen) van eljárások, függvények, eljárások.
Változókat a semmiből
Vagy egy másik lehetőség. Van néhány ötletem, hogy a vezérlő továbbítja a változó $ modellt. Továbbá ez a nézet válik az objektum osztály \ Yii \ web \ View. mely elérhető lesz a $ ez:
De az IDE nem tudja terveinket, így kiemeli a $ this változó és a $ modellt nem határozza meg ezt a fájlt. A helyzet orvoslására, akkor tetszőleges számú Doc-blokk @var kommentár közvetlenül a bemutatása a kód:
Ebben az esetben megadhatja @var az első típus, akkor a változó nevét:
Ennek eredményeként autosubstitution, keresés és automatikus javítás objektum mezők és módszerek fog keresni ezen változók automatikusan.
Alkalmazás öt: azonosítása változók bármilyen módon továbbított kívülről.
A helyettesítési típus
Nem mindig vezérlők és egyéb alkatrészeinek findModel módszer. Azt is gyakran közvetlenül a kódot, hogy végre minden lekérdezés:
Az IDE véget az öröklési lánc podsmotrit kommentár eljárás ActiveRecord :: találni:
és mivel ezek az absztrakt @inheritdoc. megy még nagyobb a kommentárok az azonos módszer a felületet:
és ragasszuk össze mindent.
Az IDE a sor végére:
megérti, hogy azért, mert a lelet módszer kell visszaadnia például az osztály \ Yii \ db \ ActiveQuery és módszereket, és ahol az egyik fogják hívni már ez:
Ahhoz, hogy működjön, azt kell meghatároznia, hogy a változó típusát segítségével Doc-blokk előtt a feladat:
vagy közvetlenül a felhasználás előtt a tárgy:
Célszerű ezt a ciklust a különböző minták:
Alkalmazása Six: A helyettesítés típusú meglévő változók.
És vissza a módszereket.
Csatlakozó szennyeződések
Először megnéztük a virtuális változókat. Tegyük fel, hogy a modell, mi is olyan viselkedést, mint ez:
Elég hozzá a módszer viselkedés modellek:
és ábrázolásai az eredeti kijelző vagy előnézet:
És ne feledjük, hogy az IDE panaszkodik mindent, ami nem az osztályteremben. De segítségével @mixin kommentárokat. amely támogatja IDE PhpStorm és talán másokat is, akkor „keverednek” osztály viselkedése:
és minden módszer getImageFileUrl és mások is elérhető lesz autosubstitution megvan a modell.
De van egy ellentmondás. Amellett, hogy a szükséges eljárások az osztályban viselkedés, és van egy csomó felesleges. Például, segéd- vagy resolveProfilePath createThumbs. nem fogjuk használni.
Ebben az esetben ahelyett, hogy az egész osztály primeshavaniya viselkedés @mixin mi egyszerűen hozzá értelemszerűen csak pár van szükség virtuális módszerek:
Hasonlóképpen, felveheti az aláírás annak bármely munkamódszerek az ő mágikus módszer __call.
Használata hét: meghatározása psevdometodov osztályban.
Programozás Magyarázatok
Emellett könnyű hozzáférést phpDocumentor egyes rendszerek még tovább mentek és jöttek fel saját céljaikra féle kommentárokat. És a programkód keresztül reflexió feldolgozza az adatokat. Hogy legalább az első elérhető példája StackOverflow site:
Hasonlóképpen, akkor kap a $ r-> getMethods (), és feldolgozni ezeket.
Ennek eredményeképpen ez a megközelítés új felhasználását találtuk. Például a Symfony keretrendszer saját jelöléseket (amellett, hogy a konfiguráció egy YAML vagy XML-fájlok) be lehet állítani az azonos szervezetek közvetlenül a kódot:
vagy ugyanazt a routing vezérlők:
És a keret könnyen feldolgozza az adatokat, és cache egy egyszerű PHP-tömbök nem sikerült feldolgozni őket minden alkalommal újra és újra.
Szintén az osztály tesztelés tűnt feliratozással és @group @dataProvider vizsgálatokhoz PHPUnit csomagot.
Ez a megközelítés nem sok köze van az eredeti phpdoc, mert egyszerűen használja az ő ötlete. De míg minden másik nem, és nyugodtan használja a különböző gombokat együtt:
Sok ilyen megközelítése konfigurálása kommentárokat Symfony nem tetszik, mert sérti az egységes felelősség, keverés kód és beállítás egyetlen fájlban. Így használja tetszése.
A nyolcadik oka: A megjelenése szoftver rendszerek támogatása specifikus kommentárokat.
Ezután nem lesz probléma autosubstitution, elírások nem egyezik meg a típusát bizonytalan változók automatikusan átnevezi mezőket vagy módszerek bármely típusú, és más automatikus újratervezés.
Barátkozz az IDE és ez megkönnyíti az életét.
Nos, a fajta, a nyaralás hamarosan, így nem alszik a karácsonyfa: