Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

> Eleganckie pisanie kodu
kufalo
post
Post #1





Grupa: Zarejestrowani
Postów: 251
Pomógł: 2
Dołączył: 24.08.2005

Ostrzeżenie: (0%)
-----


  1. <?
  2.  
  3. var_dump($_COOKIE['sdfsdfsdf']); // Notice
  4.  
  5. var_dump(@$_COOKIE['sdfsdfsdf']);
  6.  
  7. var_dump(isset($_COOKIE['sdfsdfsdf'])?$_COOKIE['sdfsdfsdf']:NULL);
  8.  
  9. ?>


Witam, przyklad pierwszy zwraca Nottce'a. Mozna sie przed nim 'zabezpieczyc' stosujac ktorych z nastepnych dwoch sposobow....

Ale czy warto pisac aplikacje uzywajac tych 'zabezpieczen' aby chodzila bezblednie na pelnym raportowaniu bledow, czy dac sobie spokoj??

Jakie jest Wasze zdanie??
Go to the top of the page
+Quote Post
 
Start new topic
Odpowiedzi (1 - 10)
Abaddor
post
Post #2





Grupa: Zarejestrowani
Postów: 65
Pomógł: 9
Dołączył: 30.06.2009

Ostrzeżenie: (0%)
-----


Zależy od strony. Jak jakiś mały blog, albo coś malutkiego to w sumie nie wiem czy warto. Przy większych projektach na pewno warto. Tam jeden błąd może posypać cały serwis.
Go to the top of the page
+Quote Post
vokiel
post
Post #3





Grupa: Zarejestrowani
Postów: 2 592
Pomógł: 445
Dołączył: 12.03.2007

Ostrzeżenie: (0%)
-----


Błędy notice można ignorować, są to, jak sama nazwa wskazuje tylko powiadomienia. Czyli małe wskazówki informujące np o tym, żeby przed wyświetleniem zawartości zmiennej najpierw sprawdzić czy ta zmienna istnieje itd. W wielu przypadkach jest to zbędne, powoduje tylko nadmiarowość kodu. Czasem owszem, można coś zauważyć wartego poprawy.

Co innego inne, te już trzeba obsłużyć, ich się nie ukrywa poprzez użycie @.

Dlatego w środowisku testowym (w przeciwieństwie do finalnego) raportowanie błędów należy włączyć (niekoniecznie z E-NOTICE).


--------------------
Go to the top of the page
+Quote Post
l0ud
post
Post #4





Grupa: Zarejestrowani
Postów: 1 387
Pomógł: 273
Dołączył: 18.02.2008

Ostrzeżenie: (0%)
-----


Problemy tego typu znikają po napisaniu swojej klasy do obsługi takich zmiennych, w której przewiduje się przypadek ich nieistnienia tongue.gif

A używanie niezadeklarowanych zmiennych to bardzo zły nawyk...


--------------------
XMPP: l0ud@chrome.pl
Go to the top of the page
+Quote Post
Zyx
post
Post #5





Grupa: Zarejestrowani
Postów: 952
Pomógł: 154
Dołączył: 20.01.2007
Skąd: /dev/oracle

Ostrzeżenie: (0%)
-----


Na pewno warto raportowanie błędów E_NOTICE mieć włączone. Choć PHP teoretycznie dopuszcza odwołania do nieistniejących zmiennych, w dobrze napisanym kodzie nieistniejące zmienne pojawiają się w 99% przypadków wskutek pomyłki/literówki podczas pisania. Odwołania do nieistniejących elementów tablicy w większości przypadków wynikają z zapomnienia o uwzględnieniu warunków brzegowych lub pomyłki przy pisaniu algorytmu. Odwołania do nieistniejących pól obiektu przy braku zdefiniowanych metod __get() oraz __set() to błąd w sztuce smile.gif.

Jak widać, nie są to błędy same w sobie, ale najczęściej są wynikiem błędów podczas programowania/implementacji, co oznacza, że zdecydowanie nie powinny one się w ogóle pojawiać. W szczególności karygodne jest, aby pojawiały się one przy odwołaniach do tablic $_GET/$_POST itd. - jest to wręcz zaproszenie do próby włamania się do serwisu, już nie wspominając o tym, że ujawniają one wewnętrzne ścieżki systemowe, co z kolei może być pomocne przy próbie włamania się na serwer.

Pamiętanie o sprawdzaniu istnienia zmiennych oraz definiowaniu ich początkowej wartości należy do dobrych zwyczajów i pozwala pisać bardziej idiotoodporny kod. Zwracam tu uwagę, że nie trzeba we wszystkich możliwych miejscach wstawiać if(isset()) itd., lecz po prostu myśleć. W dobrze napisanym systemie o jasnym przepływie sterowania można sobie bardzo ułatwiać życie korzystając z faktu, że jeśli coś sprawdzimy na początku jakiegoś kawałka kodu, to możemy mieć pewność, że w dalszej jego części będzie to dalej spełnione. Na dodatek dzięki temu możemy wykorzystać E_NOTICE w jeszcze lepszym celu. Jeśli gdzieś się pojawi, traktujemy to jako błąd podczas programowania (jakaś niejasność w kodzie, luka lub przejście, które łamie zasady) i już na etapie tworzenia kodu możemy dążyć do jego wyeliminowania.

W moim kodzie do nieistniejących zmiennych wolno odwoływać się tylko po spełnieniu zespołu warunków:

1. Doskonale wiemy, co robimy i mamy świadomość konsekwencji.
2. Nie ma innej, eleganckiej możliwości wyrażenia tego samego.
3. Obniżymy poziom raportowania błędów przez error_reporting(), a po wyjściu z sekcji krytycznej przywrócimy poprzedni.
4. Odwoływanie się dotyczy zmiennych, które są w całości wytworem skryptu, nigdy - danych pochodzących z żądania HTTP lub w jakikolwiek inny sposób z zewnątrz.

W praktyce taka sytuacja wystąpiła u mnie RAZ.

Ten post edytował Zyx 30.11.2009, 19:06:30


--------------------
Specjalista ds. głupich i beznadziejnych, Zyx
Nowości wydawnicze: Open Power Collector 3.0.1.0 | Open Power Autoloader 3.0.3.0
Go to the top of the page
+Quote Post
kufalo
post
Post #6





Grupa: Zarejestrowani
Postów: 251
Pomógł: 2
Dołączył: 24.08.2005

Ostrzeżenie: (0%)
-----


Tak wiec, jezeli chce pobrac wartość z ciastka i sprawdzic czy nalezy do prawidlowych wartosci z tablicy co bedzie lepsze:

  1. $c=array_search(@$_COOKIE['sdfsdfsdf'],$tablica_wartosci)!==false;
  2.  
  3. $c=isset($_COOKIE['sdfsdfsdf'])&&array_search($_COOKIE['sdfsdfsdf'],$tablica_wartosci)!==false;


to pierwsze krotsze czyli bardziej przejrzyste, ale nie wiem czy to dobra maniera stosowac w kodzie @.

Kwestia jeszcze co jest szybsze (zaraz to sprawdze).

Swoja dorga podoba mi sie np JS. Tam wszelakie nieprzypisane wartosci tablic, obiektow zwracaja undefined i nie mamy do czynienia z zadnymi Errorami/Noticami. Po prostu sprawdzamy czy jest undefined i tyle.... W wiekszosci przypadkow ustalona wartosc rzutuje sie na true, a undefined na false, wiec kontrola jest dziecinnie prosta.
Własciwie przy uzyciu @ w PHP mozna postepowac tak samo.

Ten post edytował kufalo 30.11.2009, 20:05:07
Go to the top of the page
+Quote Post
Zyx
post
Post #7





Grupa: Zarejestrowani
Postów: 952
Pomógł: 154
Dołączył: 20.01.2007
Skąd: /dev/oracle

Ostrzeżenie: (0%)
-----


O istnieniu operatora @ najlepiej zapomnieć w ogóle. Nie dość, że jest on powolny, to jeszcze ukrywa wszystkie błędy, jakie są możliwe w PHP. To jest jedyna prawdziwie poprawna forma.

  1. if(isset($_COOKIE['ciastko']) && in_array($_COOKIE['ciastko'], $wartosci))
  2. {
  3. /// ...
  4. }


Pierwsze niekoniecznie jest bardziej przejrzyste i na dodatek może zadziałać niezgodnie z Twoimi oczekiwaniami. Sprawdź sobie działanie poniższego kodu z niezainicjowanym $_GET['foo']:

  1. <?php
  2. $wartosci = array('bar', null);
  3.  
  4. if(in_array(@$_GET['foo'], $wartosci))
  5. {
  6. echo 'Warunek 1 spelniony.<br/>';
  7. }
  8. if(isset($_GET['foo']) && in_array($_GET['foo'], $wartosci))
  9. {
  10. echo 'Warunek 2 spelniony.<br/>';
  11. }


Hehe, nic nie ustawiamy, a nam warunek 1 uznaje za spełniony. PHP w przypadku niezainicjowanych zmiennych generuje dla nich specjalną wartość null. Przypuśćmy, że ten kod jest jakimś zabezpieczeniem serwisu i wskutek literówki w tablicy dozwolonych wartości znalazł się null, a na jej podstawie przyznawany jest dostęp do jakiejś operacji. Puszasz serwis do Internetu i po pewnym czasie ktoś odkrywa, że jak skasuje sobie zmienną z adresu, to zabezpieczenie opada i zaczyna to bezlitośnie wykorzystywać, a ty płacesz, bo ktoś się włamuje. Ja jestem mądry i mam wbite do głowy, że istnienie zmiennych sprawdza się przez isset(). Ponadto dzięki eliminowaniu błędów E_NOTICE na etapie tworzenia wiem od razu, że zrobiłem literówkę i problemu nie mam, a gdyby nawet coś pozostało niezauważone, to na pewno nikt mi nie będzie robić kuku przez zwykłe skasowanie zmiennej w adresie bądź ciastka. Zrozum, że przyrównywanie wartości do nulla to nie jest żadna kontrola, szczególnie jak nie ma się do końca pojęcia, jak coś działa. Każdy szanujący się programista po prostu sprawdza warunki brzegowe i inicjuje zmienne przed użyciem, a nie szuka dróg na skróty, bo mu się nie chce paru dodatkowych linijek wklepać, a później się dziwi, że mu się strona sypie.

W Javie to by się taki kod nawet nie skompilował, albo rzucał Ci wyjątkiem, bezlitośnie przypominając, że olewanie kontroli danych mści się później okrutnie.

Ten post edytował Zyx 30.11.2009, 20:45:29


--------------------
Specjalista ds. głupich i beznadziejnych, Zyx
Nowości wydawnicze: Open Power Collector 3.0.1.0 | Open Power Autoloader 3.0.3.0
Go to the top of the page
+Quote Post
ChrisB
post
Post #8





Grupa: Zarejestrowani
Postów: 73
Pomógł: 4
Dołączył: 13.01.2004
Skąd: Bielsko-Biała

Ostrzeżenie: (0%)
-----


dla mnie też - notice = błąd w skrypcie

jedynie w jednym miejscu gdzie generuje spoooore statystki oparte na bazie mam dorzucone @ przed operacją na jednej wielowymiarowej tablicy - tablica ma ileśset tysięcy rekordów i mogą zdarzyć się nieustawione elementy,
inicjalizacja tej tabeli -aby wszystkie pola na pewno były dla każdego indeksu lub sprawdzanie czy istnieje dany indeks wydłużało działanie skryptu dobre 2 razy - więc poprostu wrzuciłem @ przed smile.gif nieelegancko na pewno, ale na szczęście na wynik nie ma wpływu za to wynik otrzymuje zdecydowanie szybciej.

moje 2 grosze:P


--------------------
gragieldowa.pl
Go to the top of the page
+Quote Post
vokiel
post
Post #9





Grupa: Zarejestrowani
Postów: 2 592
Pomógł: 445
Dołączył: 12.03.2007

Ostrzeżenie: (0%)
-----


Pominięcie sprawdzania istnienia elementu można usprawiedliwić przy sprawdzaniu jego wartości. Przykładowo:
  1. if (isset($zmienna) && $zmienna!=''){}
  2. // możemy zastąpić
  3. if (!empty($zmienna)){}


Ale oczywiście w konkretnych przypadkach. Czasem ważne jest sprawdzenie czy zmienna w ogóle istnieje, niekoniecznie czy posiada przypisaną wartość.

Tak czy inaczej wszelkie operacje na zmiennych powinny być poprzedzone ich sprawdzeniem pod kątem istnienia, wartości, prawidłowego typu.


--------------------
Go to the top of the page
+Quote Post
korro
post
Post #10





Grupa: Zarejestrowani
Postów: 259
Pomógł: 42
Dołączył: 8.04.2005
Skąd: Mława

Ostrzeżenie: (0%)
-----


Podpisuję się pod tym, że to błąd w sztuce.
Jeśli ktoś zaczyna naukę od PHP, takie niechlujstwo może wejść w krew.
Jeśli zaczynamy przygodę z PHP ze znajomością języka kompilowanego, takie podejście razi.
Podsumowując, tak czy inaczej, jestem za eliminowaniem notice'ów.


--------------------
Go to the top of the page
+Quote Post
thek
post
Post #11





Grupa: Moderatorzy
Postów: 4 362
Pomógł: 714
Dołączył: 12.02.2009
Skąd: Jak się położę tak leżę :D




Ja zacząłem przygodę z programowaniem od Turbo Pascala. Po paru perturbacjach (czytaj: między innymi AC Logo winksmiley.jpg ) C++. W PHP nie wyobrażam sobie by choćby "małpować" notice, a co dopiero mówić o błędach. Niby można... Ale dla własnego bezpieczeństwa lepiej nie iść na łatwiznę.


--------------------
Najpierw był manual... Jeśli tam nie zawarto słów mądrości to zapytaj wszechwiedzącego Google zadając mu własciwe pytania. A jeśli i on milczy to Twój problem nie istnieje :D
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Aktualny czas: 21.08.2025 - 04:28