Najczęstsze błędy w PHP i antywzorce, Kto zna jakieś fajne :) Opcje

[Sephirus]

Witam,

Ostatnio zastanawiałem się, jakie są często spotykane błędy, a raczej złe nawyki bądź po prostu bardzo nie wydajne lub nieoptymalne kawałki kodu jakie można znaleźć/napisać w PHP (IMG:style_emoticons/default/smile.gif) Zbieram też antywzorce. Gdzież indziej mógłbym się o to zapytać niż nie tutaj (IMG:style_emoticons/default/smile.gif)

Przykład wszystkim pewnie dobrze znany:

[PHP] pobierz, plaintext 
$tablica; // powiędzmy 1000 elementów, jakichś obiektów, sporych
 
for($i = 0; $i < count($tablica); $i++) {
    // jakieś operacje
}
[PHP] pobierz, plaintext 

Poprawna forma:

[PHP] pobierz, plaintext 
$tablica; // powiędzmy 1000 elementów, jakichś obiektów, sporych
 
$elementsCount = count($tablica);
for($i = 0; $i < $elementsCount; $i++) {
    // jakieś operacje
}
[PHP] pobierz, plaintext 

@aras785 - masz rację dodałem poprawną formę (IMG:style_emoticons/default/smile.gif)

Szukam podobnych konstrukcji, antywzorców programowania itp. Zależy mi na tym by były one proste (IMG:style_emoticons/default/smile.gif) Nie szukam jakichś skomplikowanych 100 linijkowych kodów na dowód tego, że są źle napisane - chodzi mi o same zamysły (IMG:style_emoticons/default/smile.gif)

Jeśli znacie jakieś piszcie proszę (IMG:style_emoticons/default/wink.gif)

Ten post edytował Sephirus 14.01.2013, 13:41:14

[aras785]

@Sephirus pisz również poprawne formy, ponieważ wejdzie początkujący i skąd będzie wiedział? Ps. w/w formę też używam czasami (IMG:style_emoticons/default/smile.gif)

Ostatni pomagając na forum popełniłem błąd przy usuwaniu danych z bazy.

Błędy zapis:

[PHP] pobierz, plaintext 
$q = mysql_query("SELECT id FROM test WHERE id=1 LIMIT 1--");
	if(mysql_num_rows($q)==1) {
		if(mysql_query("DELETE FROM test WHERE id=1 LIMIT 1--")) {
			echo('Usunięto!');
			} else echo('Błąd przy usuwaniu');
		}else echo('Nie ma takiego rekordu w bazie');
[PHP] pobierz, plaintext 

Poprawny:

[PHP] pobierz, plaintext 
		if(mysql_query("DELETE FROM test WHERE id=1 LIMIT 1--")) {
			echo('Usunięto!');
			} else echo('Błąd przy usuwaniu');
[PHP] pobierz, plaintext 

Objaśnienie: Jeśli nie znajdzie danego ID to go nie usunie i tak błąd wywali.

//poprawiłem. Kopiuj wklej i nie zauważyłem.

Ten post edytował aras785 14.01.2013, 13:58:45

[!*!]

Formatowanie kodu też to obejmuje? (IMG:style_emoticons/default/wink.gif)
Temat: Najczestsze bledy
Przejrzyj dział Oceny. Wypunktowane błędy są w prawie każdym wątku.

[nospor]

a raczej złe nawyki

głupota i lenistwo.... dwa najczęściej spotykane na forum złe nawyki... (IMG:style_emoticons/default/smile.gif)


A z bardziej przyziemnych rzeczy to np.
zapytania w pętli, gdzie główna pętla idzie z zapytania a w niej znowu pętla z zapytania (IMG:style_emoticons/default/smile.gif)
A już szczyt szczytów zapytania w rekurencji....

[Sephirus]

@aras785 Twój kod nadal jest dla mnie nie zrozumiały (nie wiem po co ten SELECT na początku) - ale przeanalizuję to (IMG:style_emoticons/default/smile.gif)

@!*! formatowanie (stricte) nie jest błędem a raczej niedbalstwem. Chyba, że ktoś nie lubi używać {} przy pętlach i instrukcjach a potem coś do nich dopisuje i się dziwi że zawsze działają ;P

[PHP] pobierz, plaintext 
 
if($costam === true)
    zrob_cos();
    zrob_cos_jeszcze();
 
// zamiast:
 
if($costam === true) {
    zrob_cos();
    zrob_cos_jeszcze();
}
 
// itp...
 
[PHP] pobierz, plaintext 

Temat z najczęściej pojawiającymi błędami jest mi znany - myślałem że wyłapie coś jeszcze osobno (IMG:style_emoticons/default/smile.gif) Pomysł z przeglądaniem działu "oceny" jest jednak dobry - dzięki (IMG:style_emoticons/default/wink.gif) tam na pewno coś znajdę (IMG:style_emoticons/default/wink.gif)

@nospor

Na głupotę nie ma rady ;P ale nie mogę zakładać że każdy na nią cierpi - sam robię masę błędów a potem mi wstyd ;P ale nie uważam się za totalnego głupola (IMG:style_emoticons/default/smile.gif) Co do lenistwa... true, true... :/

Zapytania w pętli to faktycznie częsta przypadłość (IMG:style_emoticons/default/biggrin.gif) Dużo ludzi na początku nie wie co to JOIN, nie ma pojęcia co to relacyjność :/ no i przede wszystkim jak już napisali jakieś zapytanie i im działa, to już go nie ruszają i piszą nowe. Każdy z nas się chyba zgodzi, że na początku nauki termin "wydajność" jest nam obcy (IMG:style_emoticons/default/smile.gif)

Ale zaintrygowałeś mnie tą rekurencją z zapytaniami!! (IMG:style_emoticons/default/biggrin.gif) Jak gdzie (IMG:style_emoticons/default/tongue.gif) w życiu tego nie widziałem - nie wiem nawet jak to napisać masz jakiś przykład? (IMG:style_emoticons/default/biggrin.gif)

[nospor]

Na głupotę nie ma rady ;P ale nie mogę zakładać że każdy na nią cierpi - sam robię masę błędów a potem mi wstyd ;P ale nie uważam się za totalnego głupola

Nie, nie o taką głupotę mi chodziło. Błędy przytrafiają się każdemu.

Ale zaintrygowałeś mnie tą rekurencją z zapytaniami!! Jak gdzie w życiu tego nie widziałem - nie wiem nawet jak to napisać masz jakiś przykład?

A proszę bardzo, pierwszy przykład z brzegu:
Drzewko, tabela:
ID
ID_PARENT
.....

No i koleś pobiera rekurencyjnie całe drzewko z góry na dół. Najpierw wierzchołek, potem jego dzieci, potem dzieci dzieci i tak dalej....wszystko w ładnej niesamowidzie mulącej rekurencji (IMG:style_emoticons/default/smile.gif)




Inny przykład kodów:

[PHP] pobierz, plaintext 
 
$zm = 1;
 
if ($zm == 1) echo 'jeden';
if ($zm == 2) echo 'dwa';
else echo 'trzy';
[PHP] pobierz, plaintext 

No i koleś się dziwi ze mu się wyswietal jeden i trzy, a przecież wyraźnie zmienna to 1


To jest też dobre:

[PHP] pobierz, plaintext 
while($row=....){
$dane = $row;
}
print_r($dane);
 
//EJ.... ludzie, czemu pobiera mi tylko ostatni rekord z bazy a nie wszystkie?!!!!! HELP!!!!
[PHP] pobierz, plaintext 

(IMG:style_emoticons/default/smile.gif)

Albo to:

[PHP] pobierz, plaintext 
 
$row = mysql_fetch_array(....);
while ($row = mysql_fetch_array(....)){
print_r($row);
}
 
//EJ.... ludzie, czemu pobiera mi wszystkie rekordy oprócz pierwszego?!!!! HELP!!!! 20 dni już nad tym siędzę!!!!!!!!!!!
[PHP] pobierz, plaintext 

(IMG:style_emoticons/default/wink.gif)

[Sephirus]

Ok przyznam szczerze... z tym drzewkiem... że bym na to nie wpadł (IMG:style_emoticons/default/smile.gif) co prawda od jakiegoś czasu sporo siedzę w SQL'u i obczajam jego wszelkie tajniki (poza administracją może bo to mi na nic) i może przez to wydaje mi się to dziwne, choć kiedyś kto wie - może i sam tak pisałem (IMG:style_emoticons/default/smile.gif)

Ten drugi błąd to też bardziej pod formatowanie (IMG:style_emoticons/default/smile.gif) I kurcze coś w tym jest - trzeba pisać "ładnie", estetycznie, zachowywać te wszystkie (jak to się na początku wydaje) głupie zasady (IMG:style_emoticons/default/tongue.gif) ja osobiście nie przestrzegam tylko jednej. Czytałem parę propozycji jak pisać i formatować kod czy o nazewnictwie zmiennych itd. (także dla różnych frameworków itp.) więc mi się to utrwaliło i z tego wszystkiego mam swoją jedną wizję łączącą po kawałku ze wszystkiego ale nie przestrzegam zasady o tym, żeby linia miała <=80 znaków i nie znam osoby (osobiście) która tego przestrzega (oczywiście nie pisze ciurkiem ale jak coś mi wyskoczy poza 80 znaków to tak zostawiam po prostu).

Najgorszy błąd jaki mi się kiedyś przydarzył i naprawdę nie wiedziałem co z tym robić (pomogło dopiero przepisanie kodu od nowa (IMG:style_emoticons/default/haha.gif) ) wyglądał tak:

(może nie błąd, ale przeoczenie)

[PHP] pobierz, plaintext 
for($i = 0; $i < $jakasWartosc; $i++); {
     // wykonaj jakiś kod
}
[PHP] pobierz, plaintext 

Oczywiście ta pętla odwalała trochę roboty i to nie łatwej i nigdy nie chciała się wyświetlić :/ co bym nie robił (IMG:style_emoticons/default/tongue.gif) Głupi średnik (który swoją drogą sam nie wiem jak się tam dostał zmarnował mi kupę czasu bo zdebugowałem cały skrypt praktycznie (IMG:style_emoticons/default/tongue.gif)

EDIT: Te dwa ostatnie powalają nospor ale fakt nawet, że chyba na forum raz z czymś takim "pomogłem" (IMG:style_emoticons/default/tongue.gif)

Ten post edytował Sephirus 14.01.2013, 14:10:59

[pyro]

Tyle jest błędów i nieprawidłowych konstrukcji popełnianych przez ludzi, że ten cały wątek chyba nie ma celu, bo po pierwsze chyba miałby z 500 stron, a po drugie całe programowanie sprowadza się do poprawnego pisania algorytmów, więc ten temat jest tak jakby jak całe to forum (IMG:style_emoticons/default/goatee.gif)

[nospor]

No i cała masa złego porównywania typów, nie rozróżnianie =, ==, ===

[PHP] pobierz, plaintext 
if ($zm = 2) echo 'Czemu to mi sie zawsze wyświetla?';
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
//funkcja xyz może zwracać false, oraz liczby od 0 wzwyż
 
if (xyz() == false) echo 'Źle';
//Czemu mi ciągle wali Źle, skoro funkcja zwraca poprawny wynik?
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
$i=0;
while ($i <10){
//tu masa kodu oprócz jednego najważniejszego $i++
}
//ej ludzie... zapetlam się.....
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
while ($row = mysql_fetch_array($res)){
//tu masa kodu 
//oraz
$res = mysql_query();
}
//ej ludzie... pobiera mi tylko pierwszy rekord....
[PHP] pobierz, plaintext 

[pyro]

Ja do najgłupszych błędów, który popełniłem 30 sekund temu mogę zaliczyć zostawienie patelni na gazie, a potem robienie rzeczy przy komputerze. (ktoś mnie poprosił o pomoc z pewnym problemem natury programistycznej i zapomniałem o patelni). W kuchni pełno dymu, prawie spaliłem dom (IMG:style_emoticons/default/smile.gif) . (ale omlet z cynamonem i tak wyszedł smaczny)

Ten post edytował pyro 14.01.2013, 14:16:27

[nospor]

No i najważniejsze zło, jakie robią zarówno początkujący jak i ci, którzy uważają się za profesjonalistów:

[PHP] pobierz, plaintext 
error_reporting(E_ALL ^ E_NOTICE);
[PHP] pobierz, plaintext 

Na to mi normalnie brak słów

[Sephirus]

@pyro Masz całkowitą rację niestety - to jest "rzeka", można by wymieniać w nieskończoność mimo to uważam, że dobrze jest ciągle wałkować ten temat (IMG:style_emoticons/default/smile.gif) dlaczego?

Jestem sobie programistą, uważam że pozjadałem wszystkie rozumy (IMG:style_emoticons/default/smile.gif) wchodzę na taki wątek i czytam, tu się uśmiechnę, tam się zaśmieje ale może, w pewnym momencie naglę przystanę i stwierdzę - o kurde... nie wiedziałem, że tak nie można (IMG:style_emoticons/default/smile.gif)

No i poza tym chciałbym zebrać nieco materiałów na ten temat by się nimi podzielić z "nowymi" w pracy (IMG:style_emoticons/default/smile.gif) i ich na to uczulić a sam wszystkiego nie pamiętam (IMG:style_emoticons/default/sad.gif)

@nospor Co do operatorów to fakt, ale bardzo podobała mi się odpowiedź Erixa w temacie o najczęstrzych błędach, że "if($costam = 123)" to nie bug - tylko feature (IMG:style_emoticons/default/smile.gif) To mi nasunęło pewną myśl: rzadko spotykam się z tym żeby ktoś to stosował :/

[PHP] pobierz, plaintext 
 
// w zamyśle jakas_funkcja zwraca albo null albo ciąg znaków
 
// zamiast (co jest dla mnie najlepsze)
if($wynik = jakas_funkcja()) {
    echo 'Wynik prawidlowy i równy ' . $wynik;
}
 
// jest
$wynik = jakas_funckja();
if($wynik) {
    echo 'Wynik prawidlowy i równy ' . $wynik;
}
 
// no nie wspominając już o błędnym podejściu
if(jakas_funkcja()) {
    echo 'Wynik prawidlowy i równy ' . jakas_funkcja();
}
[PHP] pobierz, plaintext 

Czym może to być spowodowane że rzadko to ludzie stosują? Niewiedza? Gorsza przejrzystość kodu?

[nospor]

własnie w dziale przedszkole pojawił się problem z mojego posta wczesniej:
if ($zm = 'b')

Bład tak czesty, ze nawet podczas pisania posta pojawiają się takie tematy (IMG:style_emoticons/default/biggrin.gif)

[pyro]

No i najważniejsze zło, jakie robią zarówno początkujący jak i ci, którzy uważają się za profesjonalistów:

[PHP] pobierz, plaintext 
error_reporting(E_ALL ^ E_NOTICE);
[PHP] pobierz, plaintext 

Na to mi normalnie brak słów

@nospor, bzdury Pan pleciesz! To nie jest żaden błąd, tylko konstrukcja, która choć nie zawsze stosowana z rozwagą, w wielu przypadkach usprawiedliwiona.

[nospor]

Czym może to być spowodowane że rzadko to ludzie stosują? Niewiedza? Gorsza przejrzystość kodu?

Wg. mnie chodzi o przejrzystość. Sam tego nie stosuję choć dobrze wiem jak to działa (IMG:style_emoticons/default/smile.gif) Wolę mieć przejrzysty kod niż super hiper featured (IMG:style_emoticons/default/wink.gif)

@pyro to
if ($zm = 'b')
te tez nie jest błąd, tylko konstrukcja, rzadko stosowana z rozwagą (IMG:style_emoticons/default/wink.gif)

Pomijam przypadki, gdy wyłączenie E_NOTICE jest usprawiedliwione. Mówię o sytujacji, gdy to w żaden sposób nie jest usprawiedliwione, np. gdy zaczynasz projekt od 0 i lecisz już z taką dyrektywą. Wówczas to jest fatalny błąd!

NIe chce mi się powtarzać, więc podam tylko linka
http://nospor.pl/notice-wyswietlac-czy-nie.html

[pyro]

Pomijam przypadki, gdy wyłączenie E_NOTICE jest usprawiedliwione. Mówię o sytujacji, gdy to w żaden sposób nie jest usprawiedliwione, np. gdy zaczynasz projekt od 0 i lecisz już z taką dyrektywą. Wówczas to jest fatalny błąd!

NIe chce mi się powtarzać, więc podam tylko linka
http://nospor.pl/notice-wyswietlac-czy-nie.html

No to nie dopowiedziałeś i można było bardzo łatwo to źle zrozumieć. Trzeba było od razu dać link do artykułu, bo z tego co napisałeś można zrozumieć, że stosowanie tego jest zawsze złe.

[Tuminure]

Znajomość różnicy między && i AND, a także || i OR może się czasem przydać.

[PHP] pobierz, plaintext 
$result1 = true AND false; // true
$result2 = true && false; // false
$result3 = false OR true; // false
$result4 = false || true; // true
[PHP] pobierz, plaintext 

[nospor]

No to nie dopowiedziałeś i można było bardzo łatwo to źle zrozumieć. Trzeba było od razu dać link do artykułu, bo z tego co napisałeś można zrozumieć, że stosowanie tego jest zawsze złe.

Dobrze, przepraszam. Niepotrzebnie przyjąłem, że każdy zrozumie o co mi chodzi (IMG:style_emoticons/default/smile.gif)

@Tuminure o właśnie, ludzie często nie wiedzą do czego służą nawiasy oraz co to ważność operatora i często nie kumają czemu
2+3*4 nie jest równe 20 (IMG:style_emoticons/default/smile.gif)
Oczywiście mówię tu w odniesieniu do mysql i php

[Sephirus]

Co do errorów to prawda... ale to jest celowe jakby nie patrzeć ;P zapominają o cudzysłowach itp. a potem jak im wyskakuje wiele notice'ów a mogą je ukryć (bo przecież wszystko działa) to sobie je olewają i ukrywają (IMG:style_emoticons/default/tongue.gif)

U mnie w firmie jak raz włączyliśmy na głównym (starym) portalu logowanie do pliku wszystkich błędów z noticami włącznie to przez 30 minut plik z logiem miał 10GB (IMG:style_emoticons/default/smile.gif)

Ten post edytował Sephirus 14.01.2013, 14:41:14

[nospor]

U mnie w firmie jak raz włączyliśmy na głównym (starym) portalu włączyliśmy logowanie do pliku wszystkich błędów z noticami włącznie to przez 30 minut plik z logiem miał 10GB

No właśnie, i weź potem w takiej ilości błędów znajdź człowieku jakąś literówkę.... nie ma szans.... i dlatego zawsze od początku trzeba pisać poprawnie. Gdy się tego nie zrobiło to potem już pozostaje jedynie na stałe wyłączenie błędów NOTICE i szukać przez 5 godzin jakis banalnych błędów, które z NOTICE znalazłoby się w dwie sekundy

[Sephirus]

Zgadzam się w 100%, niestety z takimi starymi bytami nie ma szans na poprawę - przyczyna jest prosta - albo brak "zasobów" by to zrobić - albo prosta, czysta "nieopłacalnośc" - jednak ktoś płaci za czas pracy programistów (IMG:style_emoticons/default/smile.gif)

Zresztą po przeczytaniu Twojego nospor arta, umocniłem się jedynie w przekonaniu, że samo generowanie tych błędów zajmuje czas, toteż ich ukrywanie w dużej liczbie jedzie po wydajności - mnie to przekonuje do kwadratu (IMG:style_emoticons/default/smile.gif)

@Tuminure ok może coś źle rozumiem ale nie widzę róznicy w PHP między AND a && i OR a ||?

Widzę jedynie pomiędzy AND/&& a & i odpowiednio OR/|| a |

Na pewno tak jest? (IMG:style_emoticons/default/smile.gif)

Ten post edytował Sephirus 14.01.2013, 14:55:30

[thek]

Ja przykładowo dzięki przeglądaniu kodów innych, przekonałem sie do "inwersji" w warunkach, czyli

[PHP] pobierz, plaintext 
if(false == $zmienna)
[PHP] pobierz, plaintext 

która w razie czego zareaguje, gdyby mi się zamiast == wpisało samo =, co w debugu może przejść niezauważone.

Co do takich bardziej typowych błędów spotykanych, to oczywiście wszelkiego rodzaju gubienie się w zasięgu zmiennych spowodowane choćby używaniem globali lub zmiennych statycznych, których jednak część ludzi nie rozumie (inna sprawa, że global to zuo straszne). Często problemy z zapomnianym session_start. Chyba sztandarowy problem z wysyłaniem headersów przed funkcjami pokroju set_cookies wynikający albo z walnięcia entera przed <?php , czy zapisu strony ze znacznikiem BOM (IMG:style_emoticons/default/wink.gif)

@Sephirus: Chodzi o priorytet operacji. && i || mają pierwszeństwo przed AND i OR, co może mieć odbicie w operacjach logicznych, gdy ktoś pomiesza oba rodzaje ze sobą (IMG:style_emoticons/default/wink.gif)

Powód edycji: @Operatory logiczne

[Tuminure]

2+3*4 nie jest równe 20

Aż mi się przypomniało przeładowywanie operatorów z artykułu nonsensopedii dot. C++ (IMG:style_emoticons/default/tongue.gif)

Do tego tematu w gruncie rzeczy pasuje też ten link: http://nonsensopedia.wikia.com/wiki/PHP

ok może coś źle rozumiem ale nie widzę róznicy w PHP między AND a && i OR a ||?

Widzę jedynie pomiędzy AND/&& a & i odpowiednio OR/|| a |

Po prawej stronie podałem wyniki, które wskazałby var_dump na podanej zmiennej.
W podanym przez Ciebie linku w Example #1, również jest to co podałem.

Ten post edytował Tuminure 14.01.2013, 15:07:17

[Sephirus]

@thek Tak ta "inwersja" jeśli chodzi o kolejność jest fajną sprawą i choć sam nie stosowałem - przekonałem się właśnie do tego.

Co do globali to mi się skojarzyło z register_globals od razu, choć jest to już temat może archaiczny to mimo wszystko nadal się go sporadycznie spotyka :| A już użycie funkcji extract aby go symulować bez żadnych zabezpieczeń i kontroli tego co przychodzi chociażby z GETów to już cofanie się w rozwoju a też to spotykam :/

EDIT: Właśnie znalazłem jeszcze jeden częsty błąd... Trzeba pamiętać by czyścić monitor :/ Właśnie kombinowałem czemu godzina pokazuje mi się jako

15;02

a nie

15:02

hmm... po znalezieniu odpowiedniej linijki, sprawdzeniu, i poruszeniu rolki myszki okazało się że to paproch :/

Ten post edytował Sephirus 14.01.2013, 15:04:33

[redeemer]

W większości wypadków jako operator porównania lepiej stosować === zamiast == (http://gynvael.coldwind.pl/?id=492)

[sowiq]

A już użycie funkcji extract...

Mój kolega powiedział kiedyś bardzo trafne porównanie - funkcja extract to rozrzutnik gnoju. I tyle w tym temacie (IMG:style_emoticons/default/smile.gif)

A po kilku postach, które przejrzałem - zapomniane session_start, jakieś headery, zasięg zmiennych, pomylone = i ==... Kurde, ludzie, czy Wy dalej piszecie strukturalne PHP w Notatniku? O sesjach czy headerach zapomniałem w chwili kiedy pierwszy raz użyłem frameworka. Zasięg zmiennych? Może za czasów pisania strukturalnych skryptów, ale nie programowania w OOP. A o pomyłkach = / == każde średnio zaawansowane IDE informuje ostrzega na bieżąco.

Ten post edytował sowiq 14.01.2013, 15:15:11

[Sephirus]

Mój kolega powiedział kiedyś bardzo trafne porównanie - funkcja extract to rozrzutnik gnoju. I tyle w tym temacie (IMG:style_emoticons/default/smile.gif)

Czasem żałuję że nie ma przy postach na forum opcji z FB typu: LIKE (IMG:style_emoticons/default/smile.gif)

Ale co do IDE - to ma pomóc a nie zastępować nam rozum (IMG:style_emoticons/default/smile.gif) Dla doświadczonego programisty dobre IDE to skarb, nie dlatego że poprawia kod, ale że podpowiada i daje dużo przydatnych funkcjonalności. Jak ktoś jednak chcę się "nauczyć" programować to chyba jednak coś pokroju notatnik-plus byłby lepszy (IMG:style_emoticons/default/smile.gif) a chodzi przecież o błędy początkujących (IMG:style_emoticons/default/wink.gif)

@thek & @Tuminure tak to rozumiem - priorytet tak ale z zapisem:

[PHP] pobierz, plaintext 
$result1 = true AND false; // true <-- TYM
$result2 = true && false; // false
$result3 = false OR true; // false <-- i TYM się nie zgadzam :)
$result4 = false || true; // true
[PHP] pobierz, plaintext 

(IMG:style_emoticons/default/smile.gif)

Ten post edytował Sephirus 14.01.2013, 15:22:34

[thek]

@sowIq: co innego gdy korzystasz z Fw, a co innego gdy sam się zabrałeś za pisanie czegoś z celowym jego pominięciem, by narzut czasowy zlikwidować w ramach optymalizacji wąskich gardeł aplikacji.

Poza tym wiele osób nie zwraca uwagi, że funkcje php mogą zwrócić w normalnym trybie jako prawidłowy wynik 0 czy false, zaś jako nieprawidłowy null, a inne z kolei zwracają jako prawidłowe 0 i false, ale już nie null. Brak po prostu jednoznacznego określenia co jest prawidłowe, a co nie w tym języku. Wtedy:

[PHP] pobierz, plaintext 
if ($zmienna == 0)
[PHP] pobierz, plaintext 

i mamy WTF bo false == 0, co nie zawsze jest tym o co chodziło (IMG:style_emoticons/default/wink.gif) Pisząc od początku w jakimś Fw o wielu takich rzeczach się nie wie i nie myśli. Potem nadchodzi zmiana Fw i jest kaplica.

Headery? Nadal są gdy ktoś zapisze plik w UTF-8, ale nie zwróci uwagi jakim (stąd uwaga o BOM) albo przed <?php zdarzy mu się enter. Takich rzeczy Fw nie wyłapie.

Zasięg zmiennych? Nie każdy kod ma 5 linijek... Czasami metody z racji takich, a nie innych sytuacji mają ogromną złożoność i zdarza się, że w 5-6 zagnieżdżeniu ( niekoniecznie pętli, ale i struktury warunkowej) można się już na tym naciąć. Przykład Ci krótki dam, gdyż jakiś czas temu sobie skrobnąłem. Metoda ma znaczne complexity, ponieważ dane do niej przychodzące i obrabiane mogą być tablicą, ale i stringiem. Z kolei inny parametr może być raz stringiem, ale innym razem nullem (IMG:style_emoticons/default/wink.gif)

[PHP] pobierz, plaintext 
$bestHit = false;
try{
  foreach($this->structure AS $main) {
    if(null !== $first && $first !== $main['name']) {
      continue;
    }
    foreach($main['childrens'] AS $nested) {
      if(is_array($name)) {
        if(in_array($name['base'], array_keys($nested['attr']))) {
          $this->property = array('main' => $main['name'], 'child' => $nested['name']);
          foreach($nested['attr'] AS $attr_name => $attr_data) {
            if( array_key_exists('params', $name) && $name['params'] == $attr_data['params'] ) {
              return $this;
            } else {
              $bestHit = true;
            }
          }
        }
      } else {
        if(in_array($name, array_keys($nested['attr']))) {
          $this->property = array('main' => $main['name'], 'child' => $nested['name']);
          return $this;
        } elseif ($name == $nested['name']) {
          $this->property = array('main' => $main['name'], 'child' => $nested['name']);
          return $this;
        }
      }
    }
  }
  if($bestHit) {
    return $this;
  }
} catch (Exception $e) {
  throw tu_wyjatek_okreslony_przeze mnie(); // wiem co może mi rzucić, ale dla pewności łapię zakres Exception, a nie od niego pochodny
}
$this->property = array('main' => '', 'child' => '');
return $this;
[PHP] pobierz, plaintext 

I powiedz mi, ile czasu zajęło by Ci zrozumienie co w tym się dzieje, w jakim celu i kiedy oraz co jest zwracane (IMG:style_emoticons/default/wink.gif) Nie jest to kwestia sporzenia przez moment, a to tylko 30 linijek, będących całym ciałem jednej metody. Complexity tego kodu jest naprawdę duże, ale wynika ze struktury danych oraz danych wejściowych dla tej metody. Z tego nie wytniesz nawet linijki do metody prywatnej czy nie zrobisz klasy pomocniczej, która by to uprościła. Weź się walnij z returnem, miejscem inicjalizacji $bestHit lub przypisaniem danych do niej i masz problem z zasięgiem. A popatrz jak wiele miejsc ma ta metoda, by się pomylić, choć to tylko 2 zagnieżdżone foreach, tyle że ifów jest tu niestety wiele. I tak... Metoda ma napisany test, który ją całkowicie pokrywa, więc w razie czego wyłapię problem.

[Sephirus]

W sumie popieram przedmówcę ale (za pewne to babol jakiś) kod:

[PHP] pobierz, plaintext 
        if(in_array($name, array_keys($nested['attr']))) {
          $this->property = array('main' => $main['name'], 'child' => $nested['name']);
          return $this;
        } elseif ($name == $nested['name']) {
          $this->property = array('main' => $main['name'], 'child' => $nested['name']);
          return $this;
        }
[PHP] pobierz, plaintext 

nasuwa pytanie - czemu nie w jednym warunki i || ? (IMG:style_emoticons/default/smile.gif) (wiem czepiam się)

[sowiq]

@thek, a co ma zasięg zmiennych do ilości i zagnieżdżenia pętli oraz złożoności kodu? Do rozwiązania ewentualnych problemów z tym związanych są - jak słusznie napisałeś - testy.

A problem z zasięgiem zmiennych bardziej kojarzy mi się z takim kodem:

[PHP] pobierz, plaintext 
$var = 123;
 
function test1()
{
    echo $var;
}
 
function test2($var)
{
    echo $var;
    test1();
}
 
test1();     // wywali Warning
test2(5);   // wyświetli 5 a nie 123, po czym wywali Warning
[PHP] pobierz, plaintext 

Przykład niby oczywisty, ale już małe w zakłopotanie może wprowadzić niektórych dodanie

[PHP] pobierz, plaintext 
global $var;
[PHP] pobierz, plaintext 

na początku funkcji test1().

[Tuminure]

Wychodziłem akurat z pracy, więc nie dokończyłem poprzedniego komentarza...

@thek & @Tuminure tak to rozumiem - priorytet tak ale z zapisem:

Sęk w tym, że operator = jest wykonywany przed operatorem AND, a po operatorze &&. Analogiczna sytuacja występuje przy OR i ||.
W komentarzach umieściłem wersję z nawiasami, która powinna wyjaśnić w czym tkwi różnica.

W podanym przez Ciebie linku również jest to wytłumaczone w komentarzach (w Example#1) (IMG:style_emoticons/default/wink.gif) .

http://codepad.org/KorJrKo7

Ten post edytował Tuminure 14.01.2013, 16:38:03

[Sephirus]

Facepalm. ok @Tuminure masz całkowitą rację, od zupełnie innej strony do tego podszedłem (IMG:style_emoticons/default/smile.gif)

[thek]

@sowiq: Przy złożonym kodzie bardzo łatwo się pogubić ze zmiennymi i tym co gdzie oraz jak inicjalizujemy, nadpisujemy lub zwracamy. Zauważ, że mógłbym przykładowo gdzieś w pętli zrobić break i mieć zmienną nadpisującą wewnątrz pętli inną, o zasięgu większym. Gdy takie sytuacje występują, bardzo łatwo się w tym pomylić. Pamiętajmy, że zasięg zmiennej to nie tylko zakres widoczności wnętrza funkcji, ale także przykładowo wnętrza pętli. To co wewnątrz pętli, poza nią też nie istnieje, czyli problem w stylu:

[PHP] pobierz, plaintext 
for ($i = 0; $i < 10; ++$i) {
  echo $i;
}
echo $i;
[PHP] pobierz, plaintext 

@sephirus: taki zapis dla czytelności podczas etapu utrzymywania i konserwacji kodu (IMG:style_emoticons/default/smile.gif) Łatwiej zauważyć innym, że raz mamy do czynienia ze stringiem, a innym razem z tablicą. Choć jak sam zauważyłeś, można to zbić do jednego, ale długość tego warunku przekroczyła by nie tylko sztywny limit 80 znaków, ale także miękki 120, a ja z racji czytelności staram się warunków nie "łamać" do następnej linii, choć na owo łamanie standardy pozwalają. No i narzędzia typu Sonar trochę potrafią Ci w kodzie potencjalnych pułapek wskazać (IMG:style_emoticons/default/wink.gif)

[Pilsener]

Najgorsze są dla mnie błędy związane z wydajnością i bezpieczeństwem, typu:

• niczym nie zabezpieczona rekurencja (tym gorsza, że uzależniona od parametrów z zewnątrz)
• echowanie czego popadnie prosto z requesta lub tablicy $_SERVER, konstrukcje typu ... where id = $_GET['id'] i tak dalej
• pobieranie wszystkiego z bazy jak leci albo wrzucanie do sesji jak leci - no bo wygodnie mieć wszystko w sesji, najlepiej całą bazę danych od razu wrzucić sobie do sesji, "by mieć taki kesz"
• "dziś miejsce na dysku nie jest już problemem" - słyszałem to już x razy po czym po chwili dysk pada bo logujemy do plików pierdów bez liku

A jedne z najbardziej irytujących:

• jednolita konfiguracja dla każdego środowiska, przez co regularnie commituje ustawienia lokalne albo po update wściekam się, że coś nie działa
• brak jakichkolwiek komentarzy czy dokumentacji, najczęściej im paskudniejszy kod tym komentarzy jak na złość mniej
• brak sprawdzania, czy coś się wykonało, założenie, że jak funkcja coś zwraca to z pewnością jest to spam, potem coś po prostu nie działa i sobie możesz szukać kilka dni no bo przecież "funkcja powinna wygenerować warninga chociaż jak jej kiepawo idzie"
• używanie gdzie popadnie różnych fantastycznych wynalazków cudownego dziecka skryptu typu eval, goto, dynamiczne generowanie zmiennych - ekstrakcja to mały pikuś przy tym
• obiektowość rozumiana tak, że np. co każde 100 linijek walniemy klasę a co 20 metodę, tworzenie jakiś dziwnych fabryk czy raczej młockarni obiektów które tworzą takie plewy, że człowiek tęskni za dynamicznym generowaniem zmiennych (IMG:style_emoticons/default/smile.gif)

[sowiq]

To co wewnątrz pętli, poza nią też nie istnieje, czyli problem w stylu:

[PHP] pobierz, plaintext 
for ($i = 0; $i < 10; ++$i) {
  echo $i;
}
echo $i;
[PHP] pobierz, plaintext 

Pudło kolego (IMG:style_emoticons/default/smile.gif) Nie ten język. Za pętlą $i będzie miało wartość 10.

[edit]
Niektórzy mieli okazję pracować nad hinduskim kodem i im nie trzeba tłumaczyć (IMG:style_emoticons/default/smile.gif) Najlepszy kwiatek jaki widziałem (napisany na 99% przez hindusa). Nie trzeba tego chyba komentować (IMG:style_emoticons/default/wink.gif)

[PHP] pobierz, plaintext 
eval('$i = ' . $j . ';');
[PHP] pobierz, plaintext 

Inna rzecz, jaka mnie wprawiła w zdumienie to jakiś portal społecznościowy z prywatnymi wiadomościami, do których można dodawać załączniki. Brak jakiejkolwiek walidacji sprawiał, że po załączeniu przez nadawcę pliku PHP, odbiorca zamiast go pobierać, wykonywał go na serwerze (IMG:style_emoticons/default/smile.gif)

No i oczywiście temat rzeka - XSS. Należy pamiętać, że na modyfikację danych (dodawanie, usuwanie, update) należy pozawalać tylko requestom wykonywanym metodą POST.

[edit 2]
Jeśli chodzi o antywzorce, to znam jeden, który sam kiedyś z lubością (a raczej bez refleksji) praktykowałem. A chodzi o uzależnianie ilości wykonywanych zapytań SQL od ilości rekordów w bazie. Jak widać poniżej - im więcej rekordów będzie miała tabelka table1, tym więcej zapytań zostanie wykonanych na tabelce table2. Problem jest niezauważalny podczas przeklikiwania się przez aplikację z 10, 20, 50 rekordami w bazie. Ale problem może się zacząć pojawiać na serwerze produkcyjnym z dużo większą ilością danych.

[PHP] pobierz, plaintext 
$records = $db->getRecords("SELECT * FROM table1");
 
foreach($records as $record)
{
    $item = $db->getRecords("SELECT * FROM table2 WHERE category_id = ?", $record['id']);
    echo $item['name'];    // jakakolwiek operacja
}
 
/**  a tutaj jak to powinno wyglądać  **/
$records = $db->getRecords("SELECT * FROM table1 t1 JOIN table2 t2 ON t2.category_id = t1.id");
 
foreach($records as $record)
{
    echo $item['name'];    // jakakolwiek operacja
}
 
/**  lub:  **/
$records = $db->getRecords("SELECT * FROM table1");
$ids = array();
 
foreach($records as $record)
{
    $ids[] = $record['id'];
}
 
$records = $db->getRecords("SELECT * FROM table2 WHERE category_id IN (?)", implode(', ', $ids));
 
foreach($records as $record)
{
    echo $item['name'];    // jakakolwiek operacja
}
[PHP] pobierz, plaintext 

Ten post edytował sowiq 15.01.2013, 09:47:32

[Sephirus]

@thek Rozumiem - ma to duży sens bo kod jest faktycznie bardziej czytelny, ja w tych miejscach jednak łamię warunki ;P stąd moje "czepianie się" (IMG:style_emoticons/default/wink.gif)

Co do tej pętli to faktycznie sowiq ma rację - sam często wykorzystuję fakt, że w PHP zmienna użyta w pętli, po jej zakończeniu służy jeszcze do czegoś (dla jej ostatniej wartości).

@sowiq Oj tak - ten antywzorzec z liczbą zapytań, już tu zresztą wspominany, to naprawdę zmora niedoświadczonych z dużymi serwisami produkcyjnymi programistów, wszystko śmiga a potem na produkcji zaczyna się kombinowanie co jest nie tak że przymula (IMG:style_emoticons/default/smile.gif)

Przypomniał mi się tutaj jeden fajny bajer jaki widziałem w kodzie młodego kolegi... i żeby nie było to autentyk (IMG:style_emoticons/default/smile.gif)

[PHP] pobierz, plaintext 
// jakieś operacje na PDO itd... środek jakiegoś modelu metoda zwracająca liczbę rek. w tabeli (coś z paginacją o ile pamiętam)
 
// ...
$stmt = $pdo->query('SELECT * FROM tablica ');
$results = $stmt->fetchAll();
return count($results);
// ...
 
[PHP] pobierz, plaintext 

(IMG:style_emoticons/default/wink.gif)

[thek]

@sowiq: w PHP to przejdzie, bo język ten ma swoje głupotki. W większości języków jednak zapis ten wywinie orła. Pisząc zaś o antywzorcach i błędach można wyjść poza jezyk, wskazując jego usterki, nielogiczności - w odniesieniu do innych znanych sobie języków. Bo niestety, ale język ten ma swoje upierdliwości, które widać patrząc z perspektywy innych. I nie chodzi mi o wydajność czy tego typu rzeczy, ale właśnie nielogiczność pewnych konstrukcji, struktur czy funkcji. Wspomniana niejednoznaczność wyniku funkcji, brak konsekwencji w kolejności parametrów (niektóre funkcje można wywołać raz tak, raz siak) czy problemy z zasięgiem zmiennych lokalnych (właśnie dlatego wspomniany) to przecież nie jedyne, które mogą wkurzać.

Co do zezwalania na modyfikacje tylko danym POST, to co to za różnica? Dane jedynie minimalnie trudniej spreparować. Po prostu nie możemy na pałę w linku podmienić parametru. Ale firebug, tamperdata lub podobne i zero problemów. To jest bardziej zalecenie projektowe.

[sowiq]

Co do zezwalania na modyfikacje tylko danym POST, to co to za różnica? Dane jedynie minimalnie trudniej spreparować. Po prostu nie możemy na pałę w linku podmienić parametru. Ale firebug, tamperdata lub podobne i zero problemów. To jest bardziej zalecenie projektowe.

Oczywiście, że to zalecenie projektowe, nikt Ci przecież nie każe na siłę tak robić. Ale jest to zalecenie dotyczące bezpieczeństwa. I nie chodzi tu o to, że "atakującemu" będzie trudniej wysłać takie zapytanie, bo to akurat pryszcz. Chodzi o XSS, o którym wspomniałem wcześniej. Jak na Twojej stornie masz jakąś dziurę pozwalającą na XSS, której nie zauważyłeś i ktoś doda Ci taki obrazek jak poniżej, to masz mały problem.

[HTML] pobierz, plaintext 
<img src="/admin/post.php?act=deleteAll&confirmed=1" />
[HTML] pobierz, plaintext 

Chodzi o to, że zapytania POST nie da się wygenerować za pomocą prostego XSS. Musiałaby to być mega dziura pozwalająca na dodanie JS (IMG:style_emoticons/default/smile.gif)

[edit]

Przypomniał mi się tutaj jeden fajny bajer jaki widziałem w kodzie młodego kolegi... i żeby nie było to autentyk (IMG:style_emoticons/default/smile.gif)

Kiedyś pracowałem przy rozbudowie jednego z większych portali obrazkowych w USA i widziałem identyczny kwiatek. Więc to nie jest domena tylko tych młodszych programistów i tylko tych mniejszych projektów (IMG:style_emoticons/default/wink.gif)

Ten post edytował sowiq 15.01.2013, 09:44:10

[thek]

W przypadku XSS czy nie, zawsze się userowi robi "sandboxa", o czym wiele osób zapomina. Pozwalasz na jakieś akcje? Ogranicz to uprawnieniami tak mocno jak sie da. Taka przykladowa deletAll, nawet gdyby zadziałała, rąbnęła by nie całość bazy, ale maksymalnie to, do czego uprawnienia ma dany user. Niestety ten aspekt wielu ludzi "gubi" w czasie pisania aplikacji. Robią akcje napisane, mają uprawnienia, ale zapominają obie te rzeczy powiązać. To jest jeden z dość częstych błędów: brak lub szczątkowe zabezpieczenia na różnych poziomach.

Kwiatki takiego pokroju sam widziałem. Takie, gdzie z powodu braku spostrzegawczości potrafiło w czasie ładowania strony zahydrować przez Doctrine2 całą bazę - także.

[O$iek]

Co to znaczy "hydrować"? (IMG:style_emoticons/default/smile.gif)

[Sephirus]

"hydrować" oznacza w jaki sposób zwracać rekordy/dane z bazy danych. Przykładowo można zwracać pojedynczy rekord z tabeli jako tablica asocjacyjna, zwykła, obiekt klasy stdClass, wartość pierwszej kolumny itd.

W PDO podobną rzeczą jest "FetchMode".

[sowiq]

Pozwalasz na jakieś akcje? Ogranicz to uprawnieniami tak mocno jak sie da. Taka przykladowa deletAll, nawet gdyby zadziałała, rąbnęła by nie całość bazy, ale maksymalnie to, do czego uprawnienia ma dany user.

Chyba nie zrozumiałeś co miałem na myśli i ogólnie jaka jest idea wykonywania takich operacji za pomocą POST, a nie GET.

Masz stronę z komentarzami. Ktoś dodaje w komentarzu obrazek z URL takim, jak Ci napisałem powyżej. Oglądasz komentarz zalogowany jako admin i bach bah!, posty poleciały. Ogląda to dowolny inny user (wstrzyknięty inny URL obrazka) i bach bah! - jego posty też poleciały. XSS nie polega na tym, że dowolny user bez uprawnień usunie coś z bazy danych. Polega na tym, że przeglądarka users z uprawnieniami wykonuje w tle requesta pod URL wstrzyknięty w ten lub inny sposób przez atakującego. Wydaje mi się, że mylisz te dwa pojęcia.

Zezwalanie na modyfikację danych tylko za pomocą zapytań POST znacznie ogranicza możliwości takiego ataku. Oczywiście można też robić jakieś jednorazowe tokeny wysyłane w GET itp., ale specyfikacja protokołu HTTP mówi jasno - odczyt danych = GET, modyfikacja danych = POST.

Ten post edytował sowiq 15.01.2013, 14:17:58

[Sephirus]

Polega na tym, że przeglądarka users z uprawnieniami wykonuje w tle requesta pod URL wstrzyknięty w ten lub inny sposób przez atakującego.

Tak BTW to to bardzo kojarzy się z XSRF (CSRF) - który często jest celem dla samego XSS (choć może działać bez niego oczywiście).

[O$iek]

"hydrować" oznacza w jaki sposób zwracać rekordy/dane z bazy danych. Przykładowo można zwracać pojedynczy rekord z tabeli jako tablica asocjacyjna, zwykła, obiekt klasy stdClass, wartość pierwszej kolumny itd.

W PDO podobną rzeczą jest "FetchMode".

Dzięki.

[ano]

Oczywiście, że to zalecenie projektowe, nikt Ci przecież nie każe na siłę tak robić. Ale jest to zalecenie dotyczące bezpieczeństwa. I nie chodzi tu o to, że "atakującemu" będzie trudniej wysłać takie zapytanie, bo to akurat pryszcz. Chodzi o XSS, o którym wspomniałem wcześniej. Jak na Twojej stornie masz jakąś dziurę pozwalającą na XSS, której nie zauważyłeś i ktoś doda Ci taki obrazek jak poniżej, to masz mały problem.

[HTML] pobierz, plaintext 
<img src="/admin/post.php?act=deleteAll&confirmed=1" />
[HTML] pobierz, plaintext 

Chodzi o to, że zapytania POST nie da się wygenerować za pomocą prostego XSS. Musiałaby to być mega dziura pozwalająca na dodanie JS (IMG:style_emoticons/default/smile.gif)

[edit]

Kiedyś pracowałem przy rozbudowie jednego z większych portali obrazkowych w USA i widziałem identyczny kwiatek. Więc to nie jest domena tylko tych młodszych programistów i tylko tych mniejszych projektów (IMG:style_emoticons/default/wink.gif)

Kluczem problemu nie jest XSS a CSRF, którego w żaden sposób nie zabezpieczy to, że akceptujemy tylko requesty POST. (Bardzo łatwo wykonać "automatycznego" POSTA - wystarczy jedna linijka JSa ;-) )
Mała autoreklama - więcej info na: http://tinyurl.com/boqerob ;-)

[sazian]

używanie gdzie popadnie różnych fantastycznych wynalazków cudownego dziecka skryptu typu eval, goto, dynamiczne generowanie zmiennych - ekstrakcja to mały pikuś przy tym

a widziałeś skrypt forum vbulletin ? tam co chwilę masz eval na jakiś kod pobierany z bazy. Edytowanie tego to istna masakra szczególnie jak trafisz na funkcje której połowa kodu jest zapisana w bazie

[pamil]

+ do wykonania CSRF wcale nie potrzebujemy dziury XSS w atakowanej stronie (IMG:style_emoticons/default/smile.gif)

[Lysiur]

Wiecie co, od samego początku powstania tego tematu śledziłem jego rozwój. Jak go tylko zobaczyłem pomyślałem "oho, będzie się działo" (ironia). Niestety dalej podtrzymuje takie stanowisko w tej sprawie (IMG:style_emoticons/default/smile.gif) Temat raczej nie jest specjalnie pomocny, nawet jak na temat for fun. Sorry, jestem zgorzkniałym zgredem, ale takie jest moje odczucie. Myślę, że bardziej konstruktywnym tematem, byłoby zestawienie praktycznych, poprawnych i przydatnych postów (nie antywzorców). Czemu tak? Często jest zdarza się (zwłaszcza na początku), że zobaczymy jakiś przykład (z głupawym antywzorcem) i go stosujemy - bo nam działa. Mimio, iż doskonale zdajemy sobie sprawę, że nie jest to dobre i wmawiamy sobie, że później to poprawimy. Początkujący chwytają się wyszystkiego by tylko działało i poczuli się lepiej, że coś udało im się stworzyć konstruktywnego.

Przeglądając posty z tego tematu, nawet nie natknąłem sie (a jeśli tak - to zwracam honor) na tak banalny antywzorzec jak najprosztsze generowanie całej storny przy pomocy instrukcji echo

[PHP] pobierz, plaintext 
echo '<table>
             <tr><td>'.$zmienna.'</td></tr>
        </table>';
[PHP] pobierz, plaintext 

A często się zdarzają się w postach takie perełki.

Czy nie lepszym tematem byłby zbiór "Przydatnych i ciekawych rozwiązań", który mógłby zawierać jakieś przydatne fragmenty, które uczyły by początkujących dobrych praktyk i sprawdzonych metod? Opis rzadko używanych funkcji, z których warto skorzystać w takiej - a nie innej sytuacji. Krótkie omówienie najprostszych wzorców obiektowych w sposób praktyczny, z ew. linkami do dalszej lektury. W końcu każdy ma inne podejście do wzorców i temat ten mógłby być ciekawym polem do dyskusji. Podobnie jak sposób w jaki przystępujęcie do projektowania danego zagadnienia, na co zwracacie uwagę i czego używacie - maind mapów, etc.

wydaje mi się, że takie tematy byłby częściowo for fun, jak i przydatne dla każdego z nas. Dziś takiego tematu nie zacznę - bo nie mam na to czasu, ale myślę, że z czasem rozpocznę taki cykl "dłuższych" tematów.

Pozdrawiam i dobrej nocy!

[Sephirus]

@pamil Masz rację - tak jak wcześniej pisałem CSRF nie wymaga XSS ale jeśli mamy możliwość jakiegoś XSS z Javascript to CSRF staje się dużo bardziej niebezpieczny.

@Lysiur Masz rację i nie masz (IMG:style_emoticons/default/smile.gif) To prawda że temat to jeden wielki chaos ale powiem Ci szczerze, że sam czegoś się nauczyłem lub sobie przypomniałem a nie uważam się za początkującego. Pisząc jak coś robić a nie czego nie robić to dobra praktyka, niekiedy jednak dobrze jest spojrzeć na to z drugiej strony. Zresztą - jeśli opisujemy jakiś zły nawy, błąd itp. to automatycznie dajemy info o tym jak to powinno być zrobione poprawnie.

[!*!]

Przypomniała mi się rzecz która zdarza się dość często, mianowicie masowa produkcja niepotrzebnych zmiennych, lub złe odwołania do funkcji.

[PHP] pobierz, plaintext 
include 'cfg.php';
if(isset($config))
{
   $this->cfg = $config;
}
 
echo $this->cfg['host'];
 
//plik cfg.php:
$config = array();
[PHP] pobierz, plaintext 

Zamiast:

[PHP] pobierz, plaintext 
$this->cfg = include_once 'cfg.php';
//plik cfg.php:
return array();
[PHP] pobierz, plaintext 

Jeśli zaś chodzi o funkcje...

[PHP] pobierz, plaintext 
function Foo(){ // tu jakaś super skomplikowana funkcja która liczy i liczy i liczy... aż w końcu zwraca wynik
 
// a tu taki psikus
while()
{
echo Foo();
}
 
// zamiast
 
$r = Foo();
while()
{
echo $r;
}
[PHP] pobierz, plaintext 

Oczywiście są to w miarę proste przykłady, ale one potrafią się rozbudować szczególnie przy fantazji początkujących.
Do tego dojdzie jeszcze upieranie się że funkcje mają przewagę nad całym OOP (IMG:style_emoticons/default/biggrin.gif)

Ten post edytował !*! 16.01.2013, 11:12:39

[CuteOne]

@Lysiur pomysł dobry ale..
- nie było by żadnej konstruktywnej dyskusji tylko spam o dupie maryli (zobacz tematy w PHP/Pro). W najlepszym wypadku był by to spam, wnoszący rąbek wiedzy w dany temat..
- druga sprawa to hateowanie zaproponowanych rozwiązań.. i nie mówię tu o konstruktywnej krytyce, którą zawsze jest miło usłyszeć a o zwykłym wyśmiewaniu się tych "pseudo proprogramistow"

[Lysiur]

@CuteOne: Niestety muszę się z Tobą zgodzić. Prawda jest taka, że w natłoku śmieciowej wiedzy i puszenia się, rośnie ilość tandetnych wpisów na które poprostu szkoda czasu (IMG:style_emoticons/default/smile.gif) Idea byłaby fajna, gdyby dało się nad tym rozsądnie zapanować (IMG:style_emoticons/default/smile.gif) A tak to przegląda się dziesiątki informacji z których nic nie wynika.

Swoją drogą przypomina się wpis na blogu, jakiegoś speca od JS (IMG:style_emoticons/default/smile.gif) Twierdził on bowiem, że

[HTML] pobierz, plaintext 
....
var aArray = new Array();
 
//Jest wolniejsze i zabiera więcej pamięci niż konstrukcja:
 
var aArray = [];
....
[HTML] pobierz, plaintext 

Co najlepsze tkwił w przekonaniu, wręcz zarzekał się, że druga opcja nie wywołuje konstruktora :-) Padłem plackiem ;-)

[sowiq]

Twierdził on bowiem, że

[JAVASCRIPT] pobierz, plaintext 
var aArray = new Array();
//Jest wolniejsze i zabiera więcej pamięci niż konstrukcja:
var aArray = [];
[JAVASCRIPT] pobierz, plaintext 

No i miał rację (oczywiście oprócz konstruktora). Książka "Wysoko Wydajny JavaScript" autorstwa Nicholasa C. Zakasa (O'Reilly) powiada tak:

Chociaż z technicznego punktu widzenia nie ma nic złego w tym podejściu [mowa o 'new Array()' i 'new Object()' - przyp. sowiq], literały są interpretowane szybciej. Dodatkowym bonusem jest fakt, że literały zajmują mniej miejsca w kodzie, więc rozmiar całego pliku jest mniejszy [czyli zajmuje mniej pamięci - przyp. sowiq]
[...]
W miarę jak rośnie liczba właściwości obiektów i elementów tabel, rośnie również korzyść z użycia literałów.

To tak odnośnie puszenia się (IMG:style_emoticons/default/wink.gif)

Ten post edytował sowiq 16.01.2013, 16:35:02

[amii]

Jeśli już jesteśmy przy JS to warto wspomnieć o domknięciach a zwłaszcza domknięciach tworzonych w pętli pamiętam jak swego czasu miałem WTF odnośnie takiej konkstrukcji. Tu się można dokładnie zaznajomić z kwestią domknięć : https://developer.mozilla.org/en-US/docs/Ja.../Guide/Closures

A jeśli chodzi o php to kiedyś przez ten błąd(?) nie przyjęli mnie do roboty, mianowicie chodziło o ciapki w php, które są szybciej przetwarzane (firma miała hopla na punkcie szybkości i wydajności bo pisali aplikacje pod urządzenia mobilne a było to z 3 lata temu).
Teraz pamiętam, że jeśli nie ma zmiennych w środku to robimy tak:

[PHP] pobierz, plaintext 
'ala ma kota';
[PHP] pobierz, plaintext 

a ze zmiennymi lepiej tak:

[PHP] pobierz, plaintext 
"ala ma $zmienna";
[PHP] pobierz, plaintext 

To chyba było ale jeśli coś wypluwamy na widok to lepiej dopisywać do zmiennej a nie walić echami i printami

[sazian]

Teraz pamiętam, że jeśli nie ma zmiennych w środku to robimy tak:

[PHP] pobierz, plaintext 
'ala ma kota';
[PHP] pobierz, plaintext 

a ze zmiennymi lepiej tak:

[PHP] pobierz, plaintext 
"ala ma $zmienna";
[PHP] pobierz, plaintext 

a ja bym powiedział zawsze robimy tak

[PHP] pobierz, plaintext 
'ala ma kota';
'ala ma '.$zmienna;
[PHP] pobierz, plaintext 

dlatego że tak jest czytelniej

[pyro]

a ja bym powiedział zawsze robimy tak

[PHP] pobierz, plaintext 
'ala ma kota';
'ala ma '.$zmienna;
[PHP] pobierz, plaintext 

dlatego że tak jest czytelniej

I jak chce się przefiltrować zmienną jakąś funkcją, to nie trzeba nic już robić z cudzysłowami. Mniejsze narażanie się na parse errory (IMG:style_emoticons/default/tongue.gif)

[!*!]

Poprawne ścieżki chyba jeszcze nie zostały wymienione.

[PHP] pobierz, plaintext 
$path = 'C:\\tajny katalog\cololwiek';
[PHP] pobierz, plaintext 

Już pomijam podanie nazwy dysku, bo powodów może być dużo... chodzi tu o separator katalogów, windows to jedyny system na świecie gdzie dopuszczalne są dwie wersje \ oraz /

Jednak, aby nasz skrypt działał na wszystkim, nawet na tosterze trzeba używać /

[PHP] pobierz, plaintext 
$path = '/tajny katalog/cololwiek';
[PHP] pobierz, plaintext 

W ostateczności, jeśli się czegoś boimy, mamy fobie lub nałogowo skubiemy słonecznik:

[PHP] pobierz, plaintext 
$path = DIRECTORY_SEPARATOR.'tajny katalog'.DIRECTORY_SEPARATOR.'cololwiek';
[PHP] pobierz, plaintext 

DIRECTORY_SEPARATOR ma jedną wadę, nie na wszystkich serwerach istnieje więc trzeba pierw to sprawdzić, jednak zalecałbym po prostu dostosowanie się i używanie / które obsłuży każdy system.

[ano]

A jeśli chodzi o php to kiedyś przez ten błąd(?) nie przyjęli mnie do roboty, mianowicie chodziło o ciapki w php, które są szybciej przetwarzane (firma miała hopla na punkcie szybkości i wydajności bo pisali aplikacje pod urządzenia mobilne a było to z 3 lata temu).
Teraz pamiętam, że jeśli nie ma zmiennych w środku to robimy tak:

[PHP] pobierz, plaintext 
'ala ma kota';
[PHP] pobierz, plaintext 

a ze zmiennymi lepiej tak:

[PHP] pobierz, plaintext 
"ala ma $zmienna";
[PHP] pobierz, plaintext 

To chyba było ale jeśli coś wypluwamy na widok to lepiej dopisywać do zmiennej a nie walić echami i printami

To się ciesz, że Cię tam nie przyjeli - nie ma różnicy w wydajności w runtime pomiędzy " a '. Jeżeli oni ją odczuwają to trzeba im było doradzić, żeby zaczęli korzystać z APC ;-)

Bardzo dokładnie i dobrze wytłumuaczył to jeden z contributorów php:
https://github.com/fabpot/Twig/issues/407#i...comment-1725017
Masz tam nawet linki do konkretnych linijek kodu c++ za to odpowiedzialnego ;-)

[!*!]

@up czyli jak mam odebrać te wyniki, bo nie za bardzo rozumiem.

[PHP] pobierz, plaintext 
print timeFunc('Method1', 1000) . "\n<br>"; //0.000177661 
print timeFunc('Method2', 1000) . "\n<br>"; //0.000128326
[PHP] pobierz, plaintext 

[skowron-line]

- Kod bez komentarzy to zuo, o tym trzeba pisać to trzeba piętnować.
- Zapytanie w pętli
- Pętla w pętli pętlą popętla

Ten post edytował skowron-line 18.01.2013, 12:40:34

[ano]

@up czyli jak mam odebrać te wyniki, bo nie za bardzo rozumiem.

[PHP] pobierz, plaintext 
print timeFunc('Method1', 1000) . "\n<br>"; //0.000177661 
print timeFunc('Method2', 1000) . "\n<br>"; //0.000128326
[PHP] pobierz, plaintext 

? Jak odebrać te wyniki? Nie mam pojęcia bo nie wiem co to za wyniki, co ma robić ten kod, jak wygląda timeFunc? Itd. Poza tym te dwie linijki są takie same ;-)

I przeczytaj dokładnie wpis z githuba a wszystko stanie się jasne.

[!*!]

@up to są wyniki funkcji z linku jaki podałeś.

[redeemer]

!*!: Ten "test" jest nierzetelny, nie powinno tam być microtime(true)?

[ano]

@redeemer - o, kolejna rzecz którą można dopisać do listy z tego tematu ;]
Oczywiście, że powinno być (true)

@!*!
A jesteś świadomy, że 0.000177661 seconds = 0.177661 milliseconds
=> wartość nieistotna, równie dobrze może to być błąd pomiarowy, wyższe obciążenie CPU na te 0.12 milisekundy... itd itp.

Poza tym przeczytaj wszystko co ja napisałem i co piszą "tam":
Jakby koleś odpalił drugi raz ten skrypt (na php z włączonym APC) to wynik dla " i ' byłby IDENTYCZNY.

[!*!]

redeemer - może i powinno to nie jest istotne, obojętnie jakbyśmy tego nie mierzyli, wynik będzie z korzyścią dla przykładu drugiego, gdzie używasz apostrofów a zmienne są poza nimi.

@ano - tak, przeczytałem i uważam że On się myli. Nie znam się na C, jednak pokaż mi przykład kodu, porównanie gdzie wyniki będą identyczne, dla obu przykładów (kolejność obojętna).
Jedyne z czym się zgodzę to że tzw. tokenizacja przebiega w sposób identyczny dla obu wariantów. Jednak jak pokazują przykłady wyżej samo "tłumaczenie" ich już nie.

I tak, widzę różnice miedzy (IMG:style_emoticons/default/wink.gif)

0.00018066... "ble$foo"
0.00012027... 'ble'.$foo

Przy "kliku" pętlach nie ma to znaczenia, ale przy czymś bardziej rozbudowanym? Tak, jest APC czy inne wspomagacze, ale to nie o to chodzi, bo tym sposobem możemy wrócić do pisania stron w C, przecież będą wydajniejsze.

I jak już ktoś tu wspomniał, trudno będzie z "ble$foo" wybrać $foo używając np. token_ get_ all (IMG:style_emoticons/default/wink.gif) Chyba że się nie zrozumieliśmy i każdy z Nas mówi o czymś innym.

Ten post edytował !*! 18.01.2013, 20:21:37

[ano]

Tak, jest APC czy inne wspomagacze, ale to nie o to chodzi, bo tym sposobem możemy wrócić do pisania stron w C, przecież będą wydajniejsze.

Sorry, ale o czym Ty mówisz? Co to za porównanie APC do pisania stron w C? Używanie APC powinno być NATURALNE i normalne, a nie jakieś "WOW!".
To tak jakbyś pisał stronę w C++, która przy każdym requeście musi się na nowo kompilować...

Kilka wywołań pętli. Dokładniej tam jest 1 000 000 000 wywołań pętli. I dalej jest to na granicy błędu statystycznego.
Po to dałem ten link, żebyś miał również szansę zobaczyć na kodzik C++, który realizuje tokenizację " i ' i samemu się przekonać, że jego złożoność jest praktycznie identyczna...

[!*!]

To nie było porównanie. Granice błędu statystycznego? Ok, niech będzie. Tylko nie pisz że oba warianty są tożsame.

[ano]

Żeby nie było, małe podsumowanie:
Oczywiście najlepszą praktyką jest stosowanie '.
Jednak warto mieć świadomość z czego to wynika i dlatego wiedzieć, że stwierdzenie, że skrypt zawsze będzie szybszy w porównaniu z użyciem " jest błędne.
Natomiast w niektórych sytuacjach użycie " jest uzasadnione i nikt za to nikogo nie powinien wylewać z pracy (IMG:style_emoticons/default/wink.gif) ))

@!*! - ok, prostuje: oba warianty są tożsame już po pierwszym odpaleniu skryptu, gdy używa się APC bądź innego narzędzia cache'ującego skompilowany bytecode :-)

Ten post edytował ano 18.01.2013, 21:15:46

[!*!]

Jednak warto mieć świadomość z czego to wynika i dlatego wiedzieć, że stwierdzenie, że skrypt zawsze będzie szybszy w porównaniu z użyciem " jest błędne.
Natomiast w niektórych sytuacjach użycie " jest uzasadnione i nikt za to nikogo nie powinien wylewać z pracy (IMG:style_emoticons/default/wink.gif) ))

Moim zdaniem jest błędne, ponieważ po co nakładać na parser dodatkową robotę? Wyciąganie " i ' w formie tokenu przebiegnie tak samo, ale już " trzeba przemielić pod kątem, czy przypadkiem coś jeszcze się w nim nie znajduje, a po co skoro są lepsze zapisy? Pisząc zmienne w cudzysłowach skazujemy siebie i innych na porażkę przy debugowaniu, lub chociażby przy prostym zliczeniu zmiennych i wyświetleniu ich nazw.

Mając kod

[PHP] pobierz, plaintext 
'text'.$foo; // będzie wiadomo że jest string i zmienna
"text $foo"; // tu będzie tylko string
[PHP] pobierz, plaintext 

Pisząc jakiś prosty debuger, lub dokumentator, musiałbym robić dokładnie to samo z cudzysłowem co parser... Przemielić je jeszcze raz w poszukiwaniu zmiennych.
Więc jaki jest tego sens, skoro wariant pierwszy jest prostszy, szybszy i czytelniejszy?

ps. podane wyniki zostały zredukowane przeze mnie do obrotu 1000 x 1000, zwiększając te wartości przepaść, którą nazywasz błędem statystycznym jest o wiele bardziej widoczna, ale to już każdy może sobie sprawdzić sam.

Ten post edytował !*! 19.01.2013, 14:16:10