Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Dziwna mania niektórych użytkowników
Forum PHP.pl > Inne > Hydepark
Stron: 1, 2
domis86
symfony czarodziej.gif
Sedziwoj
Cytat(Zyx @ 30.07.2008, 19:29:04 ) *
Żeby było śmieszniej, po zwróceniu uwagi byłem jeszcze pouczany, że "przecież zmienne tymczasowe ułatwiają debugowanie, bo można zrobić w razie potrzeby rzecz następującą albo np. coś dalej przetwarzać tekst zapytania":


A bawiłeś się Xdebug? Jakbyś się bawił to byś wiedział skąd się to bierze. Do tego wiesz co przekazywane jest do funkcji, po nazwie zmiennej, widzisz wszystkie parametry, a nie never ending line.
A swoją drogą testowałeś jak wpływa na wydajność takie "nad używanie"?
Oczywiście mówię o przypadku SQL, bo za każdym razem przy np. filtrowaniu stringu nowa zmienna to śmietnik.

Cytat(Zyx @ 30.07.2008, 22:09:47 ) *
Ale dodaję je tylko, gdy w danym miejscu faktycznie jest problem i po jego likwidacji usuwam. Gdybym dopuścił np. taki wygląd zapytań, to równie dobrze mógłbym zapytać, co w takim razie jest źle z drugim podanym kodem? Przecież tu też można by się tłumaczyć kwestiami debugowania, że będę chciał wyświetlić dane po przepuszczeniu przez którąś z kolei funkcję. I tak po kolei dojdziemy do kodu-potworka w stylu:

Kod
$wyrazenie = ($a == 5);
if($wyrazenie)
{
   $arg1 = 1;
   $arg2 = 5 + $a;
   $wynik = funkcja($arg1, $arg2);
   echo $wynik;
}


I też go względami debugowania będę mógł obronić dokładnie tak samo, jak zapis:

Kod
$query = 'SELECT ...';
mysql_query($query);


Tylko że w pierwszym przypadku, debugując (mówię ciągle o Xdebug) widzisz czy wchodzi w warunek, a w drugim nie wiesz co jest przekazywane. Do tego mój argument o długości linii.

Cytat(Zyx @ 30.07.2008, 22:09:47 ) *
Prawda jest taka, że w dobrze przemyślanym problemie prawdopodobieństwo zajścia takiego zdarzenia jest BARDZO MAŁE, a jeśli już zajdzie, zawsze jest Ctrl+C/Ctrl+V. Od tej 0,5 sekundy więcej na wpisanie świat się nie zawali. Gdy zaś muszę sięgać zbyt często po ten środek, znaczy to, że rozwiązanie wymyślałem na kolanie, jest ono kiepskie i lepiej będzie, jak siądę nad kartką i wymyślę nowe.

Prawda jest taka, że jak debugujesz większy skrypt, to takich miejsc poprawek możesz mieć sporo i tylko coś bierze jak musisz dopisać, aby sprawdzić czy wszystko jest ok.
Cytat
Jeżeli coś potrzebuje stałego debugowania włączanego na rozkaz, piszę taki kod, by robił to za mnie.

I obciążasz dodatkowo, kod który jest dobrze napisany sam powie że coś jest nie tak i powie co (co prawda dokładniejsze informacje zostawić tylko dla siebie, a wyświetlać te pobieżne)


Jest mowa o kwerendach, ale sprawa się tyczy wszystkich parametrów funkcji podstawowych, gdzie nie mamy możliwości sprawdzenia co dokładnie przekazujemy.
terabit
Cytat(domis86 @ 31.07.2008, 23:23:23 ) *
symfony czarodziej.gif


eee ale nie framework winksmiley.jpg (wiem, wiem, jest suuper winksmiley.jpg)
to już lepiej coś co dobrze go wykorzystuje :]
Fantazyn
Cytat(nospor @ 31.07.2008, 11:11:43 ) *
mysql_query($q) or die('zap:'.$q)

No w powaznych projektach nie moze byc takich bzdur, ale dla osob poczatkujacych jest to a w sam raz.
A to ze trzeba pisac "caluśnie" to inna sprawa.


A ja pozwolę sobie skromnie poprosić kogoś o odpowiedź, jak powinna wyglądać pełna obsługa podanego wyżej błędu? Czy musi to być obiektowo?

Edit: Dziękuję Sedziwoj.
Sedziwoj
Cytat(Fantazyn @ 31.07.2008, 23:41:07 ) *
A ja pozwolę sobie skromnie poprosić kogoś o odpowiedź, jak powinna wyglądać pełna obsługa podanego wyżej błędu? Czy musi to być obiektowo?


Nie musi być obiektowo, obiektowość ułatwia jeśli się dobrze napisze późniejsze wykorzystanie.
A co do obsługi
Cytat
mysql_query() returns a resource on success, or FALSE on error
więc trzeba sprawdzić co zwróciła funkcja, jeśli false, to mysql_errno() i/lub mysql_error() co umożliwia nam stwierdzić co jest nie tak. Oczywiście to dopiero początek, bo trzeba przecież jakoś przekazać te błędy, potem je obsłużyć itp. ... można pisać w nieskończoność.
Zyx
Sędziwój, chyba wyraźnie napisałem, że jak potrzebujesz tej zmiennej do jakichś wyższych celów, pytania z mojej strony nie było. Jeśli faktycznie Twój Xdebug daje Ci bonusy za przekazywanie wartości przez zmienną, zamiast bezpośrednio, nie ma sensu tego zmieniać. Mój tak nie robił w czasach, gdy go używałem, zresztą do dziś się już mogło pozmieniać trochę, więc nawet o nim nie wspominałem. Weź też pod uwagę, że skoro ty musisz podczas pisania kodu wyświetlać wartości 818373767 argumentów, nie znaczy to, że ja też muszę, nawet jeśli projekt jest duży.

Ad. argumentu o obciążaniu -> toć przecież napisałeś dokładnie to samo, co ja, tylko innymi słowami, więc czego się czepiasz?

Podsumowując: zmienne tymczasowe są bez sensu, jeśli niczemu nie służą, tzn. ktoś tak napisał, bo widział tak samo w innym skrypcie, bez zastanawiania się nad sensem ich istnienia.
Sedziwoj
Cytat(Zyx @ 2.08.2008, 12:40:36 ) *
Sędziwój, chyba wyraźnie napisałem, że jak potrzebujesz tej zmiennej do jakichś wyższych celów, pytania z mojej strony nie było. Jeśli faktycznie Twój Xdebug daje Ci bonusy za przekazywanie wartości przez zmienną, zamiast bezpośrednio, nie ma sensu tego zmieniać. Mój tak nie robił w czasach, gdy go używałem, zresztą do dziś się już mogło pozmieniać trochę, więc nawet o nim nie wspominałem. Weź też pod uwagę, że skoro ty musisz podczas pisania kodu wyświetlać wartości 818373767 argumentów, nie znaczy to, że ja też muszę, nawet jeśli projekt jest duży.

Wyświetlić? Czy Ty na pewno wiesz o czym ja mówię?
Cytat
Podsumowując: zmienne tymczasowe są bez sensu, jeśli niczemu nie służą, tzn. ktoś tak napisał, bo widział tak samo w innym skrypcie, bez zastanawiania się nad sensem ich istnienia.


Dokładnie, chodziło o sens używania zmiennych do przechowywania stringów złożonych z części statycznych i z zmiennych, przekazywanych do funkcji wbudowanych w język.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.