[PHP] Podstawy pisania czytelnego kodu

Piszę ten artykuł, ponieważ zauważyłem, że naprawdę wiele początkujących osób nie zwraca na to najmniejszej uwagi.

Zacznijmy od początku. Być może zastanawiasz się dlaczego trzeba dbać o czytelność kodu?

Podstawową zasadą jaką powinieneś przyjąć jest to, że z kodem będą pracować także inni ludzie, a nie tylko Ty. Może do tego dojść choćby przy udzielaniu pomocy na forum lub pisania projektu przez kilka osób. Wtedy czytelność kodu staje się naprawdę ważna, choć uwierz mi, że w momencie kiedy napiszesz naprawdę dużo kodu, bez zwracania uwagi na jego czytelność, to sam bez problemu się w nim pogubisz.

Komentarze
Po to bozia dała chyba praktycznie w każdym języku programowania możliwość komentowania kodu, żeby z niej korzystać. Jak pewnie wiesz, w PHP mamy 3 rodzaje komentarzy.

// komentarz jednolinijkowy

# inny komentarz jednolinijkowy (wywodzący się z Perla)

/* komentarz
wielolinijkowy
może się ciągnąć
w nieskończoność */

Pamiętaj o tym, aby wybrać jeden sposób tworzenia komentarzy jednolinijkowych. W przeważającej większości używa się komentarza //. Komentarze rozpoczynające się od znaku hash #) są już prawie niespotykane, choć część skryptów wykorzystuje je np. do oznaczania sekcji w plikach konfiguracyjnych.

Wcięcia
Ośmielę się napisać, że jest to najważniejsza kwestia jeśli chodzi o czytelność kodu. Porównaj te 2 przykładowe listingi.

if ($petla == true)
{
foreach ($zmienne as $zmienna) {echo strtolower($zmienna); }
} else {
echo 'nie ma pętli';
}

versus

if ($petla == true) { // w tym wypadku lepiej po prostu if ($petla)
    foreach ($zmienne as $zmienna) {
        echo strtolower($zmienna);
    }
}

else {
    echo 'nie ma pętli';
}

Z ułożenia kodu pokazanego na drugim listingu wynika dużo korzyści. Przede wszystkim na pierwszy rzut oka widać, że mamy do czynienia z dwoma warunkami, z czego w pierwszym z nich zawarta jest pętla foreach. Ważne jest to, aby „głębokość” wcięć przy każdym kolejnym poziomie zagnieżdżenia była jednakowa w całym skrypcie.

Nazewnictwo
Kolejna bardzo ważna kwestia. Tutaj liczy się zarówno sposób zapisywania nazw zmiennych, funkcji, klas, metod itd. jak i język w jakim je zapisujemy. Bardzo wielu początkujących zapisuje zmienne w języku polskim. Ponownie przyjrzymy się dwóm przykładom kodu.

$tablica = array(1, 3, 66);
$napis = ‘To prawda’;

if (count($tablica) == 3)
    echo $napis;
$array = array(1, 3, 66);
$text = ‘To prawda’;

if (count($array) == 3)
    echo $text;

Przyznacie chyba, że dużo logiczniej brzmi sekwencja if count array == 3, echo text niż if count talica == 3, echo napis. Skoro instrukcje oraz wbudowane funkcje w języku PHP są w języku angielskim, to nie ma najmniejszego sensu miksować tego z innym językiem i robić bałaganu.

Tutaj zrobię też krótką dygresję do osób, które w tym momencie pomyślały „ale ja nie znam angielskiego. Nie będę się go uczyć, tylko po to, żeby nazwać kilka zmiennych”. Otóż angielski w każdym języku programowania jest językiem podstawowym. Pomijając to, o czym już mówiłem, czyli to, że wszystkie wbudowane instrukcje i funkcje są nazwane po angielsku, niezaprzeczalnym faktem jest, że dużo więcej materiałów na temat programowania jest właśnie w języku angielskim (choćby większość dokumentacji PHP).

Drugą kwestią jest to jak zapisujemy nazwy zmiennych, klas, funkcji, metod itd. Oto niektóre ze sposobów, przedstawię je na przykładzie zmiennej  o nazwie simple var.

echo $simplevar; // totalnie nieczytelne
echo $simple_var ; // metoda pierwsza
echo $simpleVar; // metoda druga (tzw. camelCase)

Oczywiście, że poza tym mamy jeszcze wiele mniej lub bardziej stosowanych sposobów nazewnictwa – chociażby notację węgierską, jednak temu tematowi można by poświęcić spokojnie cały wpis, a ja chciałem jedynie pokazać przykładowe sposoby nazewnictwa.

Zaletami nazywania w stylu $simple_var, jest to, że wszędzie stosowane są tylko małe litery, a PHP rozróżnia je, jeśli chodzi o nazwy zmiennych.

Podsumowanie
Ten artykuł omawia zaledwie zalążek tematu, jednak być  może po jego przeczytaniu łatwiej będzie Wam tworzyć kod łatwiejszy w zarządzaniu. Pamiętajcie, że ważne jest bycie konsekwentnym w decyzjach (zresztą nie tylko w programowaniu…). Kiedy już zdecydujecie się np. na pisanie zmiennych po angielsku, metodą camelCase, to trzymajcie się tego przez cały skrypt, nie róbcie bałaganu i nie utrudniajcie roboty, tym, którzy będą czytać kod po Was.

[Mini] Jakby to było dobrze…

Pierwszy wpis w nowopowstałej kategorii "Mikroblog". Nazwa i prefix wpisu chyba tłumaczą wszystko. Proszę nie spodziewać się zbyt wiele :)

Muszę niektórych rozczarować, to nie będą fantazje erotyczne… To po prostu kilka drobnych myśli, które naszły mnie podczas pisania kolejnej wersji IronCMS-a. Chodzi mi tu o możliwości, które ma wprowadzić HTML5 i PHP6.

Logo HTML 5

Pomyślmy tylko jakby to było pięknie gdyby:

  • zamiast pisać potworki w stylu
    <input onFocus="if (this.value=='Wpisz swój komentarz...') {this.value='';}" onBlur="if (this.value=='') {this.value='Wpisz swój komentarz...'}" [...] />
    
    móc napisać po prostu <input placeholder="Wpisz swój komentarz" ... />
  • praktycznie całą walidację po stronie klienta wykonywać za pomocą takich atrybutów jak required czy pattern (porównywanie tekstu wpisanego z regExem na poziomie HTML-a- marzenie) oraz odpowiednich wartości podanych w type (gdy podamy np. email, to adres zostanie sprawdzony przez browsera)
  • móc nie mieć w PHP takich archaizmów jak safe_mode, register_globals, czy magic_quotes. W większości wypadków są one wyłączone, jednak gdy jest inaczej, to możemy mieć sporo roboty, np. z kasowaniem slashy dodaną przez tego ostatniego "ficzera"
  • nie musieć podawać masy zbędnych atrybutów i tagów takich jak
    • całego długiego doctype w stylu
        <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
      
      gdyż od teraz wystarczy nowe <!DOCTYPE html>
    • deklarowanie kodowania poprzez długaśne <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> - w HTML 5 to <meta charset="UTF-8">
    • oczywiste wartości atrybutu type, takie jak text/css dla arkuszy stylów, czy text/javascript dla plików JS
  • mieć semantyczne tagi dla najczęstszych części strony (header, footer, article, section i spółka). Wyszukiwarki pewnie też odetchnęłyby z ulgą
  • w końcu ujednolicona obsługa filmów na stronach poprzez tag video
  • wiele więcej…

Do tego wszystkiego dorzuciłbym jeszcze jedno nierealne życzenie. Żeby przeglądarki działały jak kompilatory. Nie wybaczały nawet najmniejszych błędów :P

Zdaję sobie oczywiście sprawę, że każdy kto interesował się HTML-em 5, nie znajdzie tu wiele nowego, ale po prostu chciałem się podzielić przemyśleniami. Więc proszę nie bić ;)

Jeśli kogoś to zainteresowało i chciałby poczytać conieco o tym co nas czeka, to mogę polecić ten CheatSheet HTML 5.

PS: Obrazki we wpisach. Czyżby nowy trend na sobak.pl?

Dlaczego HTML5 nic nie zmieni?

Od dłuższego już czasu w internecie występuje ogromne poruszenie pracami nad nową, piątą, wersją HTML-a. Sam też byłem i w sumie po części nadal jestem jego entuzjastą. Miło byłoby gdyby istniał standard pozbawiony wszelkich archaizmów, który wymuszałby poprawne pisanie stron na webmasterach, a internet zmieniłby się w jedną wielką cyfrową sielankę…

Nie no. Oczywiście przesadzam, ale w tym wpisie chciałbym przestawić Wam prosty powód, dla którego tak naprawdę wejście w życie HTML-a 5 niewiele zmieni.

Co z tego, że specyfikacja zabrania używania HTML-a do opisu wyglądu strony (czyli znaczniki takie jak font itd…), że zabrania używania ramek, skoro przeglądarki nadal to wszystko obsługują.

Jako "materiał dowodowy" do tego wpisu posłuży ta prosta strona. Polecam zajrzenie w jej kod. Jest tam sieczka najgorszych znaczników z HTML4 tj. font, center, iframe…

I teraz stawiam główne pytanie: Co z tego, że specyfikacja HTML5 wymusza np. stosowanie wyłącznie CSS-a do opisu wyglądu strony, skoro przeglądarki internetowe tego nie robią?

Już teraz mamy takie przykłady: twórcy wielkich portali szczycą się, że ich strony używają HTML5. Szkoda tylko, że w większości używanie tego standardu kończy się wraz z sekcją head.

Marzy mi się, żeby przeglądarki podchodziły tak rygorystycznie do parsowania HTML-a, jak do XML-a lub jak parser do parsowania PHP. Żeby browser widząc stronę z błędem wyświetlał komunikat na ekranie. Myślę, że dopiero to zmobilizowałoby porządnie "webmasterów" do tworzenia stron zgodnych ze standardami.

Strona z DTD HTML-a piątego z działającymi frame'ami, to nie jest moje marzenie… Wygląda na to, że twórcy stron będą mogli tworzyć sieczkę, z którą będą męczyć się przeglądarki. Zmieni się tylko ilość błędów w walidatorze, o którego istnieniu większość normalnych użytkowników nie ma pojęcia (a szkoda)…