Nie wiem, czy istnieje standard dla tego, co jest uważane za „sprytny kod", ale myślę, że gdybyś pokazał programistom różne próbki kodu, byliby w stanie go poznać, gdy go zobaczą.
Był taki okres w mojej karierze, że bardzo interesowałem się pisaniem sprytnego kodu. Ale im jestem starszy i im więcej pracuję nad utrzymaniem projektów, tym mniej przejmuję się pisaniem mądrego kodu i tym bardziej jestem zainteresowany pisaniem kodu, który jest przejrzysty i czytany, a tym samym utrzymany.
Sprytny kod jest dla ptaków. Wybacz te głupie kalambury.
Kiedy pracujemy z WordPressem, prawdopodobnie mamy do czynienia z tablicami, zwłaszcza biorąc pod uwagę, że tak wiele elementów wewnętrznych WordPressa jest na nich zbudowanych (tak, istnieją też pewne obiekty, ale tablice są wszechobecne).
Jak zatem wygląda sprytny kod z tablicami w WordPressie w porównaniu z mniej sprytnym kodem? A ponadto, czy powinniśmy unikać pisania sprytnego kodu?
Sprytny kod z tablicami
Funkcje tablicowe są prawdopodobnie jednym z największych zestawów funkcji w PHP.
Oczywiście pisanie sprytnego kodu za pomocą WordPressa wydaje się częściowo pasować do środowiska, prawda? Wcale nie mówię, że jest źle. Mówię tylko, że kiedy masz funkcje w globalnej przestrzeni nazw, które działają z tablicami zwracającymi tablice, zbyt łatwo jest pisać zagnieżdżone wywołania, które ostatecznie wymagają nieco więcej pracy umysłowej, aby przeanalizować, co robi kod.
Jasne, pisanie o tym to jedno, ale może warto przyjrzeć się przykładowi, jak może wyglądać sprytny kod w WordPressie i jak można go zrefaktoryzować.
Przykład
Załóżmy na przykład, że mamy post i aktualizujemy fragment posta, aby usunąć imię i nazwisko zawarte we fragmencie. Kiedy tak się dzieje, niekoniecznie jest to ważne (chociaż delete_user nie jest trudny do wyobrażenia, prawda?)
Od samego początku otrzymujemy:
- identyfikator poczty,
- imię i nazwisko osoby do usunięcia.
Jednym ze sposobów na to byłoby użycie kombinacji array, array_map, explode, array_diff, implode. Wszystko z tego powodu:
- array do utworzenia tablicy osoby (ponieważ jako tablica jest wymagana później),
- array_map do przycinania białych znaków po rozbiciu fragmentu na tablicę,
- array_diff do wyszukiwania ciągów znaków, które pozostały po usunięciu nazwy,
- i imploduj, aby przebudować wynik z powrotem na łańcuch dla post_excerpt.
Okej, więc z tym powiedziawszy, oto przykład tego, jak może wyglądać sprytny kod w WordPressie :
<?php
// Get the excerpt from the incoming post.
$post = get_post( $post_id );
$excerpt = $post->post_excerpt;
/**
* And we update the post content without the information (and we don't need
* paragraph tags).
*/
$event_post->post_excerpt =
apply_filters(
'the_excerpt',
implode( ', ',
array_diff(
array_map(
'trim',
explode( ',', $excerpt) ),
array( $name) ),
),
);Ale to dużo zagnieżdżania i zwykle musimy zacząć od zewnątrz i wiedzieć, co robi każda funkcja, prawda?
Aby to posprzątać, nadal mamy do czynienia z funkcjami wymienionymi powyżej, ale możemy podzielić rzeczy na łatwiejsze do odczytania kroki (wraz z komentarzami do kodu), aby ułatwić przeanalizowanie przez innego programistę.
Być może mogłoby to wyglądać mniej więcej tak :
<?php
// Get the excerpt from the incoming post.
$post = get_post( $post_id );
$excerpt = $post->post_excerpt;
// Remove the name from the array of names in the excerpt.
$to_remove = array( $name );
$names = array_map( 'trim', explode( ',', $excerpt) );
$result = array_diff( $names, $to_remove );
// Now creae the new excerpt.
$new_excerpt = implode( ', ', $result );
/**
* And we update the post content without the information (and we don't need
* paragraph tags).
*/
$event_post->post_excerpt = apply_filters( 'the_excerpt', $new_excerpt );Czy jest to sposób na zrobienie tego? Nie wiem. Ale to sposób na zrobienie tego. I jest to jedna z tych sytuacji, którą łatwiej czytać i śledzić.
Może więc nie jest to pisanie sprytnego kodu w WordPressie, ale nie wiem – ani nie sądzę – to powinno być naszym celem.
Czy powinniśmy dążyć do napisania sprytnego kodu?
Podręcznik WordPressa zawiera następujące informacje:
Ogólnie rzecz biorąc, czytelność jest ważniejsza niż spryt czy zwięzłość.
A następnie przechodzi do podania przykładu. W tym momencie mojej kariery zazwyczaj się zgadzam:
- sprytny kod nie oznacza bardziej wydajnego kodu,
- sprytny kod często zajmuje więcej czasu, aby przeskoczyć przez więcej mentalnych pętli niż pełny kod,
- sprytny kod jest zatem trudniejszy do utrzymania, zwłaszcza gdy przechodzi się do starszej bazy kodu.
Wreszcie, myślę, że różni ludzie mogą uważać, że niektóre kody są bardziej sprytne niż inne, ale jest też taki kod, który wielu z nas uważa za próbę bycia bardziej sprytnym niż nie.
Ostatecznie staraj się pisać kod, niezależnie od tego, jaki chcesz pisać, ale pisz z myślą o innym programiście: Jeśli kiedykolwiek narzekałeś, że fragment kodu jest trudny do rozszyfrowania na pierwszy rzut oka, prawdopodobnie jest on źle napisany lub był staraj się być sprytny. Więc nie bądź tym facetem lub dziewczyną, którzy przekazują pieniądze następnemu programiście.
Zamiast tego staraj się napisać przejrzysty kod i używać komentarzy, gdy jest to konieczne.