Drukowana wersja tematu

Kliknij tu, aby zobaczyć temat w orginalnym formacie

Forum PHP.pl _ Artykuły _ Standardy kodowania [scanner]

Napisany przez: scanner 26.04.2004, 22:37:32

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

Napisany przez: Wankster 26.04.2004, 22:49:45

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

Napisany przez: Seth 26.04.2004, 23:17:22

Jest maly blad w wygladzie komentarzy. Nie tak:

Kod
/**

*

* ...

*/


a tak:

Kod
/**

*

* ...

*/


winksmiley.jpg

Napisany przez: PMadej 26.04.2004, 23:23:56

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.

Napisany przez: Dawid Pytel 27.04.2004, 00:11:47

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 smile.gif Na marginesie dodam, ze wiekszosc edytorow ma opcje zamiany tabulatora na spacje.

Napisany przez: Bakus 27.04.2004, 02:09:30

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

Napisany przez: scanner 27.04.2004, 06:19:14

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

Napisany przez: wassago 27.04.2004, 08:04:15

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]

Napisany przez: HaRy 27.04.2004, 08:39:59

ciekawy art.
teraz nic, tylko sie przyzwyczajac do standartow winksmiley.jpg

pozdro.

Napisany przez: kszychu 27.04.2004, 09:38:04

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.

Napisany przez: DavidPL 27.04.2004, 11:31:27

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

Napisany przez: DeyV 27.04.2004, 11:39:04

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 winksmiley.jpg
w skrócie:
zawsze 'tekst ' . $zmienna . ' tekst';
zawsze echo, nie print.

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

Napisany przez: shima 27.04.2004, 13:12:26

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

Napisany przez: wassago 27.04.2004, 13:19:37

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

Napisany przez: shima 27.04.2004, 14:02:22

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

Napisany przez: lukaswoj 27.04.2004, 14:27:37

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

Napisany przez: shima 27.04.2004, 14:57:34

Cytat
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 smile.gif

Tak jest, ale każdy sensowny edytor pozwala ustawić ilość spacji. Byle była całkowita winksmiley.jpg

Napisany przez: DeyV 27.04.2004, 15:29:01

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.

Napisany przez: shima 27.04.2004, 15:36:59

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

Napisany przez: Bonhart 29.04.2004, 08:37:26

Rozumiem, że ogólnie przyjęte jest stosowanie nazw fuckcji, zmiennych w języku angielskim ale Polacy nie gęsi smile.gif) ... tym bardziej że komentarze są w języku ojczystym .

Napisany przez: scanner 29.04.2004, 08:43:12

Cytat
Rozumiem, że ogólnie przyjęte jest stosowanie nazw fuckcji, zmiennych w języku angielskim ale Polacy nie gęsi 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]

Napisany przez: Bonhart 29.04.2004, 11:25:25

Cytat
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 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ą laugh.gif

Napisany przez: wassago 30.04.2004, 08:04:50

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

Napisany przez: shima 30.04.2004, 13:54:33

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

Napisany przez: szafranek.net 2.05.2004, 12:12:22

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 smile.gif ). Na dodatek nie jest zgodne ze stanadardem PEAR. Myślę że spokojnie możnaby obyć się bez tego wymagania.

Napisany przez: Bora 4.05.2004, 22:47:15

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

Napisany przez: invx 5.05.2004, 17:35:36

ja niewiem po co przy nazwach zmiennych pisac jej typ ?

Napisany przez: scanner 5.05.2004, 17:42:58

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

Napisany przez: wassago 5.05.2004, 19:02:17

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

Napisany przez: Bora 5.05.2004, 20:20:10

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

Napisany przez: treewood 1.06.2004, 11:56:56

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

Napisany przez: DeyV 1.06.2004, 12:30:31

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]

Napisany przez: treewood 1.06.2004, 12:38:15

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

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

Napisany przez: sztosz 2.06.2004, 12:34:18

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]

Napisany przez: scanner 2.06.2004, 12:49:20

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

Napisany przez: wassago 2.06.2004, 13:08:06

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

aaamen! :wink:

Napisany przez: sztosz 2.06.2004, 13:22:33

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?

Napisany przez: Sh4dow 2.06.2004, 13:59:17

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 questionmark.gif?
function funkcyjka() {
//...
}
//czy tak ?
function funkcyjka2 ( )
{
//...
}

$a=$b+$c;
// czy questionmark.gif
$a = $b + $c;

mysql_query ( " SELECT * FROM t1 WHERE col1 = ' " . $cos . " ' " );
//czy 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 jahttp://www.bierkandt.org/beautify/ do pozadkowania kodu. Sam czasami kozystam w niektorych sytuacjach.

Napisany przez: treewood 2.06.2004, 14:17:12

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

Napisany przez: wassago 2.06.2004, 14:20:08

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

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

Napisany przez: DeyV 2.06.2004, 14:23:38

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

Cytat
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 winksmiley.jpg

Napisany przez: treewood 2.06.2004, 14:29:04

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)

Napisany przez: Przemo` 3.06.2004, 00:30:56

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

Cytat
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 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 http://phpbb.com/phpBB/docs/codingstandards.htm 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.

Napisany przez: DeyV 7.06.2004, 09:22:10

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

Napisany przez: wassago 7.06.2004, 10:01:44

Cytat
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 (!?)

Napisany przez: hawk 7.06.2004, 10:09:40

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

Napisany przez: DeyV 7.06.2004, 13:08:22

Cytat
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 winksmiley.jpg

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

Napisany przez: cagrET 7.06.2004, 13:51:59

Cytat
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 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 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 ?

Napisany przez: shima 7.06.2004, 13:55:32

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 winksmiley.jpg, czy nie jest istotne, jakiej notacji używam w nazwach, ważne, że jest konsystentna, czytelna i niezmienna.

Napisany przez: sztosz 7.06.2004, 14:16:41

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

Napisany przez: hawk 7.06.2004, 15:03:39

Hmm, przyznaję się bez bicia że to co preferuje cagrET to jakby żywcem wyjęte z mojego stylu 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.

Napisany przez: treewood 8.06.2004, 11:45:54

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.

Napisany przez: kodereq 2.05.2009, 12:00:14

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 ?

Napisany przez: Crozin 2.05.2009, 12:03:57

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.

Napisany przez: kwiateusz 2.05.2009, 14:33:27

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

Napisany przez: Crozin 2.05.2009, 14:43:53

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.

Napisany przez: orglee 11.08.2009, 01:27:35

Pozwolę sobie odgrzać tego zielonkawego już kotleta. 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ł. blink.gif

Napisany przez: Tomplus 11.08.2009, 06:19:21


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

  1. if ( $foo == true )
  2. {
  3. foo();
  4. }


tego

  1. if ( $foo == true ) foo();


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 ?

Napisany przez: erix 11.08.2009, 08:59:38

  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)

Napisany przez: Tomplus 11.08.2009, 11:00:53

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.

  1.  
  2. http://www.php.net/echo ("mój text");
  3. //albo
  4. $foo = ("jakis text");
  5. //czy
  6. http://www.php.net/echo "<font color=\"white\">Mój text</font>";


ale teraz mogę mu pokazać taki artykuł smile.gif
niech się nauczy jak pisać NOWOCZEŚNIE i prawidłowo tongue.gif

Napisany przez: lars_91 17.08.2009, 10:41:00

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:

  1. <?php
  2. if($expression) {
  3. http://www.php.net/echo 'True;
  4. }
  5. ?>

od:
  1. <?php
  2. if($expression)
  3. {
  4. http://www.php.net/echo 'True;
  5. }
  6. ?>

Mamy poza tym krótszy kod.

Napisany przez: erix 17.08.2009, 11:38:33

Cytat
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. ;]

Napisany przez: thek 22.08.2009, 23:34:31

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

  1. funkcja(funkcja2(argument2_1,funkcja3()),parametr2,funkcja3())

są mniej czytelne niż
  1. funkcja( funkcja2( argument2_1, funkcja3() ), parametr2, funkcja3() )

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.
  1. if( warunek ) {
  2. if( warunek ) {
  3. instrukcje;
  4. } else {
  5. instrukcje;
  6. }
  7. } elseif {
  8. instrukcje;
  9. } else {
  10. instrukcje;
  11. }

  1. if( warunek )
  2. {
  3. if( warunek )
  4. {
  5. instrukcje;
  6. }
  7. else
  8. {
  9. instrukcje;
  10. }
  11. }
  12. elseif
  13. {
  14. instrukcje;
  15. }
  16. else
  17. {
  18. instrukcje;
  19. }
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
  1. http://www.php.net/echo ( warunek) ? instrukcja : instrukcja;

, ale gdy ktoś zobaczy coś takiego pierwszy raz zapewne nie przyjdzie mu do głowy, ze jest to odpowiednik znanego mu
  1. if( warunek) {
  2. http://www.php.net/echo instrukcja;
  3. } else {
  4. http://www.php.net/echo instrukcja;
  5. }

Zresztą sam jestem zwolennikiem stosowania skrótów tam gdzie to możliwe i nieraz stosuję formę
  1. if( warunek )
  2. http://www.php.net/echo instrukcja;
  3. else
  4. http://www.php.net/echo instrukcja;

a gdy nie ma else, po prostu
  1. if( warunek ) http://www.php.net/echo instrukcja;

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 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,
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 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 winksmiley.jpg

Napisany przez: albrzykowski 5.12.2009, 12:01:53

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.

Napisany przez: orglee 5.12.2009, 20:02:02

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

Napisany przez: emp 5.02.2010, 01:43:59

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

Napisany przez: erix 5.02.2010, 18:46:08

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

Napisany przez: Volume 9.05.2010, 18:36:26

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:

  1. if(...) {
  2. ...
  3. }


zdecydowanie wole:

  1. if(...)
  2. {
  3. ...
  4. }


czyli odwrotnosc do tego co podal thek

Napisany przez: pitbull82 9.11.2010, 15:01:15

Cytat(Volume @ 9.05.2010, 19:36:26 ) *
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.

Napisany przez: kulczycki 30.12.2010, 00:27:03

Cytat
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 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ć
  1. if( warunek ){
  2.  
  3. }


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

Napisany przez: phpion 3.01.2011, 13:08:16

Cytat(kulczycki @ 30.12.2010, 00:27:03 ) *
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.

Napisany przez: kulczycki 3.01.2011, 22:53:40

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

Napisany przez: phpion 4.01.2011, 07:26:39

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

Napisany przez: kulczycki 4.01.2011, 07:37:47

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

Napisany przez: Crozin 4.01.2011, 12:47:29

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

Napisany przez: darko 4.05.2011, 22:22:19

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

Napisany przez: Dejmien_85 8.10.2014, 23:26:21

Cytat(Crozin @ 4.01.2011, 13:47:29 ) *
@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". wink.gif

Napisany przez: irekk 2.11.2014, 18:07:53

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.

Napisany przez: Dejmien_85 5.11.2014, 08:52:48

Cytat(irekk @ 2.11.2014, 18:07:53 ) *
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ę. ; )

Napisany przez: com 23.06.2022, 23:27:20

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/

Napisany przez: Salvation 24.06.2022, 12:44:34

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

Napisany przez: com 14.07.2022, 15:07:11

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

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)