Share
I den här serien tar vi ett djupt dykk i WordPress-kodningsstandarderna - speciellt PHP-kodningsstandarderna - för att evangelisera och förstå hur kvalitet WordPress-kod ska skrivas.
Trots det faktum att detta är dokumenterat i WordPress Developer Handbook, tror jag att det finns något att säga för att förstå motiveringen bakom Varför vissa saker är sättet att de är.
Kom ihåg: Vårt yttersta mål är att se till att vi skriver kod som överensstämmer med kodningsstandarderna så att vi tillsammans med andra utvecklare lättare kan läsa, förstå och behålla kod för teman, plugins och applikationer som är byggda ovanpå WordPress.
I det här inlägget kommer vi att ta en titt på hur man hanterar namngivningskonventioner och funktionsargument.
Innan du spenderar någon tid på att utveckla de punkter som beskrivs i kodningsstandarderna är det viktigt att förstå den roll som namngivningskonventioner spelar i kodning, oberoende av vilken plattform du arbetar med.
I slutändan bör namngivningskonventioner - oavsett om de är för klasser, funktioner, variabler, attribut eller argument - hjälpa till att förklara syftet med att de tjänar.
Däremot menar jag att klassnamn typiskt skulle vara substantiv, funktioner borde typiskt vara verb och variabler, attribut och argument bör förklara syftet med att de tjänar inom ramen för klassen eller funktionen där de ska definieras. Det handlar om att göra koden så läsbar som möjligt.
Precis som kodningsstandarderna anger:
Förkorta inte variabla namn oundvikligen; låt koden vara entydig och självdokumentation.
Det här är en bra tumregel oavsett av vilken del av koden den är på vilken du arbetar.
När det gäller att arbeta med WordPress är det inte troligt att du stöter på klasser om du inte gör något av två saker:
Om du helt enkelt arbetar med temat, är du mer sannolikt att arbeta med en uppsättning funktioner - vi talar om dem tillfälligt.
Men för dem som arbetar med plugins eller egna bibliotek, är det viktigt att komma ihåg att klasser normalt ska vara substantiv - de ska representera syftet att de inkapslar och de borde helst göra en sak och göra det bra.
Till exempel, om du har en klass kallad Local_File_Operations då kan det vara ansvaret för att läsa och skriva filer. Det ska inte vara ansvarigt för att läsa och skriva filer samt att hämta fjärrfiler.
Enligt WordPress-kodningsstandarderna bör klasserna följa följande konventioner:
Enkelt, rätt?
Praktiskt taget skulle det här se ut som följande:
Accentsconagua
klass Local_File_Operations klass Remote_File_Operations klass HTTP_Request klass SQL_Manager Att upprepa: klasser bör också vara substantiv och ska beskriva det enda syfte de tjänar.
Som tidigare nämnts, om klasser är substantiv som idealiskt representerar en enda idé eller enstaka ändamål, bör deras metoder vara de åtgärder som de kan ta. Som sådana borde de vara verb - de bör ange vilka åtgärder som ska vidtas när de kallas.
Dessutom måste argumenten som de accepterar också vara en faktor i funktionens namn. Om en funktion till exempel är ansvarig för att öppna en fil, ska parametern vara ett filnamn. Eftersom vårt mål ska göra det så enkelt som möjligt att läsa kod, borde det läsa något som "har den lokala filhanteraren läs filen med följande filnamn."
I kod kan det här se ut så här:
// Klassdefinitionsklassen Local_File_Manager public function open_file ($ filnamn) // Function implementation // Hur vi skulle använda den här koden $ file_manager = new Local_File_Manager (); $ file_manager-> open_file ('foo.txt'); Naturligtvis täcker detta fortfarande inte på vilket sätt funktioner ska skrivas inom ramen för WordPress utveckling. Kodningsstandarderna:
Använd små bokstäver i variabel-, åtgärds- och funktionsnamn (aldrig
Camelcase). Separata ord via underskrifter. Förkorta inte variabla namn oundvikligen; låt koden vara entydig och självdokumentation.
Konventionens första del är lätt nog att förstå; Men jag tror att utvecklare har en benägenhet att ta genvägar när de kan. "Ah," tror vi, "$ str är meningsfull här och $ nummer meningsfullt här. "
Självklart finns det alltid värre - vissa utvecklare använder sig av enstaka tecken för sina variabla namn (vilket i allmänhet endast är acceptabelt inom loopar.)
Precis som kodningsstandarderna anger: Förkorta inte variabla namn onödigt. Låt koden vara entydig och självdokumentation.
Nu är sanningen, kod kan bara vara entydig till en punkt. Det är ju det som kallas koden, eller hur? Det är därför jag tycker att kodkommentarer ska användas generellt.
Hur som helst, är basen att låsa dina metodnamn, undvik allt kamelhölje, separera med avstånd och vara så specifika som möjligt när du namnger dina variabler.
Variabla namn är faktiskt inte mycket annorlunda än funktionsnamn än de representerar ett enda värde eller en hänvisning till ett visst objekt. Namnkonventionerna följer fortfarande vad du förväntar dig:
En annan konvention som vissa utvecklare använder är vad som är känt som ungerska notation, vilket är var den typ av värde variabla butiker är prefixed framför variabeln.
Till exempel:
$ str_firstname $ i_tax eller $ num_tax $ arr_range Ärligt talat säger kodningsstandarden ingenting om detta. Å ena sidan tror jag att det här gör renare kod i det övergripande räckviddet av kod, men det finns många utvecklare som inte tycker om den ungerska notationen.
Eftersom kodningskonventionerna inte säger något om dem, är jag tveksam till att rekommendera dem eftersom jag vill stanna så nära standarder som möjligt. Som sådan måste jag rekommendera att det är bäst att följa kodningsstandarderna.
I överensstämmelse med temat att göra vår kod så läsbar och självdokumentativ som möjligt är det meningsfullt att vi drar detta genom vår källkod hela vägen till de filer som vi ska göra upp på vårt tema, plugin eller Ansökan.
Enligt kodningsstandarderna:
Filer ska benämnas beskrivande med små bokstäver. Hyphens bör separera ord.
I överensstämmelse med vårt tidigare exempel, låt oss säga att vi jobbar med Local_File_Operations då skulle filen vara namngiven klass lokal-file-operations.php.
Lätt nog.
Därefter, om du arbetar med ett plugin som heter Instagram_Foo då ska filen namnges instagram-foo.php; Det är dock värt att notera att om du använder någon typ av avancerade metoder för att utveckla dina plugins, t.ex. att hålla plugin-klassfilen i sin egen fil och sedan ladda den med en annan fil, kan din filstruktur vara:
klass-instagram-foo.phpinstagram-foo.phpVar instagram-foo.php ansvarar för att ladda klass-instagram-foo.php. Det här är givetvis bara meningsfullt om du använder OOP när du skriver dina WordPress-plugins.
När det gäller att överföra funktionsargument är det viktigt att komma ihåg att om funktionsnamn beskriver de åtgärder som tas av klassen, så ska argumentet representera vad funktionen faktiskt driver.
Från kodningsstandarderna:
Föredra strängvärden till bara
Sannochfalsknär du ringer funktioner.
Eftersom booleska värden kan vara oklara när man överför värden till en funktion, gör det svårt att fastställa exakt vad funktionen gör.
Till exempel, låt oss använda ovanstående exempel på ett något annorlunda sätt:
// Klassdefinitionsklassen Local_File_Manager public function manage_file ($ filnamn, true) if (true) // Öppna filen annat // Ta bort filen // Hur vi använder den här koden $ file_manager = nytt Local_File_Manager (); $ file_manager-> manage_file ('foo.txt', true); Är svårare att förstå än något annat:
// Klassen definition klass Local_File_Manager public function open_file ($ filnamn) // öppna filen public function delete_file ($ filnamn) // ta bort filen // Hur vi skulle använda den här koden $ file_manager = new Local_File_Manager (); $ file_manager-> open_file ('foo.txt'); $ file_manager-> delete_file ('foo.txt'); Därtill, kom ihåg att argument som överförs till funktioner är fortfarande variabler i sig själva så att de omfattas av de variabla namngivningskonventionerna som vi har beskrivit ovan.
Vi har tagit en längre titt på namngivningskonventioner och funktionsargument i kodningsstandarderna. Förhoppningsvis har det hjälpt till att ge inte bara en guide för hur man förbättrar vissa aspekter av din WordPress-kod, men också för att förklara motiveringen bakom vissa av de metoder.
I nästa artikel kommer vi att ta en titt på betydelsen av enkla citat och dubbla citat inom ramen för att arbeta med strängar i WordPress utveckling.
där är en skillnad i hur de tolkas av PHP och det finns villkor där du ska använda en över varandra och vi kommer att se över det i nästa artikel.
