Share
In deze serie duiken we diep in de WordPress-coderingsstandaarden - met name de PHP-coderingsnormen - om te evangeliseren en te begrijpen hoe de kwaliteit van de WordPress-code moet worden geschreven.
Ondanks het feit dat dit wordt gedocumenteerd in het handboek van WordPress Developer, denk ik dat er iets te zeggen valt over het begrijpen van de redenering achter waarom sommige dingen zijn zoals ze zijn.
Vergeet niet: ons uiteindelijke doel is ervoor te zorgen dat we code schrijven die voldoet aan de coderingsnormen, zodat we samen met andere ontwikkelaars gemakkelijker code kunnen lezen, begrijpen en onderhouden voor thema's, plug-ins en toepassingen die zijn gebouwd bovenop WordPress.
In dit bericht gaan we kijken hoe we conventies voor naamgeving en functieargumenten moeten afhandelen.
Voordat u enige tijd besteedt aan het uitwerken van de punten die in de coderingsstandaarden worden geschetst, is het belangrijk om de rol te begrijpen die naamgevingsconventies spelen bij het schrijven van code, ongeacht het platform waarmee u werkt.
Uiteindelijk moeten conventies voor naamgeving - ongeacht of ze voor klassen, functies, variabelen, attributen of argumenten zijn - helpen om het doel dat ze dienen te verduidelijken..
Daarmee bedoel ik dat klassenamen meestal zelfstandige naamwoorden zijn, dat functies meestal werkwoorden moeten zijn, en dat variabelen, attributen en argumenten het doel moeten verklaren dat ze dienen in de context van de klasse of functie waarin ze moeten worden gedefinieerd. Het gaat erom de code zo leesbaar mogelijk te maken.
Net zoals de coderingsnormen vermelden:
Afkorting van variabelenamen niet noodzakelijkerwijs afkorten; laat de code ondubbelzinnig zijn en zelfdocumenteren.
Dit is een goede vuistregel achteloos van welk deel van de code waarop je werkt.
Als het gaat om werken met WordPress, kom je waarschijnlijk geen lessen tegen tenzij je een van de twee dingen doet:
Als u alleen aan het thema werkt, werkt u waarschijnlijk eerder met een reeks functies - we zullen het hier even over hebben.
Maar voor degenen die met plug-ins of hun eigen bibliotheken werken, is het belangrijk om te onthouden dat klassen typisch zelfstandige naamwoorden moeten zijn - ze moeten het doel weergeven dat ze inkapselen en ze zouden idealiter één ding moeten doen en het goed doen.
Bijvoorbeeld als u een klasse hebt genaamd Local_File_Operations dan is het misschien verantwoordelijk voor het lezen en schrijven van bestanden. Het zou niet verantwoordelijk moeten zijn voor het lezen en schrijven van bestanden en, bijvoorbeeld, het ophalen van externe bestanden.
Volgens de WordPress coderingsstandaarden moeten klassen de volgende conventies volgen:
Eenvoudig, toch?
Praktisch gezien zou dit er als volgt uitzien:
Accentsconagua
class Local_File_Operations class Remote_File_Operations klasse HTTP_Request class SQL_Manager Om te herhalen: klassen moeten ook zelfstandige naamwoorden zijn en het enige doel beschrijven dat ze dienen.
Zoals eerder vermeld, als klassen zelfstandige naamwoorden zijn die idealiter één enkel idee of een enkel doel vertegenwoordigen, moeten hun methoden de acties zijn die ze kunnen uitvoeren. Als zodanig moeten het werkwoorden zijn; ze moeten aangeven welke actie zal worden ondernomen wanneer ze worden gebeld.
Bovendien moeten de argumenten die zij accepteren ook een rol spelen in de naam van de functie. Als een functie bijvoorbeeld verantwoordelijk is voor het openen van een bestand, moet de parameter een bestandsnaam zijn. Aangezien ons doel het zo gemakkelijk mogelijk zou moeten maken om code te lezen, zou het iets moeten lezen als "laat de lokale bestandsbeheerder het bestand lezen dat de volgende bestandsnaam heeft."
In code ziet dit er ongeveer zo uit:
// De klassendefinitieklasse Local_File_Manager openbare functie open_file ($ bestandsnaam) // Functie-implementatie // Hoe we deze code zouden gebruiken $ file_manager = new Local_File_Manager (); $ file_manager-> open_file ('foo.txt'); Natuurlijk dekt dit nog steeds niet hoe functies moeten worden geschreven binnen de context van WordPress-ontwikkeling. De coderingsstandaards staat:
Gebruik kleine letters in variabelen, actie- en functienamen (nooit
camelCase). Aparte woorden via onderstrepingstekens. Afkorting van variabelenamen niet noodzakelijkerwijs afkorten; laat de code ondubbelzinnig zijn en zelfdocumenteren.
Het eerste deel van de conventie is eenvoudig genoeg om te begrijpen; Ik denk echter dat ontwikkelaars geneigd zijn snelkoppelingen te maken wanneer ze daartoe in staat zijn. "Ah", denken we, "$ str is logisch hier, en $ number is hier logisch. "
Natuurlijk zijn er altijd erger - sommige ontwikkelaars nemen hun toevlucht tot het gebruik van enkele karakters voor hun variabele namen (wat over het algemeen alleen aanvaardbaar is binnen loops.)
Net zoals de coderingsnormen vermelden: De variabelenamen niet afkorten un-se. Laat de code ondubbelzinnig zijn en zelfdocumenteren.
De waarheid is dat code maar tot op zekere hoogte eenduidig kan zijn. Dat is tenslotte de reden waarom het code wordt genoemd, toch? Dit is de reden waarom ik denk dat codeacties royaal moeten worden gebruikt.
Hoe dan ook, de bottom line is om de namen van je methodes te verkleinen, alle kamelenomhulsel te vermijden, gescheiden door spaties en zo specifiek mogelijk te zijn bij het benoemen van je variabelen.
Variabelenamen verschillen eigenlijk niet veel van andere functienamen dan dat ze een enkele waarde vertegenwoordigen of een verwijzing naar een bepaald object. De naamgevingsconventies volgen nog steeds wat u zou verwachten:
Een andere conventie die sommige ontwikkelaars gebruiken, is wat bekend staat als Hongaarse notatie. Dit is waar het type waarde dat de variabele winkels hebben, voor de variabele wordt voorafgegaan.
Bijvoorbeeld:
$ str_firstname $ i_tax of $ num_tax $ arr_range Eerlijk gezegd, zeggen de coderingsnormen hier niets over. Aan de ene kant denk ik dat dit zorgt voor schonere code in het totale bereik van de code, maar er zijn veel ontwikkelaars die een hekel hebben aan de Hongaarse notatie.
Omdat de coderingsconventies niets over hen zeggen, aarzel ik ze om ze aan te bevelen, want ik wil zo dicht mogelijk bij de normen blijven. Als zodanig moet ik aanbevelen dat het het beste is om de coderingsnormen te volgen.
In overeenstemming met het thema om onze code zo leesbaar en zelfdocumenterend mogelijk te maken, is het logisch dat we deze door onze broncode halen, helemaal naar de bestanden die we gaan maken van ons thema, plug-in of toepassing.
Volgens de coderingsnormen:
Bestanden moeten beschrijvend worden benoemd met behulp van kleine letters. Hyphens moeten woorden scheiden.
Laten we zeggen dat we werken om in overeenstemming te blijven met ons vorige voorbeeld Local_File_Operations dan zou het bestand een naam krijgen class-local-file-operations.php.
Makkelijk genoeg.
Vervolgens, als u werkt aan een plugin genaamd Instagram_Foo dan moet het bestand een naam krijgen Instagram-foo.php; het is echter de moeite waard om op te merken dat als u een aantal geavanceerde methoden gebruikt voor het ontwikkelen van uw plug-ins, zoals het houden van het klassebestand van de plug-in in zijn eigen bestand en het dan te laden met een ander bestand, dan kan uw bestandsstructuur zijn:
class-Instagram-foo.phpInstagram-foo.phpWaar Instagram-foo.php is verantwoordelijk voor het laden van de class-Instagram-foo.php. Dit is natuurlijk alleen logisch als u OOP gebruikt bij het schrijven van uw WordPress-plug-ins.
Als het gaat om het doorgeven van functieargumenten, is het belangrijk om te onthouden dat als functienamen de acties beschrijven die door de klasse worden uitgevoerd, het argument moet weergeven wat de functie eigenlijk doet.
Van de coderingsnormen:
Geef de voorkeur aan tekenreekswaarden op recht
waarenvalsbij het aanroepen van functies.
Aangezien booleaanse waarden onduidelijk kunnen zijn bij het doorgeven van waarden aan een functie, is het moeilijk om vast te stellen wat de functie precies doet.
Laten we het bovenstaande voorbeeld bijvoorbeeld op een enigszins andere manier gebruiken:
// De klassedefinitie klasse Local_File_Manager public function manage_file ($ bestandsnaam, true) if (true) // Open het bestand else // Verwijder het bestand // Hoe we deze code $ file_manager gebruiken = nieuwe Local_File_Manager (); $ file_manager-> manage_file ('foo.txt', waar); Is moeilijker te begrijpen dan, laten we zeggen, zoiets als dit:
// De klassendefinitieklasse Local_File_Manager openbare functie open_file ($ bestandsnaam) // open het bestand public function delete_file ($ filename) // verwijder het bestand // Hoe we deze code zouden gebruiken $ file_manager = nieuw Local_File_Manager (); $ file_manager-> open_file ('foo.txt'); $ file_manager-> delete_file ('foo.txt'); Vergeet bovendien niet dat argumenten die worden doorgegeven aan functies nog steeds variabelen zijn en daarom zijn ze onderhevig aan de variabelen voor naamgevingsconventies die we hierboven hebben beschreven.
We hebben uitgebreid aandacht besteed aan het benoemen van conventies en functieargumenten in de coderingsstandaarden. Hopelijk heeft dit ertoe bijgedragen niet alleen een handleiding te bieden voor het verbeteren van bepaalde aspecten van uw WordPress-code, maar ook om de reden achter sommige van de praktijken te verklaren.
In het volgende artikel gaan we kijken naar de betekenis van enkele aanhalingstekens en dubbele aanhalingstekens in de context van het werken met strings in WordPress-ontwikkeling.
Er is een verschil in hoe ze worden geïnterpreteerd door PHP en er zijn omstandigheden waarin je de ene boven de andere moet gebruiken en we zullen dat in het volgende artikel bekijken.
