Bästa PHP-kodstil för WordPress-utvecklare?

Ända sedan vi började programmera med datorer har kodstil varit föremål för stora debatter. En av de mest kända och omdebatterade frågorna, den om kodindrag ska göras med tab eller mellanslag, har till och med nämnts i den populära TV-serien Silicon Valley.

För att samla mer konkreta belägg för diskussionen har StackOverflow genomfört en enkät där man jämförde inkomsterna hos utvecklare som som föredrar tab-indrag och dem som använder mellanslag. Inom detta nästan löjliga ”heliga krig” om bästa kodstil försöker vi här ge vår egen syn på bästa kodstil för PHP när utvecklare skapar tillägg och teman för WordPress.

Med tanke på att de underliggande delarna i WordPress-kärnan är skrivna i PHP är det utan tvekan vettigt att följa WordPress egna kodstandard för PHP när man utvecklar tillägg eller teman för WordPress. Även om vi huvudsakligen följer denna standard i vår egen WordPress-relaterade utveckling finns det vissa egenheter i WordPress kodstandard (WordPress Coding Standards, WPCS) som i vårt tycke inte är lämpliga att följa.

I denna artikel beskriver vi våra egna undantag till WordPress kodstandard för PHP och gör vårt bästa att övertyga även dig att göra likadant.

Indentering med två mellanslag

För indentering föredrar vi att använda två (2) mellanslag i stället för <Tab>, vilket annars är rekommendationen från WordPress:

if ( $something ) {
  $some_variable = 'something';
}

Genom att använda mellanslag säkerställer vi att koden ser ut likadan i alla redigeringsprogram. Och genom att nöja oss med två mellanslag blir indenteringen bekväm även vid multipla indenteringsnivåer, så att koden inte hamnar alltför långt ut till höger. Detta problem är extra påtagligt i mallfiler som innehåller HTML-kod inbakad i filer med PHP-kod eller för annan kod som använder flera indenteringsnivåer.

Det är inte nödvändigt att indentera flera på varandra följande tilldelningar eller en associativ matris till samma nivå:

// FEL ✘
$foo   = 'somevalue';
$foo2  = 'somevalue2';
$foo34 = 'somevalue3';
$foo5  = 'somevalue4';
$foo6  = array(
  'foo1'         => 'bar1',
  'foo223'       => 'bar2',
  'foo123456789' => 'bar3',
);

// RÄTT ✔
$foo = 'somevalue';
$foo2 = 'somevalue2';
$foo34 = 'somevalue3';
$foo5 = 'somevalue4';
$foo6 = array(
  'foo1' => 'bar1',
  'foo223' => 'bar2',
  'foo123456789' => 'bar3',
);

Med så många mellanslag blir det extra arbete när man behöver uppdatera befintlig kod. Om en variabel med ett längre namn skulle läggas in i blocket måste indenteringen uppdateras även för de övriga variablerna, något som i våra ögon inte är vettigt. När du lägger till kod ska du inte tvingas att ändra stilen för befintlig omgivande kod.

När du lägger till kod ska du inte tvingas att ändra stilen för befintlig omgivande kod.

Använd inte för mycket mellanrum

Överdriven användning av horisontella mellanrum borde inte behövas överallt, trots att det föreskrivs av WordPress kodstandard för PHP för att göra koden mer läsbar. Argumentet om bättre läsbarhet är dock ganska subjektivt och kan ifrågasättas, med tanke på att riktlinjerna för kodstil inom de flesta programmeringsspråk och ramverk vanligtvis försöker göra det rakt motsatta: att vara ganska sparsamma med horisontella mellanrum. Till exempel tillåter PSR-2 för PHP, PEP8 för Python och Google JavaScript Style Guide horisontella mellanrum endast på mycket specifika platser.

I detta avseende ligger vi närmare kodstandarden för WordPress, hellre än att helt avstå från mellanrum. Horisontella mellanrum bör verkligen användas, men endast på vissa platser, i syfte att betona vissa saker, snarare än att gå till det extrema och fylla ut koden med mellanrum överallt.

För det första rekommenderar vi att man använder mellanrum före den inledande parentesen och efter den avslutande parentesen för kontrollstrukturerna if, elseif, foreach, for och switch:

foreach ( $items as $item ) {
  if ( $item['type'] === 'book' ) {
    read($item);
  } elseif ( $item['type'] === 'food' ) {
    if ( is_delicious($item) ) {
      eat($item);
    } else {
      throw_away($item);
    }
  } else {
    ...

Anledningen till detta är att det tydligare separerar strukturen från utseendet hos funktionsanrop och förtydligar villkoren, något som gör koden mer lättläst.

Ett enstaka mellanslag bör också användas efter den inledande parentesen och före den avslutande parentesen när en funktion deklareras, det ger bättre läsbarhet:

function some_function( $param1, $param2 = 'something' ) {
  …

Däremot behöver man inte lägga in mellanslag runt parenteser i andra situationer, t.ex. vid funktionsanrop:

// FEL ✘
if ( $b || ( $b && $c ) ) {
  do_something( $a, callback( $b, $c ) );
}

// RÄTT ✔
if ( $b || ($b && $c) ) {
  do_something($a, callback($b, $c));
}

Man behöver inte heller lägga till några mellanslag före och efter index för matriser, även om de utgörs av variabler:

// FEL ✘
$value = $foo[ $bar ];

// RÄTT ✔
$value = $foo[$bar];

Att använda Yoda-villkor, bör du inte

WordPress PHP-kodstandard rekommenderar att man använder Yoda-villkor där det tilldelade värdet skrivs före variabelnamnet. Skälet till detta är att hitta programfel som kan orsakas av att man helt enkelt använder ett enstaka likhetstecken för tilldelning, eftersom man inte kan tilldela en konstant något annat värde, såsom true = $foo eller 'somevalue' = $foo.

Vår erfarenhet är att detta gör koden mycket svårare och tidskrävande att läsa. De fel du kan hitta på detta sätt hittar du ändå med korrekt statisk kodanalys som begränsar tilldelningar till att alltid utgöra det första objektet i en kodrad. Därför menar vi att man bör undvika Yoda-villkor:

// FEL ✘
if ( 'somevalue' === $something ) {
  ...
}

// RÄTT ✔
if ( $something === 'somevalue' ) {
  ...

Automatiserad statisk kodanalys

Kodstil handlar för det mesta bara om vad man personligen föredrar, och därför går det inte att objektivt definiera vilken kodstil som är korrekt. Å andra sidan bör all kod inom ett kodprojekt hålla en enhetlig stil. Alla utvecklare som arbetar med samma kodbas bör använda en gemensam kodstil. Därför är det lämpligt att på något sätt automatiskt kontrollera att kodstilen som en utvecklare levererar stämmer mot den enhetliga stilen. Detta görs vanligtvis med hjälp av statisk kodanalys, där programmets källkod läses som text, utan att köra själva programmet.

Kodstil handlar för det mesta bara om vad man personligen föredrar, och därför går det inte att objektivt definiera vilken kodstil som är korrekt.

För att utföra den statiska kodanalysen använder vi PHP CodeSniffer (PHPCS), för vilken det finns en regeluppsättning för WordPress Coding Standards tillgänglig. Man kan också definiera anpassade regeluppsättningar i en konfigurationsfil. Till exempel har vi i vårt GitHub-filförvar för vårt eget tillägg med öppen källkod, Seravo Plugin, den anpassade konfigurationsfilen phpcs.xml som anger regeluppsättningen WordPress-Extra som bas och sedan lägger till vissa undantag till de reglerna. Vi har även skrivit en separat bloggartikel om PHP CodeSniffer där vi förklarar mer i detalj hur man använder programmet.

Om du använder GitHub som din leverantör av Git-tjänster kan du enkelt köra statisk kodanalys automatiskt för varje commit mot Git genom att lägga till ett verktyg för kontinuerlig integrering (Continuous Integration – CI), såsom Travis CI, i ditt GitHub-repo. Det finns ett exempel på konfiguration för Travis CI och en konfigurationsfil .travis.yml som kör PHP CodeSniffer i vårt alldeles egna tillägg Seravo Plugin.

Vad anser du är den bästa kodstilen för PHP? Vi vill veta vad du tycker, så kommentera gärna här nedan. Utifrån den diskussionen kommer vi att lägga till en grund för en regeluppsättning i vår projektmall för WordPress.