Przejrzystość kodu Opcje

[caladan]

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ć.

Powód edycji: [erix] przeniosłem

[LBO]

To jest tzw notacja węgierska.

[Vielta]

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.

[LBO]

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.

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ę.

$_nazwa osobiście używam przy zmiennych statycznych, nie wiem czy ma to jakieś inne użycie.

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

[Vielta]

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

Ten post edytował Vielta 26.06.2009, 16:01:45

[erix]

Więc nie zawsze z dostępem do eclipse, z którego to korzystam.

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

[dr_bonzo]

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"

[Vielta]

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

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

[osl]

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

[batman]

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.

[erix]

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

Czytaj, co piszę.

[dr_bonzo]

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.

...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

[Vielta]

@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

[starach]

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.

[Crozin]

@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..

[batman]

...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.

[bim2]

rFtpLink czasami jest resourc'em, a czasami booleanem tak naprawdę, ale..

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

[Crozin]

@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 

[LBO]

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)

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
/**
 * @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.

[batman]

~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:

Warning: implode() [function.implode]: Invalid arguments passed in

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).