Standardy kodowania [scanner] Opcje

[scanner]

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

[Wankster]

Czy komentarze phpDoc'a nie zaczynają się od /**?

[Seth]

Jest maly blad w wygladzie komentarzy. Nie tak:

Kod

/**

*

* ...

*/

a tak:

Kod

/**

*

* ...

*/

(IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[PMadej]

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.

[Dawid Pytel]

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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) Na marginesie dodam, ze wiekszosc edytorow ma opcje zamiany tabulatora na spacje.

[Bakus]

Artykuł coudwny i jak widzę nie wiele się standard ten różni od moich przyzwyczajeń nabranych w magicznym TurboPascalu na informatyce... (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) Szkoda tylko, że jakoś tak dziwnie tekst artu wystaje poza ramkę z jasnym tłem... (korzystam z Konquerora)

[scanner]

Poprawiłem literówki w opisie "Komentarzy".

[wassago]

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]

[HaRy]

ciekawy art.
teraz nic, tylko sie przyzwyczajac do standartow (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

pozdro.

[kszychu]

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.

[DavidPL]

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

[DeyV]

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 (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)
w skrócie:
zawsze 'tekst ' . $zmienna . ' tekst';
zawsze echo, nie print.

Postaramy się dołączyć tą 2 cześć do tego arta.

[shima]

Możecie napisać, czemu tabulatory są zabronione?

[wassago]

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

[shima]

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

No tak, ale tabulatory są po to, zeby stuknąć raz, a nie cztery. Ja ustawiam szerokość tabulatora na 4 spacje i mam ten sam efekt.

[lukaswoj]

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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[shima]

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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Tak jest, ale każdy sensowny edytor pozwala ustawić ilość spacji. Byle była całkowita (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[DeyV]

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.

[shima]

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.

OK, przyznaję rację. Ustawiłem w swoim edytorze opcję zamiany tabulatorów na spacje, dla mnie żadna różnica, ale faktycznie inni mogą mieć łatwiejszą prace z moim kodem. A co do fatalnie sformatowanego kodu, to zdarzało mi się niejednokrotnie widzieć różne przykłady.

[Bonhart]

Rozumiem, że ogólnie przyjęte jest stosowanie nazw fuckcji, zmiennych w języku angielskim ale Polacy nie gęsi (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) ) ... tym bardziej że komentarze są w języku ojczystym .

[scanner]

Rozumiem, że ogólnie przyjęte jest stosowanie nazw fuckcji, zmiennych w języku angielskim ale Polacy nie gęsi (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) ) ... tym bardziej że komentarze są w języku ojczystym .

O ile przetłumaczenie komentarzy dla potrzeb publikacji skryptu na serwisach obcojezycznych to nie jest większy problem o tylko zamiana w skrypcie[php:1:b819e79dc8]<?php
MojaFunkcja()
?>[/php:1:b819e79dc8]na [php:1:b819e79dc8]<?php
MyFunction()
?>[/php:1:b819e79dc8]już takie problemy nastręcza szczególnie w przypadku bardziej rozbudowanych aplikacji.
Pozatym anglikowi czy francuzowie wiecej powie[php:1:b819e79dc8]<?php
$objDBDriver->Query()
?>[/php:1:b819e79dc8]niż[php:1:b819e79dc8]<?php
$objSterownikBazy->Zapytaj()
?>[/php:1:b819e79dc8]

[Bonhart]

O ile przetłumaczenie komentarzy dla potrzeb publikacji skryptu na serwisach obcojezycznych to nie jest większy problem o tylko zamiana w skrypcie [...]

Chodzi mi o to że większość programistów polskich zna chociaż podstawowo angielski, po prostu są zmuszenie do tego.
Tak się zastanwiam dlaczego nie zmusić reszty świata do uczenia się polskiego (IMG:http://forum.php.pl/style_emoticons/default/laugh.gif)
Ja równięż używam nazw angielskich, bo czasem trudno znaleść odpowiedniki np query = kwerenda
W sumie moj post był pewnego rodzaju prowokacją (IMG:http://forum.php.pl/style_emoticons/default/laugh.gif)

[wassago]

@shima: jeszcze cos dla Ciebie http://www.jwz.org/doc/tabs-vs-spaces.html

[shima]

@shima: jeszcze cos dla Ciebiehttp://www.jwz.org/doc/tabs-vs-spaces.html

Coż, jako że w mojej grupie wszyscy używamy tego samego narzędzia, więc nie zdawałem sobie sprawy z powagi sytuacji, ale ten artykuł wyjaśnił mi kilka kwestii. Część merytoryczna warta jest polecenia każdemu, kto pracuje w zespole. THX wassago

[szafranek.net]

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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) ). Na dodatek nie jest zgodne ze stanadardem PEAR. Myślę że spokojnie możnaby obyć się bez tego wymagania.

[Bora]

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

[invx]

ja niewiem po co przy nazwach zmiennych pisac jej typ ?

[scanner]

Po to, żeby się nie pogubić i uczynić kod czytelniejszym. Lepij chyba jest, jak widac jaki typ danych w srodku siedzi, co nie?

[wassago]

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

spoko, o tym powstanie calkowicie oddzielny art (by me) :wink:
zaczne go pisac po maturach (ok. 20.05.2004)

EDIT:

nie phpDoc (przestarzaly, od 3 lat brak aktualizacji), tylko phpDocumentator :wink:

[Bora]

bajer. phpdoc jest bardzo fajnym standardem komentowania kodu i warto go w pełni wykorzystac.

[treewood]

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

[DeyV]

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]

[treewood]

ad2. fakt nie zauwazylem ... ja nie praktyktuje czegos takiego jak if ( cos ) ale if( cos )

ad3. mnie sie podoba bardziej $oObject a nie $Object

[sztosz]

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]

[scanner]

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

[wassago]

[...]Przy okazji, pragniemy ustandaryzować niektóre działania, bo czytelność kodów prezentowanych na forum woła o pomstę do nieba. [...]

aaamen! :wink:

[sztosz]

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?

[Sh4dow]

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 (IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif) ?
function funkcyjka() {
//...
}
//czy tak ?
function funkcyjka2 ( )
{
//...
}

$a=$b+$c;
// czy (IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif)
$a = $b + $c;

mysql_query ( " SELECT * FROM t1 WHERE col1 = ' " . $cos . " ' " );
//czy (IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif)
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 jaBeautify php do pozadkowania kodu. Sam czasami kozystam w niektorych sytuacjach.

[treewood]

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

[wassago]

@sztos to jest tylko i wylacznie Twoje subiektywne odczucie, masz po prostu zle przyzwyczajenia z informatyki - tak to jest jak niedouczeni ucza.

Panowie, co ma spacja do czytelnosci kodu ? [..]

ma, i to wiele. Sh4dow - po co ta rozmowa, no masz inne przyzwyczajenie, osobiscie nie wyobrazam sobie pisania skryptow innym sposobem niz "standardami thot'a". Nawet 4 linijkowy kod, ktory zaraz wykasuje - pisze wg standardow.

[DeyV]

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 (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) )

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

ee - tu już przesadziłeś. 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.
Oczywiście - nikt nikogo nie będzie zmuszał do niczego, ale ... my będziemy raczej pisać tak, jak podaliśmy (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[treewood]

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)

[Przemo`]

Jak najbardziej zgadzam się z artykułem lecz stanowczo nie zgadzam sie ze stwierdzeniem:

Jako wcięć powinno się używać 4 (czterech) spacji. Niedozwolone jest używanie znaku tabulacji

Nie wiem kto to wymyslił, ale wg. mnie jest to całkowity bezsens, mimo tej zaciekłej wojny Po 1 trzeba "celować"/liczyc spacje, aby zachować równowagę. Po 2 poruszając sie po liniach w poziomie trzeba stracic więcej czasu na przebycie drogi (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) . Po 3 dokument zawierający 400 spacji jest większy niż dokument zawierający 100 tabulatorów. Po 4 czasami zachodzi potrzeba włączenia w edytorze oznaczania spacji, np. kropkami, wówczas w dokumencie gdzie są spacje zamiast tabulatorów kompletnie nic nie widać.
Troche też nie zgadzam się ze spacjami wszedzie, po nawiasach okrąłych. Ja ich uzywam tylko w if ( $zmienna ) natomiast w innych funkcjach je omijam i zostawiam tylko po przecinkach za zmiennymi.
Generalnie używam lekko zmodyfikowanych standardów phpBB uważam, że są dobre.
Bardzo dobrze, że powstał taki polski dokument, jednak każde zastosowanie powinno mieć wyjaśnienie, bo inaczej ludzie to zignoruja i dalej będą pisac po swojemu.

[DeyV]

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

[wassago]

Natomiast coraz przychylniej patrzę na propozycje wprowadzenia notacji węgierskiej, tj. oznaczania typów danych 1 a nie 3 literami.

Nie wydaje mi sie aby taki sposob notacji byl lepszy od 3 znakowych prefiksow. Gdyby pomyslec nad tym to uzytkownik moze przez taka notacje zaostac wprowadzony w blad. Poza tym jak bardzo moze wplynac na szybkosc kody prefix 3 a 1 znakowy, wg mnie bardzo niewiele. Pamietajcie, czytelnosci przede wszytskim.
thanks = thx = t (!?)

[hawk]

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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) 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ć.

[DeyV]

nie ma narzędzia które potrafi zaaplikować to wszystko co wymyślimy?

Heh - Zend Studio większośc z tych rzeczy potrafi, ale jakoś nie wydaje mi się, by mógł sie stać obowiązkowym narzędziem każdego z developerów php.pl (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

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.

To jednak uważam za zbędne. Wydaje mi się, że warto by w tym miejscu odstąpić od notacj węgierskiej, i zostawić Obiekty bez 'o' na poczatku, i zaczynając od dużej litery, celem zwiększenia czytelności kodu. Nikt nie broni nam od czasu do czasu być prekursorami.
Nie grozi nam przecież pomyłka "czy to klasa czy obiekt?" a taki zapis znacznie ułatwia odwoływanie się do innych obiektów wewnątrz danego
(to o czym pisałem wcześniej $Core->View->CośTam )

[cagrET]

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.

Bo w takiej Javie nie możesz mieć zmiennej Test jesli masz klasę Test. A w php możesz, ponieważ mamy znaczek $. Zwykłe zmienne zawsze koduję z małej litery, a zmienne obiektów z dużej. Przedrostek "o" jest zatem zbędny.

Kod

<?php

    function connection( &$dsn, $persistent = false )

    {

        if ( is_array( $dns ) )

        {

            $dns_info = &$dns;

        }

        else

        {

            $dns_info = BD::parseDNS( $dns );

        }



        if ( !( $dns_info ) || !( $dns_info['phpType'] ) )

        {

            return $this->addError();

        }



        return TRUE;

    }

?>

Blee, ale mi się to nie podoba (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)
Preferuję:

Kod

<?php

    function connection(&$dsn, $persistent = false) {

        if (is_array($dns)) {

            $dns_info = &$dns;

        } else {

            $dns_info = BD::parseDNS($dns);

        }

        if (!($dns_info) || !($dns_info['phpType'])) {

            return $this->addError();

        }

        return true;

    }

?>

O wiele bardziej przejrzyste, pozatym aż 7 linijek oszczedzamy w edytorze ! (20 / 13). Dzięki temu taki kod czyta się prawie 2 razy szybciej oraz w edytorze widzimy prawie 2 razy wiecej kodu, dzieki czemu mamy lepsze spojrzenie na to co się tak naprawdę w tym naszym kodzie dzieje .. Kodowaliście kiedyś w edytorze (z odpowiednia rozdzielczoscia i czcionka) w którym macie widocznych 80 linijek naraz ? Mówię wam, komfort kodowania jest po prostu nie do opisania .. porównując z edytowaniem z widocznymi 35 linijkami. Aktualnie mam 70 linijek w edytorze, nie stosuję dodatkowych enterów ktore wydluzaja kod dwukrotnie, ostatecznie mam 4 razy bardziej przejrzysty kod (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif)

Fajne czcionki można zassać stąd: http://www.tactile3d.com/tristan/ , http://www.tobiasjung.net/profont/index.html

Btw. dlaczego na początku funkcji "false" pisane jest z małej litery, a na końcu "TRUE" jest pisane dużymi ?

[shima]

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 (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) , czy nie jest istotne, jakiej notacji używam w nazwach, ważne, że jest konsystentna, czytelna i niezmienna.

[sztosz]

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

[hawk]

Hmm, przyznaję się bez bicia że to co preferuje cagrET to jakby żywcem wyjęte z mojego stylu (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) . 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.

[treewood]

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.

[kodereq]

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 ?

[Crozin]

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.

[kwiateusz]

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

[Crozin]

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.

[starach]

Pozwolę sobie odgrzać tego zielonkawego już kotleta. (IMG:style_emoticons/default/winksmiley.jpg)

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ł. (IMG:style_emoticons/default/blink.gif)

[Tomplus]

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

[PHP] pobierz, plaintext 
if ( $foo == true )
{
    foo();
}
[PHP] pobierz, plaintext 

tego

[PHP] pobierz, plaintext 
if ( $foo == true ) foo();
[PHP] pobierz, plaintext 

Mówię tutaj dobitnie o takich krótkich funkcjach warunkowych. Ja uważam że coś takiego jest prawidłowe, szczególnie jeżeli klamry i nawiasy mienia sie w oczach. Więc powiedzcie, dlaczego to 1 ma być takie lepszego od tego mojego przykładu, nie zalecanego w artykule ?

[erix]

1. czytelność jest większa (sam kolor nie wystarczy, nie bez powodu wymyślono marginesy i puste miejsca)
2. szybkość rozbudowy bloku (wystarczy wstawić nową linijkę i klepać)
3. prawidłowe przyzwyczajenia - większość projektów wymaga stosowania klamerek w swoich standardach (z tego, co pamiętam, to nawet projekty Zenda)

[Tomplus]

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.

[PHP] pobierz, plaintext 
 
echo ("mój text");
//albo
$foo = ("jakis text");
//czy
echo "<font color=\"white\">Mój text</font>";
[PHP] pobierz, plaintext 

ale teraz mogę mu pokazać taki artykuł (IMG:style_emoticons/default/smile.gif)
niech się nauczy jak pisać NOWOCZEŚNIE i prawidłowo (IMG:style_emoticons/default/tongue.gif)

[lars_91]

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] pobierz, plaintext 
<?php
if($expression) {
    echo 'True;
}
?>
[PHP] pobierz, plaintext 

od:

[PHP] pobierz, plaintext 
<?php
if($expression)
{
    echo 'True;
}
?>
[PHP] pobierz, plaintext 

Mamy poza tym krótszy kod.

Ten post edytował lars_91 17.08.2009, 10:41:35

[erix]

2. Nawiasy klamrowe - Wg. mnie czytelniejsze jest stosowanie:

Jeśli chodzi o sposób zapisywania nawiasów, to istnieją dwie szkoły - a wyznawców praktycznie 50/50. ;]

[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 (IMG:style_emoticons/default/winksmiley.jpg) 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,
(IMG:style_emoticons/default/cool.gif) 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 (IMG:style_emoticons/default/winksmiley.jpg)
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 (IMG:style_emoticons/default/winksmiley.jpg)

[albrzykowski]

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.

Ten post edytował albrzykowski 5.12.2009, 12:02:47

[starach]

Wydaje mi się że to już nie ma co się czepiać, tylko trzeba ten temat zarchiwizować lub dodać mu jakiś tag typu [nieaktualne].

[emp]

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

Ten post edytował emp 5.02.2010, 01:46:26

[erix]

A przeczytałeś ten wątek? Ja akurat NetBeans/Eclipse/czegokolwiek w javie nie znoszę i co?

[Volume]

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:

[PHP] pobierz, plaintext 
if(...) {
...
}
[PHP] pobierz, plaintext 

zdecydowanie wole:

[PHP] pobierz, plaintext 
if(...) 
{
...
}
[PHP] pobierz, plaintext 

czyli odwrotnosc do tego co podal thek

[pitbull82]

zdecydowanie wole:

Ja do niedawna też, ale widzę że jak się używa bardziej zaawansowanych edytorów które zwijają kod, to traci się po zwinięciu linijkę, bo zostaje { (phped), więc postanowiłem zmienić wieloletnie przyzwyczajenia.

[kulczycki]

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

Wszystko piszemy z małej litery ?. Logicznie rzecz biorąc nie ma to większego sensu. Przykład
islogin() czy IsLogin() : wybieraj (IMG:style_emoticons/default/winksmiley.jpg)

a teraz przykład długiej nazwy funkcji
handlequestgiverstatusqueryopcode( WorldPacket & recv_data )
czy
HandleQuestgiverStatusQueryOpcode( WorldPacket & recv_data )

chyba że chodzi Ci o nazwy zmiennych - to się zgodzę ale nie w każdym przypadku. Co do plików też się nie zgodzę ;P

co do klamr, ja znów mam nawyk z c++ i kilku obszernych projektów i wole stosować

[PHP] pobierz, plaintext 
if( warunek ){
 
}
[PHP] pobierz, plaintext 

spacje po i przed nawiasami, nie wiem czemu ale jakoś tak wygodniej mi. Klamry za warunkiem.

Tak naprawdę standardy standardami ale trudno nauczyć człowieka czegoś innego od tego jak mu dobrze. Każdy pisze tak jak lubi, jedynie to w projekcie na większa skale trzeba się czegoś trzymać.

Ten post edytował kulczycki 30.12.2010, 00:33:17

[phpion]

handlequestgiverstatusqueryopcode( WorldPacket & recv_data )
czy
HandleQuestgiverStatusQueryOpcode( WorldPacket & recv_data )

Dlaczego pakujesz camelCase jako nazwę funkcji do języka, który korzysta z under_score?
handle_quest_giver_status_query_opcode( WorldPacket & recv_data )
Takie cuda jak podane przez Ciebie pasują do JavaScript (z tym, że pierwsza litera to mała litera), a nie do PHP.

[kulczycki]

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 (IMG:style_emoticons/default/smile.gif)

[phpion]

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/j...n_functions.htm

[kulczycki]

A masz na myśli nazwy zwykłych funkcji czy też metod w obiektach ?

[Crozin]

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

[darko]

Odkurzam. W zalinkowanym artykule w temacie lista znaczników phpDoc jest już niekompletna.

[Dejmien_85]

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

Odgrzeję starego i zgniłego koteleta, ale wyłącznie w celach edykacyjnych.

Nie spotkałem się nigdy z terminem "under_score", to się nazywa "snake_case" - ogólnie mamy 3 terminy:
- snake_case,
- camelCase,
- StudlyCaps.

Co do standardów kodwania - obecnie w PHP chyba najlepszy wybór to PSR-X i do tego książki typu "Clean Code". (IMG:style_emoticons/default/wink.gif)

[irekk]

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.

[Dejmien_85]

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.

Hmm, ogólnie to niedawno w jednej z książek (chyba Javy) spotkałem się z określeniami: lowerCamelCase i UpperCamelCase.

Później zajrzałem na wiki i zobaczyłem:

- BumpyCaps/BumpyCase
- camelBack
- CamelCaps
- CapitalizedWords/CapWords
- compoundNames
- Embedded Caps/Embedded Capitals
- HumpBack
- InterCaps/Internal Capitalization
- mixedCase
- nerdCaps/headlessCamelCase
- PascalCase
- SmalltalkCase
- WikiWord/WikiCase
- wimpyCaps

No i pomyślałem sobie, że... tak mało wiemy. ; F

Dobra, nie ma co rozgrzebywać tego tematu, jak widać co język to nowe pojęcia - a ludzie uwielbiają finezję. ; )

[com]

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/

[Salvation]

PSR-12. Każdy inny standard użyty w kodzie, to "widzi mi się" programisty / firmy i nie powinien istnieć (IMG:style_emoticons/default/tongue.gif)

[com]

@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 (IMG:style_emoticons/default/smile.gif)