Witam.
Często w kodach można się spotkać z zapisami zmiennych np. $sNazwa, $aNazwa, $_nazwa. Rozumiem że 's' ,'a' to określenie typów zmiennych. Po co się to stosuje i kiedy to jest przydatne i czy nejlepiej zawsze jest to stosować. Czy nie wystarczy w komentarzach klasy opisać typ zmiennej. No i jeszcze '_' - to kompletnie nie wiem co oznacza. Fajnie jakby ktoś rzucił linkiem żebym mógł poczytać, bo googlarkę nie wiem o co pytać.

To jest tzw notacja węgierska.

Zależy od osoby. Jedni stosują, inni nie. Stosuje się to po to, żeby nie zastanawiać się/sprawdzać jaki typ ma dana zmienna. Przydatne jest w zasadzie zawsze. $_nazwa osobiście używam przy zmiennych statycznych, nie wiem czy ma to jakieś inne użycie.

Dlaczego przydatne zawsze? Osobiście nigdy nie potrzebowałem tego typu podpowiedzi - szczególnie w dobie zaawansowanych IDE, gdzie najeżdżam na atrybut/zmienną i wiem wszystko co potrzebuję.



W standardzie kodowania ZF takim prefiksem oznacza się zmienne i funkcje prywatne/chronione.

Dla mnie przydatne ze względu na programowanie na różnych komputerach, czasem w domu, czasem poza domem na laptopie, czasem dopisywanie czegoś w biegu na telefonie (bo coś "nagle, samo z siebie przestało działać" ). Więc nie zawsze z dostępem do eclipse, z którego to korzystam.

Z ZF styczności zbytnio dużej nie mam, miałem chęci nauczenia się korzystania z tego tałatajstwa ale jakoś nie wiedziałem do końca z której strony się zabrać. Parafrazując stare przysłowie, co programista to obyczaj.


Zresztą, co ten temat robi w tym dziale?;o

Jeśli używasz phpDoc, to po co Ci dostęp do Eclipse?

Kiedys uzywalem tej "notacij wegierskiej" - niepotrzebna, a potem jak potrzebujesz wpisac zmienna wraz z uzyciem podpowiadania to.... musisz wiedziec jakiego jest typu, a skoro musisz wiedziec to po co ci go zapisywac.

$sNa<ctrl+spacja>

wiec jest to bez sensu.

Nazwy moich zmiennych jednoznacznie wskazuja na typ zmiennej:
$userName; // string
$postCount; // int
$post; // object
$posts; // array/collection of objects

tam gdzie sie tak nie da - to coz pozostaja komentarze.

Zmienne statyczne (rozumiem ze klasy) - po co jakos je wyrozniac skoro i tak sie do nich odwolujemy przez
self::$statyczna;
a deklarujemy uzywajac "static"

A teraz mi pokaż gdzie napisałem o używaniu phpDoc.

w zupełności zgadzam się z dr_bonzo. notacji węgierskiej używam tylko przy JS, a i tam można bez tego - kwestia przyzwyczajenia.
Poza tym, tak jak napisał przedmówca, dla mnie również najważniejsze jest to, żeby nazwa zmiennej jak najwięcej mówiła o sobie, ale bez zbędnych przyrostów.

A jak widze czasem zmienne typu $a,$b,$zmienna... to mnie krew zalewa

Notacji węgierskiej używałem z powodzeniem przez długi czas i bardzo dobrze mi służyła. Jednak w momencie, jak przesiadłem się na Eclipse, od razu z takiego zapisu zrezygnowałem. Obecnie stosuję taki zapis, jak przedstawił ~dr_bonzo.
Notacja węgierska dobrze się sprawdza w bazie danych. Przede wszystkim odpada problem słów kluczowych.
A znak podkreślenia ( _ ) nie został wymyślony przez ZF. Jest to powszechna praktyka stosowana do oznaczenia prywatnych i chronionych metod i właściwości.

~Vielta - napisałeś o przenośności, ja odpowiedziałem. [;

Czytaj, co piszę.

...za czasow php 4 gdzie nie dalo sie okreslac poziomu widocznosci zmiennych - wszytkie byly publiczne.
A dobre IDE - podpowie ci nazwe zmiennej, a na liscie, obok zaznaczy poziom jej widocznosci. Wiec.... ja tej metody nie uzywam

@erix:
Mea culpa, późna godzina jest (tjaa). Notacja węgierska to w moim wypadku przyzwyczajenie po czasach gdy pisałem jeszcze korzystając z np. N++ czy innych programów, w których podpowiadanie składni, etc. nie jest takie dobre jak w Eclipse czy Netbeansie. W sumie czas zacząć używać phpdoc'a

Używam NetBeans 6.5 i notacji węgierskiej. Dzięki niej łatwiej mi się segreguje zmienne w końcowej fazie przez co jeśli muszę coś zmienić jest to banalnie proste. Nie muszę używać żadnych skrótów czy klikać po menusach, żeby wiedzieć za co odpowiada jaka zmienna. Polecam stosowanie tej metody w PHP.
i = integer
s = string
c = char
m = mixed
b = boolean
a = array
r = resource
_ = private / protected ( przestałem stosować to w zmiennych kiedy przerzuciłem się na notacje węgierską. Teraz tego prefiksu używam tylko w nazwach metod )

Dzisiaj na przykład machnąłem sobie klasę która mi pobiera pliki z serwera FTP i je obrabia.

[PHP] pobierz, plaintext 
<?php
private $sFtpUser = '';
private $sFtpPass = '';
private $sFtpAddress = '';
private $rFtpLink;
 
public function init(Context $c)
{
    // Connect to FTP server
    $this->rFtpLink = ftp_connect($this->sFtpAddress);
 
    // check connection and login
    if(!$this->rFtpLink || !ftp_login($this->rFtpLink, $this->sFtpUser, $this->sFtpPass))
    {
        throw new Error('app.ctrl.data.update.auth');
    }
 
    //(...)
 
    // close the FTP stream
    ftp_close($this->rFtpLink);
}
?>
[PHP] pobierz, plaintext 

W sumie wydaje mi się że takie manipulacje na FTP powinny odbywać się w modelu, ale już nie chciało mi się bawić w te ceregiele zwłaszcza że model w moim FW jest kiepsko obsługiwany.

@orglee: ftpUser, ftpPass, ftpAddress - już po tym widać co w tej zmiennej jest. rFtpLink zamień na ftpStream czy ftpHandle.
Ale w sumie... jak Ci pasuje to zostaw jak jest, trochę śmieszne jest bo rFtpLink czasami jest resourc'em, a czasami booleanem tak naprawdę, ale..

I tutaj dochodzimy do największej wady PHP - brak ścisłej kontroli typów. Pół biedy, gdyby funkcje zwracały zawsze ten sam tym danych, a nie raz zasób, a raz bool.

Dlatego należy traktować to jako "oczekujemy resource"

@batman: czy brak ścisłej kontroli typów to największa wada PHP? Nie powiedziałbym. Ale wsteczna kompatybilność powoduje że taka ftp_connect() zamiast rzucić wyjątkiem zwróci false.

@bim2: I jaki to ma wtedy sens skoro programista nadal musi dojść do tego jakim typem jest dana zmienna/pole? Bo na oznaczeniu w nazwie nie może do końca polegać, a kod staje się wtedy wręcz zdradziecki:

[PHP] pobierz, plaintext 
<?php
 
$aMyArray = array(...);
$aMyArray = doSth();
 
if($aMyArray === false){
   //wtf?
}
?>
[PHP] pobierz, plaintext 

Proszę, bez demonizowania PHP nie jest ściśle typowany i nie będzie. Koniec i kropka.
Ma to swoje wady (trudniejszy debug) i zalety (niski próg wejścia)

[PHP] pobierz, plaintext 
<?php
/**
 * @var array|bool
 */
$aMyArray;
 
// Da się? da.
?>
[PHP] pobierz, plaintext 

Mimo wszystko kod, który przedstawiłeś, jest po prostu złym kodem i nie świadczy u ułomności PHP, a raczej o kiepskich zdolnościach programisty.

~LBO
Kod przedstawiony jest jak najbardziej na miejscu. Oto przykład:

[PHP] pobierz, plaintext 
<?php
// z jakiegos powodu w zmiennej jest false, a nie tablica
$aMyArray = false;
echo implode('.', $aMyArray);
?>
[PHP] pobierz, plaintext 

Powyższy kod spowoduje powstanie warninga:

Przy ścisłej kontroli typów nie byłoby to możliwe. A jeśli PHP byłoby napisane z sensem, to funkcja, która zwróciła false, rzuciłaby wyjątkiem lub zwróciła pustą tablicę (taki bezsens wydaje mi się bardziej możliwy, patrząc na obecne dokonania twórców PHP).

@batman, ja nie piszę, że się nie da. Ja piszę, że ten przykładowy kod jest gówniany i każdy programista, który żongluje tak typami (ponieważ się da, phi) byłby u mnie skreślony.

Podobnie jest na wyższym poziomie abstrakcji - dajmy na to OOP. Wiele rzeczy można tam zrobić, ale nie oznacza to, że się powinno. Jeden wzorzec pasuje do rozwiązania z dziedziny problemu.. inny nie.

Zdaje sobie sprawę, że ze ścisłym typowaniem PHP byłoby lepszym językiem, ale radzę sobie bez tego.

Daleko szukać: mysql_query - zwraca albo zasób albo false. Podobnych funkcji jest cała masa. Bez okrętek nie da się napisać dobrze kodu i nie zależy to od poziomu programisty, tylko od poziomu języka, z którego on korzysta.

To są naleciałości i tutaj, faktycznie stoi się na przegranej pozycji. Podobnie jest z niekonsekwentnym nazewnictwem w API.

Różnica w tym, że np ja projektując obiekty już tych błędów nie popełniam.

Nie Ty jeden. I z tego właśnie względu powstały różne notacje, między innymi wspomniana notacja węgierska.

I wracamy do tego, że posiadając potężne IDE tej notacji używać nie muszę ( nie wspominając o meaningful names dla zmiennych).

Tylko proszę nie wspominać znów o kodowaniu na komórce, czy na 5 maszynach na raz. Programista narzędzia i zaplecze mieć musi, a nie w... notatniku.

Tzn usprawniajmy sobie prace z narzedziem z ktorego korzystamy w 99% czasu a nie 1%.


A jak mysql_query() ma wskazac ze polaczenie sie nie udalo - i nie ma do dyspozycji wyjatkow. Takich funkcji jest multum. Pewnie ze lepiej kaby byly obiekowe + korzystaly z wyjatkow, ale tak nei jest.



1. Funkcja ktora ustawila $aMyArray na false, nie mogla inaczej wskazac nieprawidlowego wykonania (nie korzysta przeciez z wyjatkow), zwracanie pustej tablicy moglo by byc niewskazane bo moglo by oznaczac np. plik jest pusty (dla file()) zamiast plik nie istnieje, itd.

2. Jesli funkcja moze ci zwrocic false, to Ty, powinienes sprawdzic czy pozniej ta wartosc moze isc do funkcji implode().


Przy scislej kontroli typow mozesz dostac null'a - czyli jest to mozliwe, ale sie rzuca wyjatkiem.

Oczywiście przy założeniu, że jest to PHP. Jak na razie nie spotkałem się jeszcze z sytuacją, w której C# zwraca mi null, a nie rzuca wyjątkiem.

I tak też robię, jednak jest to klepanie dodatkowego kodu, który rak naprawdę nic nie wnosi do aplikacji.

Różne notacje powstały po to, by pomóc programistom w takich sytuacjach. Notacja węgierska najlepiej nadawała się do PHP, ponieważ jasno dawała do zrozumienia (przy poprawnie napisanym kodzie) co w zmiennej piszczy. Jednak z nadejściem epoki IDE podpowiadających składnię, zapis węgierski nie jest już potrzebny, ponieważ IDE pokaże co znajduje się w zmiennej.

Nie zmienia to jednak faktu, że PHP nie jest user frienly i to edytor musi korygować błędy języka.

A ktoś używa czystej implementacji tych funkcji...? Zawsze jest jakiś sterownik albo PDO. No czasem mysqli, ale cóż...

To był tylko przykład. Takich funkcji jest cała masa.

PHP jest językiem typowanym dynamicznie, więc to nie jest wada języka...