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

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

Jest maly blad w wygladzie komentarzy. Nie tak:


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

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.

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

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

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.

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 .

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]

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
Ja równięż używam nazw angielskich, bo czasem trudno znaleść odpowiedniki np query = kwerenda
W sumie moj post był pewnego rodzaju prowokacją

@shima: jeszcze cos dla Ciebie http://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

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?

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:

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

aaamen! :wink:

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

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.

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 )


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

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

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

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

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

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


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 )

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.


Blee, ale mi się to nie podoba
Preferuję:

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

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 ?

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)