Wyszukiwarka
Aby odnaleźć interesujące Cię informacje wpisz poniżej szukane frazy:
Logowanie
Zaloguj się aby zobaczyć swój profil:
Top 10
Dziesięć najczęściej czytanych artykułów
Przedstawiam tłumaczenie/streszczenie artykułu Another 7 deadly sins for PHP . Warto nadmienić, iż podobnych grzechów jest znacznie więcej i winny one być stopniowane w zależności od ilości wiedzy posiadanej przez programistę. Powyższe błędy dotyczą "programatorów" średniozaawansowanych.
Często zdarza się, że nasze aplikacje wymagają ustawienia pewnych zmiennych, pełniących rolę opcji konfiguracyjnych. Wielu programistów tworzy takie zmienne za pomocą "define", co nie jest najlepszym rozwiązaniem. W przypadku gdy ilość opcji jest duża, w kodzie szybko pojawia się poważny bałagan. Nie jesteśmy w stanie np. stwierdzić gdzie dana zmienna zostaje nadpisana. Poza tym stosowanie "define" jest niewłaściwe z tych samych powodów, dla których nie powinno się nadużywać zmiennych globalnych. O wiele lepszym podejściem jest umieszczenie konfiguracji w tablicy asocjacyjnej i utworzenie klasy, która pozwoli na pobranie dowolnej opcji w dowolnym momencie. Użycie "define" jest uzasadnione w nielicznych przypadkach, np. określanie ścieżki dostępu do części systemu.
Struktura katalogów w przypadku wielu aplikacji internetowych jest chaotyczna i niezaplanowana. Znalezienie wybranego fragmentu kodu nie jest wtedy szybkie i łatwe. Gruntownie przemyślane drzewo katalogów uchroni nas przed taką sytuacją, a ponadto nasz kod zyska na modularności. Przy nazywaniu kolejnych podkatalogów można zastosować jedną ze sprawdzonych konwencji jak na przykład ta pochodząca z technologii PEAR: klasa Aaaa_Bbbb_Cccc umieszczona w pliku Aaaa/Bbbb/Cccc.php
Mnóstwo programistów stosuje niekonwencjonalne lub niepraktyczne nazwy plików (np. rozszerzenie .inc). Wiele edytorów ma problemy z obsługą takich plików - nie działa podświetlanie składni, autouzupełnianie kodu itp. Trudności z poprawnym rozpoznaniem tych plików może mieć również serwer www. Z pewnością nie ucieszysz się gdy skrypty php zostaną wyświetlone w przeglądarce jako zwykły tekst.
W wielu przypadkach można zauważyć nieuzasadnioną tendencję do pisania całej aplikacji od podstaw. Nie jest to dobre podejście jeśli zależy nam na wysokiej jakości produktu końcowego. Zalecane jest wykorzystanie jednego z wielu dostępnych frameworków mvc (np. Zend), oraz wybranych bibliotek, które ułatwią nam rozwiązanie danego problemu. Komponenty takie są z reguły projektami dojrzałymi, w których brał udział niejeden doświadczony programista. Na korzyść gotowych rozwiązań z pewnością przemawia również fakt, iż wiele osób przed nami zdążyło je już przetestować i ewentualnie poprawić.
Jeśli zamierzasz zamieścić na forum lub blogu fragmenty swojego kodu, upewnij się przedtem, że jest on dopracowany. W przeciwnym przypadku Twój kod nie przyniesie nikomu większego pożytku. Jeśli skrypty będą czytane przez początkujących programistów, przejmą oni część Twoich niezalecanych praktyk. Może się również zdarzyć, że Twoje skrypty będzie przeglądał potencjalny pracodawca, który będzie wyczulony na wszelkie nieprawidłowe techniki programowania.
Od wersji 5 php daje możliwość pisania kodu w pełni obiektowego i nie ma żadnych poważnych powodów dla których programiści mieli by stosować paradygmat programowania strukturalnego. Jeśli jesteś osobą nie do końca zaznajomioną z programowaniem obiektowym możesz przejściowo pisać metody statyczne i wywoływać je jak zwykłe funkcje. Z czasem powinieneś dostrzec i zrozumieć zalety obiektowości.
Jednym z najgorszych błędów początkującego programisty php jest zamieszczanie kodu php i html w jednym pliku. Logika takiej aplikacji nie jest rozdzielona od części odpowiedzialnej za wygląd strony. Ponadto, zdecydowanie lepiej jest zgromadzić wszystkie potrzebne dane zanim przystąpimy do ich wyświetlania. Jeśli po drodze wystąpi błąd, zamiast fragmentu strony będziemy zawsze mogli wyświetlić komunikat o błędzie. Najprostrzym rozwiązaniem omawianego problemu jest skorzystanie z wybranego systemu szablonów.
"Nie jest to dobre podejście jeśli zależy nam na wysokiej jakości produktu końcowego. Zalecane jest wykorzystanie jednego z wielu dostępnych frameworków mvc (np. Zend), oraz wybranych bibliotek, które ułatwią nam rozwiązanie danego problemu."
Nie zgodzę się z postawioną tu tezą. Uważam, że każdy programista PHP powinien zacząć od pisania projektów od podstaw i "zaliczyć" ich kilka. Dopiero wtedy może przejść do używania np frameworków. W przeciwnym razie niczego się nie nauczy poza składaniem aplikacji z gotowych klocków. W szczególności nie będzie wiedział po co i dlaczego to działa tak a nie inaczej.
Jeśli to jest 7 głównych grzechów to jesteśmy w niebie. Jeśli grzechem jest rożne nazewnictwo katalogów czy używanie stałych, a nie obiektów i zmiennych do konfiguracji. No to wszyscy chyba do raju idziemy.
Jedynie można by się zgodzić z jednym, z nazewnictwem plików. a też nie do końca bo chodzi jedynie o rozszerzenia plików. Troche bardzo naciągane te grzechy :)
No i jak widać po komentarzach, z stosowaniem obiektowego podejścia jest problem.
Co z tego, że nie ma namespace, przecież same obiekty zamykają pewną funkcjonalność w spójną całość, aby było łatwiej operować i nie szukać w gąszczu funkcji.
Piszecie po co używać obiektowości w prostych rzeczach, a ja się pytam co ona komplikuje, bo jakoś nie widzę aby coś utrudniała, a raczej zwiększa czytelność kodu.
(trochę mnie irytuję, że swoje racja niektóre osoby popierają tym, że piszą w innych językach programowania, jakby PHP to był jakimś najgorszym)
Zgodzę się co do jednego, że ludzie potrafią pisać w PHP funkcjonalność, którą już oferuje język.
Zabrakło moim zdaniem ważnego grzechu :
Implementowanie niskopoziomowych operacji. PHP jest ograniczonym językiem, nie kodujemy w nim zasadniczo algorytmów. np. jak jest coś do zrobienia z tablica to zagladamy do podrecznika, do działu "Array Functions" i stosujemy gotowca.
Jak zauważyli przedpiscy niektore grzechy są trochę naciągane. Mieszanie kodu HTML i PHP to nie to samo co mieszanie logiki z trescia. Strukturalny pardygmat programowania i tak bedzie siedzial np. w kodzie metod klas, a sama obiektówka w malutkich projektach to przerost formy nad treścią. Upublicznianie niedopracowanego kodu - może autor siedzi w towrzystwie blogerów, ale większość programistów nie uzewnetrznia się na potege. Głównie zapaleńcy i lanserzy.
Pisanie kodu obiektowego jest zalecane i powinno być używane. Dlaczego ? bo pozwala to na łatwiejszą kontrolę kodu. W PHP jest ten problem że stworzona klasa aby być widoczna w całej aplikacji musi być odpowiednio umieszczona w hierarchi plików, to samo jest z kodem strukturalnym dlatego wielu programistom PHP wydaje się zbędna obiektowość w tym języku jednakże wystarczyłoby, aby aplikacje zaczęły korzystać z przestrzeni nazwa (coś na wzór tych z C++) lub paczek jak te w JAVA i język stał by się niezwykle wygodny w użyciu. Zanim ktoś skrytykuje tą wypowiedź wyjaśniam, że oprócz PHP programuję także w innych językach i moja wypowiedź może być baaardzo stronnicza...
Z tym pisaniem kodu strukturalnego to nie jest tak do konca zle - wazne zeby kod byl dobrze zorganizowany, obiektowy byc nie musi. Ja za jeden z glownych grzechow programistow PHP uznaje stostowanie paradygmatu obiektowego zawsze i wszedzie - nawet tam gdzie to niepotrzebne.
Ostatni punkt jest fatalnie sformulowany. Chodzi o mieszanie kodu logiki i kodu prezentacji, a nie HTML i PHP. Bo przeciez wspomniany wczesniej ZF w widokach dokladnie to robi :)
|
|
eZ publish Content Management System
