Standardy kodowania [scanner] Opcje

[scanner]

Dyskusje na temat artykułu http://wortal.php.pl/phppl/wortal/artykuly...dardy_kodowania

[thek]

Osobiście uważam, że standardy są od tego, by się do nich stosować. Sam "wychowywałem się" na C++ i na studiach wiele z nich mi wtłoczono. Czy to tyczących składni, czy też pisania dokumentacji projektowej itp. Wiele z nich po czasie stało się podświadomych i trudniej mi się połapać w "radosnej twórczości". Co do spacji i tabulatorów, to tak naprawdę wychodzi ten drobiazg przy komentowaniu kodu zazwyczaj, bo tam głównie dba się o to by pewne informacje były w określonym miejscu i tam tabulacja zawodzi w głównej mierze.
Spacje pomiędzy nawiasami przy liście parametrów funkcji to już standard dla mnie bo czytanie jednolitych bloków w momencie gdy do funkcji jako parametr przesyłam wartości zwracane przez inną kilkukrotnie czasem zagłębioną (wiem... tracę przy tym na wydajności, ale czasem już tak jest) to potworki w stylu

[PHP] pobierz, plaintext 
funkcja(funkcja2(argument2_1,funkcja3()),parametr2,funkcja3())
[PHP] pobierz, plaintext 

są mniej czytelne niż

[PHP] pobierz, plaintext 
funkcja( funkcja2( argument2_1, funkcja3() ), parametr2, funkcja3() )
[PHP] pobierz, plaintext 

Nawiasy klamrowe po funkcji przejąłem wrzucać zaraz po liście argumentów, bez przechodzenia do nowej linii, co dla mnie wygodniejsze zresztą, bo późniejsze zagłębianie sprawia, że taki kod jest nieco czytelniejszy, gdyż widać więcej kodu na tym samym poziomie zagnieżdżenia.

[PHP] pobierz, plaintext 
if( warunek ) {
    if( warunek ) {
        instrukcje;
    } else {
        instrukcje;
    }
} elseif {
    instrukcje;
} else {
    instrukcje;
}
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
 if( warunek )
{
     if( warunek )
    {
         instrukcje;
     }
    else
    {
         instrukcje;
     }
 }
elseif
{
     instrukcje;
 }
else
{
     instrukcje;
 }
[PHP] pobierz, plaintext 

A teraz wyobrazić sobie trzeba, że tych instrukcji warunkowych, pętli itp., jest w kodzie znacznie więcej. Łatwiej ogarnąć całość przy pierwszej szkole zapisu, gdyż jest on zwięźlejszy. Ten kto stosuje skrótowe zapisy instrukcji warunkowych rozumie

[PHP] pobierz, plaintext 
echo ( warunek) ? instrukcja : instrukcja;
[PHP] pobierz, plaintext 

, ale gdy ktoś zobaczy coś takiego pierwszy raz zapewne nie przyjdzie mu do głowy, ze jest to odpowiednik znanego mu

[PHP] pobierz, plaintext 
if( warunek) {
    echo instrukcja;
} else {
    echo instrukcja;
}
[PHP] pobierz, plaintext 

Zresztą sam jestem zwolennikiem stosowania skrótów tam gdzie to możliwe i nieraz stosuję formę

[PHP] pobierz, plaintext 
if( warunek )
    echo instrukcja;
else
    echo instrukcja;
[PHP] pobierz, plaintext 

a gdy nie ma else, po prostu

[PHP] pobierz, plaintext 
if( warunek ) echo instrukcja;
[PHP] pobierz, plaintext 

które to formy są dopuszczalne i w przypadku jednej instrukcji skracają kod, bez utraty jego czytelności. W końcu po coś te formy skrótowe zostały wymyślone. Albo by zmniejszyć kod w określonych przypadkach, albo dla zachowania zgodności składniowej z innymi językami.

Z C++ wyniosłem też pisanie obiektów z małej oraz klas z dużej. Dopiero PHP wniósł dodatki związane z opisem typu w zmiennej. Jako że akurat pod tym względem C++ wymusza jawne podawanie tego podczas tworzenia kodu, a niemal każda konwersja musi być jawna, nie musiałem tego wcześniej stosować. Do tej pory mam odruchy w PHP by robić rzutowania, nawet dla typów wbudowanych Inna sprawa, że PHP mi na to także pozwala. Dlatego, mimo różnic w pewnych rzeczach, dobrze mi się pracuje z wersją 5.

Jak dla mnie pominięto w artykule choćby:
a) stosowanie spacji podczas wyrażeń arytmetycznych. Wiele osób całkowicie to ignoruje, co prowadzi do jego zlewania się w jeden wielki ciąg, który fatalnie się czyta,
stosowanie podkreślenia na początku zmiennej by oznaczyć ją jako tymczasową (w obrębie funkcji wewnętrznej, pętli czy tego typu sytuacjach), co pozwala na szybsze połapanie się w tym, które są ważne. Wiem, że kłóci się to trochę z $_POST, $_GET i innymi ale te akurat zawsze są z dużych i znane każdemu więc się nie pomyli nikt raczej
c) nie stosowanie podwójnego podkreślenia, bo te w wielu językach są zarezerwowane dla słów specjalnyc, co może spowodować pomyłki przy odbiorze kodu,
d) jednolitość pisowni zmiennych bool, bo stosuje się warianty: TRUE, true, True.

Oczywiście można by dodać jeszcze kilka innych