Dyskusje na temat artykułu http://wortal.php.pl/phppl/wortal/artykuly/pomysly_porady_sugestie_dobre_nawyki/standardy_kodowania
Czy komentarze phpDoc'a nie zaczynają się od /**?
Jest maly blad w wygladzie komentarzy. Nie tak:
a ja myslalem ze moj kod jest w miare standaryzowany ... czas zaczac pisac wg zalecen tych co potrafia wiecej ... dzieki scanner za spoko art. licze teraz ze pojawi sie jakis art o stosowaniu phpDocumentatora w praktyce.
Mnie zaciekawiła kwestia tabulator vs spacje. Jakis czas temu na forum wywiazala sie bardzo zazarta dyskusja na ten temat. Dobrze, ze ten artykul rozwial wszelkie watpliwosci i zle przyzwyczajenia Na marginesie dodam, ze wiekszosc edytorow ma opcje zamiany tabulatora na spacje.
Artykuł coudwny i jak widzę nie wiele się standard ten różni od moich przyzwyczajeń nabranych w magicznym TurboPascalu na informatyce... Szkoda tylko, że jakoś tak dziwnie tekst artu wystaje poza ramkę z jasnym tłem... (korzystam z Konquerora)
Poprawiłem literówki w opisie "Komentarzy".
Artykul podoba mi sie, choc mam nieco inne przyzwyczajenia co do formatowania mojego kodu - bardziej PEAR'owskie :wink: dodam o siebie jeszcze jedna zecz, mianowicie - gdy mamy duzo linijek kodu w jednym pliku i mnostwo petli, warunkow etc. warto uzywac "komentowania koncowego" np.
[php:1:be79f1196b]<?php
function foo()
{
if ( isset( $strFoobar ) ) {
for ( $i; $i <= $arrFoobar; ++$i ) {
[...]
} //end for
} // end if
return FALSE;
} // end function
?>[/php:1:be79f1196b]
ciekawy art.
teraz nic, tylko sie przyzwyczajac do standartow
pozdro.
Co do struktur kontrolnych: standart PEAR zaleca, by klamra otwierająca blok była w tej samej linii co warunek a nie w oddzielnej. Nie znalazłem też spacji między nawiasem otwierającym a wyrażeniem warunkowym i wyrażeniem a nawiasem zamykającym, np:
[php:1:2773295266]<?php
if (wyrazenie) {
akcja;
}
else {
akcja2;
}
?>[/php:1:2773295266]
W sumie to nie chcę się czepiać, ale sam od dawna używam takiego stylu i jest to bardzo wygodne i czytelne.
Wszystko okej, ale dlaczego nie ma nic wspomniane o łączeniu stringów.
Czy lepiej stosować ' czy może "
Czy robić: echo 'tekst '.$zmienna.' tekst';
czy może: echo "tekst $zmienna tekst";
Dla mnie jest to raczej oczywiste, ale nie koniecznie dla wszystkich.
--
Pozdrawiam,
Dawid
co do standardów - tworząc ten dokument - staraliśmy się wybrać to co najlepsze z obecnie istniejących. Oznacza to, że nie jest to dokładnie to, czego wymaga PEAR.
Dlatego też pojawiają się pewne dodatkowe spacje. np. wewnątrz nawiasów if( ). Podobnie z klamrą - co do kóerej zdecydowaliśmy, ze czytelniej jest, jeśli jest w nowej lini.
Łączenie stringów - jest, w dalszej, jeszcze nie opublikowanej części
w skrócie:
zawsze 'tekst ' . $zmienna . ' tekst';
zawsze echo, nie print.
Postaramy się dołączyć tą 2 cześć do tego arta.
Możecie napisać, czemu tabulatory są zabronione?
hmm.. po prostu uzywa sie jako wciec spacji - zawsze w standardach kodowania bylo tak ze uzywamy spacji. W sumie to nie wiem dlaczego tak sie robi, ale jest to zdecydowanie wygodniejsze. Nawet ze wzgledu na programy do edytowania skryptow..
Odnosnie Tab'ow
Wg mnie tak na zdrowy rozum powodem jest to, ze ludzie (programisci) uzywaja roznych edytorow a z tego co wiem to interpretacja Tab'ulatora (czyli ilosc wstawianych za niego "spacji" - wlasciwie to pustej przestrzeni) zalezy od edytora, czyli w roznych edytorach moze byc rozna, dlatego uzywa sie spacji, ktora wszedzie interpretowana jest jednakowo.
Glowy uciac nie dam, ze taki jest powod ale tak mi sie wydaje
a ja mam ustawione tak, by naciśnięcie tam, wstawaiało 4 spacje. Niby różnica minimalna, ale jednak jest.
Dlaczego? Bo dzięki temu mamy pewność, że wciacie będzie wyglądać identycznie, niezależnie od tego, jak ustawiony jest edytor.
A uwierzcie, kod z wcięciami robionymi zarówno przez spacje jak i tabulatory, w innym edytorze potrafi wyglądać fatalnie.
Rozumiem, że ogólnie przyjęte jest stosowanie nazw fuckcji, zmiennych w języku angielskim ale Polacy nie gęsi ) ... tym bardziej że komentarze są w języku ojczystym .
@shima: jeszcze cos dla Ciebie http://www.jwz.org/doc/tabs-vs-spaces.html
Bardzo fajny artykuł, na pewno wykorzystam niektóre punkty.
Do tej pory starałem się trzymać standardów PEARa, więc nie bardzo rozumiem jednej rzeczy: po co dodawać nadmiarowe spacje na początku i końcu listy argumentów dla funkcji oraz instrukcji for, if, switch, while? Moim skromnym zdaniem nie zwiększa to jakoś specjalnie czytelności kodu, a stanowi dodatkowy wysiłek dla programisty (i tak już przemęczonego ). Na dodatek nie jest zgodne ze stanadardem PEAR. Myślę że spokojnie możnaby obyć się bez tego wymagania.
Spoko artykulik ale brakuje paru rzeczy
Bardzo fajnie byłoby pokazać jak zbudowac domumentacje kodu poprzez phpDocumentator. Np pare screenów. Wówczas będzie potrzebne @package i @subpackage oraz jak powinnien wyglądać poprawnie skomentowany plik i klasa.
W liście wolnych art nie było o phpdoc wiec chyba można w tym go troche lepiej opisac
ja niewiem po co przy nazwach zmiennych pisac jej typ ?
Po to, żeby się nie pogubić i uczynić kod czytelniejszym. Lepij chyba jest, jak widac jaki typ danych w srodku siedzi, co nie?
bajer. phpdoc jest bardzo fajnym standardem komentowania kodu i warto go w pełni wykorzystac.
ja troszeczke inaczej definiuje zmienne. szkoda mi tylu znakow (trzy) marnowac.
i tak:
[php:1:496cc18713]<?php
$intVar -> $iVar
$strVar -> $sVar
$arrVar -> $aVar
$objSmarty -> $oSmarty
$blnVar -> $bVar
$resFile -> $rFile
$fltVar -> $fVar
?>[/php:1:496cc18713]
podobnie z petlami
nie stosuje
if ( expr )
{
...
{
tylko
if( expr ){
...
}
tego sie juz nauczylem z symfonii c++
"Jako wcięć powinno się używać 4 (czterech) spacji"
ja uzywam 2
scanner napisal:
[php:1:496cc18713]
"<?php
MyFunction( );
$objDBDriver->Query()
?>
"
[/php:1:496cc18713]
ja z "thinking in java" nauczylem sie nawyku nazywania wszystkich funkcji i metod od malej litery a nazwy klasy od duzej
np.
[php:1:496cc18713]
"<?php
getSomething( );
$oVar->query();
class ClassName{}
?>
"
[/php:1:496cc18713]
to tyle jesli chodzi o mnie...
tak przygladając się różnym standardom, również doszedłem do wniosku, że przydałoby się przeprowadzić parę modyfikacj. Może nie tak dalko posuniętych, ale jednak.
1. Klasy - zaczynamy od dużej litery, funkcje od małej
2. spacje - tylko w nawiasach - nie przed nimi, czyli powinno być
[php:1:0258201679]<?php
function test( $Param )
{
if( $Cos )
{
}
}
?>[/php:1:0258201679]
3. nazwy obiektów. Wzorem innych języków - proponowałbym pominąć przedrostek obj, i nazywać je z wielką literą na początku, czyli
[php:1:0258201679]<?php
$Test = new Test;
$Test->Input = new Input;
?>[/php:1:0258201679]
ad2. fakt nie zauwazylem ... ja nie praktyktuje czegos takiego jak if ( cos ) ale if( cos )
ad3. mnie sie podoba bardziej $oObject a nie $Object
Nie mam może duzego doswiadczenia ale dla mnie o wiele bardziej czytelne jest takie "spacjowanie" funkcji:
[php:1:24f3721992]<?php
date (Y-M-D);
?>[/php:1:24f3721992]
niż:
[php:1:24f3721992]<?php
date ( Y-M-D );
?>[/php:1:24f3721992]
Natomiast przy tak krótkich argumentach w funkcjach jak "date()" wogóle pomijam spacje dla czytelnosci kodu.
Może to wynika z tego że używam edytora który dobrze "koloruje" kod php.
A poza tą jedną uwagą uważam, że ten Art jest świetny, klaruje wiele rzeczy dotyczących czytelności.
?>[/php]
Ja może powtórzę jeszcze raz, bo chyba nie wszyscy zrozumieli.
Komentowany materiał nie jest moim widzimisie, tylko dokumentem, który powstał w trakcie dyskusje developerów php.pl tuż po uruchomieniu prac nad projektem Thot.
Zatem nie chodzi o to, kto jak woli, ale jak My, developerzy chcemy mieć ułożony kod. Przy okazji, pragniemy ustandaryzować niektóre działania, bo czytelność kodów prezentowanych na forum woła o pomstę do nieba.
Każdy ma jakies swoje przyzwyczajenia. Ale jeśłi ich nie ma, jełsi zaczyna, to niech nabiera tych "ustandaryzowanych".
Zgadzam się z tym, że jest to standard który jest przez was wymagany. Rozumiem to i akceptuje, wysyłając wszelkie pracę do was będzio on przeze mnie stosowany. Co więcej cieszę się że istniej, przynajmniej tutaj standard zapisu kodu.
Ale nadal będę twierdził że za duzo spacji wcale nie sprawia że kod jest przejżysty. Hmm... Może to przyzwyczajenia z informatyki?
Panowie, co ma spacja do czytelnosci kodu ? No tak jesli ktos nie uzywa entera to tak, przyda sie. ale spacjowanie wszystkiego co popadnie to jest troche nadgorliwosc, bo jak widze ser szwajcarski to glodny sie robi i nie czytam juz dalej.
Wazniejsze jest zeby kozystac z tabulacji przy wszelkiego rodzaju petlach, warunkach i innych miejscach gdzie przyda sie odruznienie kodu od siebie.
[php:1:92376daa8d]<?php
//tak ?
function funkcyjka() {
//...
}
//czy tak ?
function funkcyjka2 ( )
{
//...
}
$a=$b+$c;
// czy
$a = $b + $c;
mysql_query ( " SELECT * FROM t1 WHERE col1 = ' " . $cos . " ' " );
//czy
mysql_query("SELECT * FROM t1 WHERE col1 = '".$cos."'");
?>
to jest obojetne, czesc sie lepiej, czesc gorzej czyta, ale nie robmy czegos takiego:
<?php
funkcja funkcyjka() { /*...*/ } $a=$b+$c; mysql_query ("SELECT * FROM t1 WHERE col1 = '".$cos."'"); echo "ala ma kota, a kot ma ospe"; str_replace('c', 'a', $nic); echo $nic;
?>[/php:1:92376daa8d]
a co do komentarzy to juz inna sprawa ze to przy publikacjach otwartych jest bardzo wazna rzecza zeby poprawnie udokumentowac/skomentowac kod. Nikt nie jest nieobylny i popelnia bledy, a przy ladnie napisanym kodzie duzo ladniej jest poprawic jakis blad, nie tylko obcej osobie, ale samemu.
dla osob ktore maja problemy z ladnym pisaniem polecam bardzo ciekawa stronka i zarazem skrypcik jahttp://www.bierkandt.org/beautify/ do pozadkowania kodu. Sam czasami kozystam w niektorych sytuacjach.
Scanner napisal:
"Każdy ma jakies swoje przyzwyczajenia. Ale jeśłi ich nie ma, jełsi zaczyna, to niech nabiera tych "ustandaryzowanych"."
Tak tylko niektorzy tez czytali jakies inne ksiazki nie tylko do php np. do Javy gdzie nie raz podawano za dobry przyklad pisania funkcji z malych a klas z duzych ... i to nie jest moje widzimisie bo napisalem od razu, ze co do nazewnictwa duzo bralem na wzor z Thinking in Java
Jesli sie przypatrzec temu co napisaliscie apropo PHPdoc czyli np:
@author
@version
to chce zauwazyc, ze takie cos juz od dawien obowiazuje np. w JAVA i nie tylko w PHPdoc (ktorego tworcy zapewne skorzystali z pomyslu i dobrze).
Wiec skoro sa pewne teoretycznie "standardy" pisania w JAVA to czemu w php tego tez nie zastosowac? No chyba, ze chcecie sie na tyle wyrozniac ...
Oczywiscie nie naciskam bo kazdy pisze jak chce ale zauwazcie iz to WY w bezposredni sposob tworzycie nowe trendy, style, standardy dla duzej grupy ludzi piszacych i zaczynajacych i dlatego pisze swoje widzimisie bo idealny nikt nie jest i uwagi moze przyjac a moze i sa sluszne? Bo lepiej nagiac czasem pewne zasady dla ogolnego dobra a to co prezentujecie dla mnie jest sprzeczne np. z tym co sie pisze o pisaniu w JAVIE a szkoda ...
Podobnie ma sie sprawa zmiennych. Super wyjscie jest z tymi przedrostkami ... ale sami wiecie, ze dlugosc zmiennych wplywa na czas realizacji skryptu. Wiec z jednej strony optymalizacja a z drugiej czytelnosc kodu ...
@sztos to jest tylko i wylacznie Twoje subiektywne odczucie, masz po prostu zle przyzwyczajenia z informatyki - tak to jest jak niedouczeni ucza.
Naszym celem było przygotowanie standaru zaróno przejżystego, jak również przyjaznego piszącym. Wiązało się to z pójściem na ustępstwa zarówno w jedną jak i drugą strone.
Jest to jednak standard cały czas rozwijany, i po ostatniej rozmowie developerów ustaliliśmy, że zostanie wprowadzonych parę zmian.
Klika z nich wymieniłem w poście odrobinę wyżej, dzięki czemu mamy nadzieję, że stanie się on jeszcze łątwiejszy do opanowania (a chcę również zauwazyć, że w dużej części wprowadzone zmiany są włąśnie ukłonem w kierunku Javy, więc i Ty, treewood, powinieneś być zadowolony )
deyv napisal
"zostanie wprowadzonych parę zmian."
i ciesze sie bardzo ... bo mialem naprawde mieszane uczucia apropo tych standardow.
wiekszosc poza tymi funkcjami i klasami jest akceptowalna i cieszy mnie to, ze czytajac ten artykul wiedzialem, ze praktykuje to juz od dawna u siebie ...
"Oczywiście - nikt nikogo nie będzie zmuszał do niczego, ale ... my będziemy raczej pisać tak, jak podaliśmy"
masz racje (apropo nazewnictwa zmiennych) to juz traktuje jako wlasne widzimisie i TYLKO propozycje
" idąc tym tropem moglibyśmy dojść do wniosku, ze tabulatory i spacje też tak działają, a komentarze w kodzie do już czyste marnotrastwo."
nie obracaj kota ogonem i nie uwypuklaj sprawy ... bo wiadome jest, ze $sCos przy pewnych zalozeniach jest rownie czytelne jak $strCos ... a braki komentarzy, tabulacji to sprawy nadrzedne i tego chyba NIKT sie nie czepia.
nawiasem mowiac ja jak udostepniam skrypt to albo:
- zakodowany w np. turcku
- przekonwertowany przez program np. phpcleaner, ktory usuwa wszystkie komentarze i skraca nazwy zmiennych (optymalizacja)
Jak najbardziej zgadzam się z artykułem lecz stanowczo nie zgadzam sie ze stwierdzeniem:
Ten temat był poruszany odrobinę wyżej.
Przyczyny wprowadzenia spacji zamiast tabulatorów:
1. zawsze wyświetlane są tak samo (czego nie można powiedzieć o tabulatorach) a przegladanie dokumentów, gdzie częśc wciąć jest robiona przez spacje, a pozostała przez tabulatory potrafi być straszna.
2. większość edytorów posiada funkcję zastępowania tabulatora odowiednią ilością spacji.
Natomiast coraz przychylniej patrzę na propozycje wprowadzenia notacji węgierskiej, tj. oznaczania typów danych 1 a nie 3 literami.
Będziemy musieli to przedyskutować.
To ja dorzucę też swoje 2 grosze :wink: :
1. Notacja węgierska
php to chyba jedyny język, w którym jestem za, z uwagi na ogólną "beztypiczność". Zdecydowanie popieram treewooda, odnośnie stosowania jednego znaku zamiast trzech. Nie tylko jest to krótsze, ale i bardziej przejrzyste. Bo bVar występuje nawet w MSDNie, a blnVar byłoby naszym autorskim wynalazkiem.
Wyjątkiem są fragmenty typu
[php:1:ed3c86cf7b]<?php
for ($i=0; $i<10; $i++) {
//...
}
?>[/php:1:ed3c86cf7b]
Nie ma sensu zamieniać $i na $iI, $intI, $iIndex, $iTemp czy inne potworki.
2. Klasy, obiekty, metody
Klasy - obowiązkowo z wielkiej litery, CamelCaps. Tu chyba nie ma żadnych wątpliwości.
Obiekty - wzorem innych języków proponowałbym jednak pisać z małej litery. Jak już stosujemy notację węgierską, to o na początku powinno być obowiązkowe.
Metody- zdecydowanie z małej. Pisanie z wielkiej nie ma żadnego uzasadnienia, za to bardziej upodabnia się do nazwy klasy.
3. Tabulatory
Nie ma rady - ja też wolę tabulatory, ale muszą być 4 spacje i koniec.
Tak swoją drogą - nie ma narzędzia które potrafi zaaplikować to wszystko co wymyślimy? Niedoścignionym wzorcem jest JBuilder, który potrafił wszystko przeformatować.
Kiedy, po długim czasie pisania "jak leci" zdecydowałem się na stosowanie (w C++) "Original Berkeley Style" czułem się nieco zdezorientowany składnią, ale teraz, po przyzwyczajeniu się, uważam, że nie jest istotne, czy będą 3 spacje, 1 czy 7 , czy nie jest istotne, jakiej notacji używam w nazwach, ważne, że jest konsystentna, czytelna i niezmienna.
@cagrET: Co do przejrzystosci kodu nie sposób się nie zgodzic masz zupełną rację.
@shima: Tu też się zgadzam: - czytelna i niezmienna<-(to najważniejsze)
Hmm, przyznaję się bez bicia że to co preferuje cagrET to jakby żywcem wyjęte z mojego stylu . Ja robię dokładnie tak samo. Tutaj jednak zaczynamy kwestię enterów i spacjowania. Polecam http://java.sun.com/docs/codeconv/. Sun pod tym względem jest bardzo dokładny i dobrze mi się tak pisze.
Więc, co przemyśleniu, dochodzę do wniosku że o przed nazwą obiektu można sobie podarować i pisać po prostu z małej. Przedrostki do innych typów zmiennych jednak mi się podobają, chociaż do tej pory nigdy nie używałem.
wassago napisal:
"thanks = thx = t (!?)"
no nie ... walnales przyklad po prostu idealny ... hehehehe
hawk napisal:
"Więc, co przemyśleniu, dochodzę do wniosku że o przed nazwą obiektu można sobie podarować i pisać po prostu z małej. Przedrostki do innych typów zmiennych jednak mi się podobają, chociaż do tej pory nigdy nie używałem."
No racja ... kazdy pisze jak chce ... lepsze to niz pisanie $objCosTam. juz blizszy bylbym $CosTam. Jednak ja nie lubie wyjatkow. Skoro wszystkie zmienne traktuje wg schematu to nie robie wyjatku, ze TYLKO objekty sa inaczej nazywane. Ale to juz dla mnie drobnostka z porownaniem z tym $objCosTam.
Chciałem zapytać jak najłatwiej osiągnąć te wcześniej wspomniane "4 spacje". No bo chyba nie przez 4 uderzenia klawisza spacji ? Da się to jakoś podbindować pod Tab ?
To zależy od edytora w jakim pracujesz. Większość w preferencjach ma coś takiego jak:
"Używaj prawdziwej tabulacji"
I jest też możliwość określenia długości na jaką ma być wyswietlany tab - i w zależności od tego czy zaznaczysz to pole, albo w miejsce Taba wrzucane są X spacje, albo wcięcie robione tabem wygląda na tak długie
btw: Osobiście odrazam używania spacji do robienia wcięć w kodzie - co najwyżej do wyrównywania jeżeli ktoś chce.
a czemu odradzasz? o ile wiem to spacje wszedzie wyglądaja tak samo a tab co edytor to inaczej... no i np w yaml'u tylko spacje moga sluzyc za wciecia
Dlatego, że dla mnie akurat idealną długością wcięcia jest odległość czterech spacji. Dla znajomego jest to odległość dwóch.
Innymi słowy użycie tabulacji daje możliwość nieinwazyjnego dostosowania wyglądu kodu do własnych preferencji.
Pozwolę sobie odgrzać tego zielonkawego już kotleta.
Crozin w złote ramki twoje słowa.
- 5 Lat jak na standardy kodowania to jest już trochę czasu. Może można by było zaktualizować ten artykuł. Chociażby ten 3literowy prefix udający notację węgierską to mnie trochę zdziwił.
Wg. mnie w tym artykule powinno być zaznaczone że jeżeli jeżeli TABulator jest określeniem kilku spacji (np.4,5) to należy z niego skorzystać. A jeżeli tworzy taką przestrzeń ( ), w której kursor przeskakuje, to powinno się zakazać.
Dobre edytory textowe posiadają tą funkcje że z automatu zamieniają TAB na spacje, tylko kwestia jest... na ile tych spacji.
Mnie nurtuje takie pytanie:
Dlaczego to ma być lepsze od
if ( $foo == true ) { foo(); }
if ( $foo == true ) foo();
No to powinien być jeszcze jeden taki podpunkt.
Aby grupa programistów starała się aby pisząc wspólnie jakiś produkt, korzystać z tych samych standardów.
ja mam bolączkę z swoim kompanem...
bo ma świetne pomysły przy pisaniu skryptów, ale ma zupełnie odmienny styl... ignoruje odstępy i potem ja musze to wszystko poprawiać, aby kod był przejrzysty i usuwać jakieś stare szkoły np.
http://www.php.net/echo ("mój text"); //albo $foo = ("jakis text"); //czy http://www.php.net/echo "<font color=\"white\">Mój text</font>";
Trochę od siebie.
1. Wcięcia - jak dla mnie wcinanie kodu tuż po <?php jest trochę bez sensu, toż to tylko jedna linijka, kod nie stanie się bardziej nieczytelny, a przynajmniej szerokość kodu się zmniejszy, nie będzie zawijany.
2. Nawiasy klamrowe - Wg. mnie czytelniejsze jest stosowanie:
<?php if($expression) { http://www.php.net/echo 'True; } ?>
<?php if($expression) { http://www.php.net/echo 'True; } ?>
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
funkcja(funkcja2(argument2_1,funkcja3()),parametr2,funkcja3())
funkcja( funkcja2( argument2_1, funkcja3() ), parametr2, funkcja3() )
if( warunek ) { if( warunek ) { instrukcje; } else { instrukcje; } } elseif { instrukcje; } else { instrukcje; }
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
if( warunek ) { if( warunek ) { instrukcje; } else { instrukcje; } } elseif { instrukcje; } else { instrukcje; }
http://www.php.net/echo ( warunek) ? instrukcja : instrukcja;
if( warunek) { http://www.php.net/echo instrukcja; } else { http://www.php.net/echo instrukcja; }
if( warunek ) http://www.php.net/echo instrukcja; else http://www.php.net/echo instrukcja;
if( warunek ) http://www.php.net/echo instrukcja;
Witam,
Tutaj też jest trochę o standardach kodowania
http://97dd3f4dc892082dd4198bc1d2d576a8.blogspot.com/
Z jedną rzeczą w artykule natomiast nie bardzo się zgadzam a mianowicie odnośnie nazewnictwa plików. Z mojej strony dwa ale:
1: Jeśli chodzi o nazywanie plików małymi literami:
- Klasy PEAR (pliki) nazywane są dużymi literami;
- Zend FM stosuje również nazewnictwo klas dużymi literami
Wydaje mi się więc, żę nazwanie plików z kodem klas z dużej litery jest dobrym rozwiązaniem (nie jest złym)
2: "Nazwy plików piszemy małymi literami, zaznaczając typ pliku:
Tu też się przyczepię. Wydaje mi się, że jeśli rozplanujemy aplikację trzymając konkretne jej części w wydzielonych dla nich folderach, dopisywanie do nazwy pliku jej typu nie ma większego sensu.
Jeśli mamy np folder classes lub libs to nie widzę potrzeby dodawania w nazwie "class" lub "function".
Poza tym ciekawy artykuł, wiem, że dośc stary niemniej dobrze, że ktoś napisałem a tym.
Pozdrawiam.
Wydaje mi się że to już nie ma co się czepiać, tylko trzeba ten temat zarchiwizować lub dodać mu jakiś tag typu [nieaktualne].
Standard kodowania jest jeden. Netbens. Prawy przycisk myszy i fromat. Wszystko piszemy z małej litery i nadajemy sensowne nazwy. To samo tyczy się katalogów i nazw plików czy komentarzy. Reszta to prehistoria i utrudnianie sobie życia na siłę.
A przeczytałeś ten wątek? Ja akurat NetBeans/Eclipse/czegokolwiek w javie nie znoszę i co?
Ja nie uwazam zeby watek archiwizowac wg mnie problem jest dosc istotny a nowosci (i ich sensowna argumentacja moze byc ciekawa).
Co do tego co zostalo opisane przez scannera w wiekszosci przypadkow po pewnym stazu mozna samemu do tego dojsc. Ja w 90% jakby intuicyjnie (czyli tak jak dla mnie wydawalo sie najczytelniej) stosowalem wlasnie takie rozmieszczenia kodu jak opisane w artykule.
Choc to co mnie najbardziej gubi w cudzych kodach to zapis w postaci:
if(...) { ... }
if(...) { ... }
if( warunek ){ }
Phpion to nie z javyscript a z c++. I nie wiem co złego jest w łączeniu nazw przez użycie dużych liter zamiast _. Mi tak jakoś jest o wiele bardziej wygodniej, i jest to ładniejsze dla oka. Szczerze to masz też racje bo nie brałem pod uwagi under_score
Nie mówię skąd się wywodzi CamelCase - odniesienie do JavaScript miało na celu to, że w tym języku jest stosowany CamelCase, natomiast w PHP under_score. Według mnie decydując się na kodowanie w danym języku wypadałoby nie mieszać konwencji i trzymać się tej obowiązującej. Dla porównania:
PHP: http://php.net/quickref.php
JS: http://www.tutorialspoint.com/javascript/javascript_builtin_functions.htm
A masz na myśli nazwy zwykłych funkcji czy też metod w obiektach ?
@phpion: Nie podawaj tutaj PHP jako przykładu języka, w którym przyjęła się notacja under_score (ona się tak na serio nazywa?), bo ona się nie przyjęła. Albo inaczej - już od dawna nie jest wiodącą. Niestety bardzo często powtarzane "PHP ma burdel w API" odnosi się również do braku jakichkolwiek konwencji dot. nazewnictwa.
Odkurzam. W zalinkowanym artykule w temacie lista znaczników phpDoc jest już niekompletna.
StudlyCaps znam jako PascalCase. snake_case czesciej zwane jest LowerCase albo underscores. Natomiast korzystam w swoich projektach z notacji węgierskiej w przypadku zmiennych i PascalCase w przypadku funkcji, klas i przestrzeni.
Wiem że troche odgrzebuje, ale wisi od lat jako ostatni wiec pewnie od czasu do czasu ktoś tu zajrzy mimochodem, dlatego dla potomnych dziś jedyny standard to będzie ten https://www.php-fig.org/per/coding-style/
PSR-12. Każdy inny standard użyty w kodzie, to "widzi mi się" programisty / firmy i nie powinien istnieć
@Salvation tak do tej pory było to PSR-12 ale obecnie najnowszy i już ostatni standard który będzie nadążał za zmianami w core, po prostu się zmieniał to PER
Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)