Stiluri de scriere a codului sursa

[Manu]

De-a lungul timpului mi-am tot schimbat pe ici pe colo stilul de scriere a codului sursa.
Sunt curios cum SCRIU si altii si care sunt standardele in vigoare, daca exista astfel de standarde.

Referindu-ma in special la limbajele C-like, cu blocuri de cod intre acolade, pot spune ca respect in prezent urmatoarele:

- Acolada deschisa o pun la sfarsitul randului care declara o noua functie, exprima un if, for sau while. Inainte o puneam pe rand nou, dar mi-am dat seama ca e mai economicos astfel. Am vazut coduri sursa atat cu acolada la sfarsit de rand, cat si pe rand nou singura sau eventual insotita de un comentariu despre ce face blocul respectiv de cod.
Daca acum pun acolada pe acelasi rand cu expresia care deschide blocul de cod, comentariu il pun pe randul anterior.

- Comentariile pe un rand, precedate de doua slash-uri, le scriu dupa acestea si un spatiu, cu litera mare daca sunt deasupra randului sau blocului de cod la care se refera, cu litera mica daca sunt la sfarsit pe acelasi rand cu codul pe care il explica.
Inainte stiu ca puneam cele doua slash-uri lipite de comentariul propriu-zis scris cu litera mica, nu imi dau seama cand si cum m-am schimbat.

- De obicei nu am indentat codul mai mult decat o facea editorul, daca era vreunul cu astfel de facilitate. Acum am incercat sa folosesc taburile pentru a indenta, chiar daca e mai greu sa nu fac omisiuni. Un editor precum EdSharp spune nivelul de indentare la apasarea Alt+I si atunci e mai usor de orientat prin cod, stiu mai clar si fara comentarii unde se incheie un bloc de cod, mai ales cand se inchid cate 3 / 4 unul dupa altul.

- Numele functiilor le scriu acum Camel Case, parca e mai usor si mai clar fiindca JAWS citeste cuvinte diferite. Inainte le scriam cu litere mici, cuvinte delimitate de liniute de subliniere, JAWS citea tot cuvinte diferite, dar parca e mai greu de ajuns de fiecare data la underline si devine enervant cand e nevoie de multe pentru un singur nume, mai ales ca am observat, probabil ca influentat de Java, tedninta e sa scriu cat mai descriptiv numele functiilor. De fapt e si mai usor de inteles apoi ce am facut si fara prea multe comentarii, comentariu ajungand sa fie chiar codul in sine.

- Probabil influentat tot de JavaScript si Java, numele variabilelor le scriu Camel Case, prima litera fiind totusi mica.
Inainte imi placea Hungarian Notation, pentru ca am inceput cu JAWS Scripting unde aveam adesea nevoie de aceeasi valoare si ca string, si ca integer.

[IonPop]

"De-a lungul timpului mi-am tot schimbat pe ici pe colo stilul de scriere a codului sursa.
Sunt curios cum SCRIU si altii si care sunt standardele in vigoare, daca exista astfel de standarde.".

In general nu exista standarde de scriere a codului pentru toate limbajele, fiindca modul de scriere a codului poate diferi mult de la limbaj la limbaj, dar de obicei pentru fiecare limbaj exista un cod de bune practici recomandat.

Pentru Perl de exemplu exista o carte "Perl Best Practices" in care se descrie pe larg cum trebuie scris un program in Perl pentru a fi usor de intretinut. Si iti dai seama ca exista multe detalii daca o carte intreaga descrie doar despre cum este bine sa scri.
Dupa acea carte s-a creat modulul Perl::Critic care ofera comanda perlcritic, care verifica unul sau mai multe fisiere Perl daca sunt bine scrise, cele mai multe reguli fiind din acea carte, iar daca ceva nu e bine, in eroare iti da detalii si iti spune chiar si numarul paginii din carte la care trebuie sa citesti ca sa vezi ce nu e bine.
Si poti configura acel program cu un fisier de configurare in care sa stabilesti regulile pe care vrei sa le aplici si ce importanta au fiecare, fiindca poti alege sa iti afiseze doar erorile de o anumita importanta, iar acele reguli nu se refera doar strict la modul de formatare a codului sursa, ci la multe mai multe.
De asemenea, exista modulul Perl::Tidy care ofera comanda perltidy cu care poti crea un nou fisier gata formatat, dupa toate regulile, dar si aceste reguli pot fi modificate in functie de standardul ales de fiecare echipa.

"- Acolada deschisa o pun la sfarsitul randului care declara o noua functie, exprima un if, for sau while. Inainte o puneam pe rand nou, dar mi-am dat seama ca e mai economicos astfel. Am vazut coduri sursa atat cu acolada la sfarsit de rand, cat si pe rand nou singura sau eventual insotita de un comentariu despre ce face blocul respectiv de cod.
Daca acum pun acolada pe acelasi rand cu expresia care deschide blocul de cod, comentariu il pun pe randul anterior.".

Asa este recomandarea de baza si pentru programele in Perl si asa fac majoritatea programatorilor in Perl, insa nu toti.
Unii prefera sa puna acolada deschisa pe un rand nou fiindca din punct de vedere vizual este oarecum mai clar fiindca ea este pe aceeasi coloana cu acolada de inchidere.
Eu prefer sa o pun totusi la fel ca tine, pe acelasi rand la sfarsit de rand, tot fiindca este mai simplu si nu mai trebuie sa pierd un rand in plus doar pentru acea acolada, iar din punct de vedere vizual este foarte putin important ca nu apare pe aceeasi coloana cu cea de inchidere.

De cele mai multe ori nu este nevoie de comentarii, dar atunci cand este nevoie, majoritatea prefera sa le puna deasupra numelui subrutinei sau blocului if().
Eu prefer de obicei sa pun comentariile dedesubt fiindca imi pare mai logic.
Adica merg pe idea ca dupa ce ai spus if()... tot ce se intampla in cazul in care acea conditie este respectata este inclus in blocul acelei conditii.
Un comentariu in afara blocului if() nu are rost, fiindca inainte de acel if() acea conditie nu este respectata. Ceva de genul:

daca ( basescu=smecher ) {
#Avem un presedinte smecher
...
}

Nu ar fi OK daca codul ar arata ca:

#Avem un presedinte smecher
daca ( basescu=smecher ) {
...
}

...Fiindca mai intai spun ceva, si doar apoi verific daca conditia este adevarata.
Si mai exista si un alt motiv, si anume fiindca cu TextPad pot selecta tot ce apare intre { si } cu Control+M, iar daca adaug si comentariul in interiorul blocului, daca mut acel cod altundeva, preiau implicit si comentariul asa ca este mai simplu, si la fel este si in cazul subrutinelor.
Insa dupa cum spuneam, eu pun destul de rar comentarii. Idea este ca este bine sa pui comentarii doar pentru codul din care nu rezulta clar ce face, cum este de exemplu cazul folosirii regular expressions mai complexe.

"- Comentariile pe un rand, precedate de doua slash-uri, le scriu dupa acestea si un spatiu, cu litera mare daca sunt deasupra randului sau blocului de cod la care se refera, cu litera mica daca sunt la sfarsit pe acelasi rand cu codul pe care il explica.
Inainte stiu ca puneam cele doua slash-uri lipite de comentariul propriu-zis scris cu litera mica, nu imi dau seama cand si cum m-am schimbat.".

Eu pun destul de rar comentarii la sfarsitul randului, dar asta cred ca in primul rand fiindca sunt orb, si risc sa sar peste ele daca nu astept Jaws sa imi citeasca randul pana la sfarsit, asa ca pentru siguranta le pun de obicei la inceputul randului.
Nu am un standard in ceea ce priveste scrierea lor cu litera mare sau mica si nici daca dupa caracterul # las un spatiu gol sau nu, insa comentarii fiind, aceste lucruri sunt neimportante.
Cand creez module care ar putea sa mai fie folosite si de altii, sau de care si eu voi mai avea nevoie multa vreme, de obicei adaug si documentatie in ele cu niste marcaje speciale.
Unii programatori adauga documentatia bucatica cu bucatica inainte de fiecare subrutina, descriind ce face, iar altii o adauga in intregime la sfarsitul modulului.
Cand este adaugata bucata cu bucata inainte de fiecare subrutina este foarte usor de folosit cand vrei sa intretii codul sursa, fiindca vezi imediat ce face subrutina respectiva si detalii despre ea, iar dupa ce faci eventualele modificari poti actualiza rapid si documentatia acolo.
Cand insa vrei doar sa arunci o privire generala asupra codului si nu te intereseaza sa citesti si documentatia, este mai usor daca documentatia este la sfarsit.
Pentru vazatori nu exista multe probleme legate de documentatie, fiindca ei pot folosi editoare care pot ascunde temporar documentatia, folosesc editoare care afiseaza in culori diferite codul si documentatia etc, insa eu prefer totusi sa pun documentatia la sfarsit, fiindca nici pe diferentele de culori nu ma pot baza, si nici nu pot folosi toate editoarele existente, asa ca este mai clar asa.

"- De obicei nu am indentat codul mai mult decat o facea editorul, daca era vreunul cu astfel de facilitate. Acum am incercat sa folosesc taburile pentru a indenta, chiar daca e mai greu sa nu fac omisiuni. Un editor precum EdSharp spune nivelul de indentare la apasarea Alt+I si atunci e mai usor de orientat prin cod, stiu mai clar si fara comentarii unde se incheie un bloc de cod, mai ales cand se inchid cate 3 / 4 unul dupa altul.".

TextPad permite indentarea automata a codului, dar mie nu imi place sa o folosesc, poate si fiindca eu nu folosesc TextPad doar pentru a scrie cod sursa, ci pentru multe altele de genul editarii fisierelor .csv, .txt, .html si imi place sa salveze ce scriu eu, nu ce vrea el.
Eu indentez cu tasta tab, dar am setat TextPad sa imi puna 4 spatii in loc de un caracter tab, si fiindca asa se recomanda pentru programele in Perl, insa de fapt asta este o recomandare si pentru alte limbaje fiindca daca se folosesc caractere tab codul poate arata formatat foarte incorect daca este deschis de alti utilizatori care au setat editorul sa afiseze tasta tab nu ca 8 spatii, ci doar ca 4 sau 2.
Asa, dupa ce apas tab, se adauga de fapt 4 spatii obisnuite, iar un spatiu este un spatiu in toate editoarele.
Eu prefer sa folosesc spatii si din motive legate de accesibilitate, fiindca Jaws nu citeste intotdeauna caracterele tab ca fiind tab, ci in multe editoare si campuri text le citeste ca spatii, asa ca nu stiu daca am sters un simplu spatiu si mai trebuie sa sterg cateva, sau am sters un caracter tab si este suficient.

"- Numele functiilor le scriu acum Camel Case, parca e mai usor si mai clar fiindca JAWS citeste cuvinte diferite. Inainte le scriam cu litere mici, cuvinte delimitate de liniute de subliniere, JAWS citea tot cuvinte diferite, dar parca e mai greu de ajuns de fiecare data la underline si devine enervant cand e nevoie de multe pentru un singur nume, mai ales ca am observat, probabil ca influentat de Java, tedninta e sa scriu cat mai descriptiv numele functiilor. De fapt e si mai usor de inteles apoi ce am facut si fara prea multe comentarii, comentariu ajungand sa fie chiar codul in sine.".

Fiindca tot cuvinte intregi sunt citite de Jaws si daca se concateneaza cuvinte cu litera mare si cu liniuta de subliniere, indiferent care metoda este folosita este la fel de descriptiv si tot nu este nevoie sa se adauge comentarii.
Preferinta pentru cuvinte cu litera mare se datoreaza editorului folosit, fiindca in Eclipse daca te deplasezi cu Control+sageata stanga/dreapta, cursorul sare de la un cuvant la altul si poti sa editezi mai usor un anumit cuvant fara sa trebuiasca sa apesi sageata stanga/dreapta de o multime de ori.
In TextPad se poate alege de asemenea care caractere vrei sa fie considerate de tip "word". In mod implicit sunt caracterele a-zA-Z0-9_, deci si liniuta de subliniere. Daca vrei poti sa o elimini, asa ca cursorul se va opri la fiecare cuvant. Acest mod de scriere are avantajul ca poti sari mai usor de la un cuvant la altul cand vrei sa faci modificari, dar are dezavantajul ca trebuie sa apesi Control+sageata stanga/dreapta de mult mai multe ori cand vrei sa treci de numele variabilei sau subrutinei respective, asa ca prefer sa considere si caracterul _ ca facand parte din cuvant cum este in mod implicit.

Si bineinteles, preferinta pentru cuvinte cu litere mari se datoreaza limbajului folosit. Daca recomandarea pentru un anumit limbaj si toata documentatia foloseste camel case, ar fi dificil si total nestandard sa folosesti un alt sistem.

In Perl se folosesc cuvinte concatenate care incep cu majuscula si cuvinte concatenate cu caracterul _ in scopuri diferite.
Numele modulelor incep cu litera mare si sunt combinatii de cuvinte despartite cu ::, iar daca o anumita parte contine mai multe cuvinte, ele apar cu litera mare fiecare ca de exemplu:
Foo::BarBiz
Dar modulele de tip pragma care modifica modul de lucru al programelor se scriu cu litere mici, ca de exemplu in:
use strict;

Constantele sunt scrise de obicei doar cu litere mari, iar daca sunt compuse din mai multe cuvinte, sunt unite cu caracterul de subliniere ca in: FOO_BAR.
Iar variabilele si subrutinele se scriu cu litere mici, iar cuvintele sunt despartite de caracterul de subliniere.

Aceste reguli insa nu sunt batute in cuie, fiindca daca de exemplu intr-un program in Perl se foloseste o biblioteca ca Win32::GUI care are un stil de programare tip Windows, se foloseste acelasi stil in care variabilele si subrutinele specifice sunt scrise cu prima litera majuscula.
In acest mod este ceva mai clar care subrutine definesc evenimente ale interfetei grafice, si care sunt subrutine care nu au legatura cu interfata.

Dar daca nu scri programe cu intrefata grafica, probabil in 99% din cazuri trebuie sa folosesti doar cuvinte cu litera mica despartite de caracterul de subliniere, fiindca constante sunt folosite oricum destul de rar, iar nume de module sunt de asemenea folosite mai rar doar la includerea lor in programul curent si la initializarea obiectului...

Mie imi place cand trebuie sa scriu doar cu litera mica si fiindca este mai usor, si chiar imi place mai mult cum este in Python si Ruby unde si modulele se scriu tot cu litera mica.
Ce nu imi place in Python insa este ca am intalnit multe cuvinte scrise cu litera mica care erau concatenate fara liniuta de subliniere, iar Jaws le citeste foarte ciudat si sunt greu de inteles.
Imi place insa stilul de scriere cu litere mici si liniuta de subliniere si din alte motive, adica si fiindca pot folosi acelasi stil si cand scriu cod sql si nu am apoi deloc probleme. In anumite baze de date conteaza daca se scrie cu litera mica sau mare si este de preferat sa scri cu litera mica fiindca altfel este posibil sa fie nevoie sa adaugi si ghilimele, iar uneori codul SQL nu il scri manual, ci este scris automat de un ORM, si trebuie sa iti mai bati capul si cu setari suplimentare ca sa includa anumite nume de tabele sau coloane intre ghilimele, asa ca cu litera mici totul este mai sigur.
Exista de asemenea o problema de portabilitate, fiindca daca scri doua nume de fisiere Foo.pm si foo.pm sub Linux si incerci sa le descarci sub Windows, unul dintre ele se va pierde, fiindca in Windows in mod implicit nu se tine cont de aceste diferente. Asa ca daca se obisnuieste scrierea cu litera mica intotdeauna pe cat posibil, este mai bine fiindca altfel pot aparea griji suplimentare.

"- Probabil influentat tot de JavaScript si Java, numele variabilelor le scriu Camel Case, prima litera fiind totusi mica.
Inainte imi placea Hungarian Notation, pentru ca am inceput cu JAWS Scripting unde aveam adesea nevoie de aceeasi valoare si ca string, si ca integer.".

Daca o variabila are doua nume diferite, inseamna ca sunt doua variabile diferite, asa ca in orice limbaj poti scrie o variabila ca foo_int sau foo_string si va fi clar ce tip de date contine fiecare.
In Perl nu este nevoie de hungarian notation fiindca este clar ce face o variabila intr-o operatie in functie de operatorii folositi, iar daca exista doua variabile cu nume similare, se poate adauga in numele variabilei un prefix sau sufix care sa arate mai clar pentru ce anume sunt folosite fiecare.

Cand scriam cod in Javascript, Visual Basic si VBA in urma cu vre-o 15 ani si eu foloseam camel case, insa nici atunci nu imi placea respectivul mod descriere, insa din simple motive de aspect. Imi parea ca FooBarBaz arata OK, dar fooBarBaz arata super nasol, adica sa scriu un cuvant care sa contina si litere mari, dar culmea, sa inceapa cu litera mica.
Dar pana la urma este o chestiune de obisnuinta. Daca citesti o gramada de documentatie intr-un fel sau altul, iti va parea cat se poate de normal acel mod, si alte moduri vor parea mai ciudate, fiindca din lipsa de exercitiu chiar sunt mai dificil de folosit.

Desi am citit "Perl Best Practices", mult timp nu am urmat acele sfaturi fiindca imi pareau cam ciudate unele dintre ele, asa ca scriam codul dupa cum imi placea mie, adica fara spatii inainte si dupa semnul =, cand asignam o valoare unei variabile, sau fara spatii dupa ( si inainte de ) in unele cazuri fiindca imi ziceam ca in mod obisnuit dupa ( si inainte de ) nu se lasa spatii.
Dar apoi a trebuit sa corectez niste programe create de altii, si le-am formatat cu perltidy cu setarile lui implicite, si am fost surprins sa vad ca codul a devenit mai usor de citit cu Jaws dupa asta, fiindca cursorul se oprea la paranteze fara sa imi citeasca si eventualul caracter " sau $ de langa, sau se oprea la semnul = fara sa imi citeasca si urmatorul caracter.
Asa ca acum prefer si eu sa urmez acele practici recomandate si sa las cate un spatiu pe unde trebuie, dar nu mai mult de un spatiu. Adica nu imi place ca atunci cand asignez valori pentru mai multe variabile sa apas tasta tab si sa aranjez valorile respective pe aceeasi coloana ca sa arate mai bine vizual, cum se practica, fiindca este mai greu de ajuns la ele si aranjamentul vizual oricum nu ma ajuta.
Am vazut si coduri in care unii nu lasa spatii aproape deloc, nici inainte de acolada deschisa dintr-un bloc if() sau care deschide o subrutina si nici spatii intre blocuri diferite.

O buna recomandare este sa se lase spatii intre blocuri cu tipuri de cod diferit. Cel putin pentru utilizatorii de cititoare de ecran este o recomandare extraordinara.

De exemplu, eu nu scriu niciodata un cod de genul:

$variabila = "valoare";
if ( $variabila eq 'blabla' ) {
#comentariu
}
$vvariabila = "cucubau";

Ci intotdeauna las un rand gol inainte si dupa blocul if(), cu exceptia cazului in care inainte de acest bloc este un loop for, foreach, while sau este chiar inceputul subrutinei, care definesc de fapt un alt inceput de bloc de un nivel mai inalt si cu exceptia in care dupa acest bloc apare un alt caracter } care inchide un bloc de nivel mai inalt.

Adica urmatoarele sunt OK:

$variabila = "valoare";

if ( $variabila eq 'blabla' ) {
#comentariu
}

$vvariabila = "cucubau";

for my $variabila ( @variabile ) {
if ( $variabila eq 'blabla' ) {
#comentariu
}
}

In acest mod codul este mult mai clar si putem intelege mai bine unde incepe si unde se termina un bloc.

De asemenea, este OK sa pui mai multe asignari de variabile una dupa alta fara un rand gol intre ele daca codul pentru fiecare incape pe un rand. Dar daca nu incape, este bine sa lasi randuri goale pentru a vedea clar ca o expresie mai lunga este doar o singura expresie, nu doua.
Adica e OK:

$var = 1;
$foo = 2 if $buz eq "x";
$bar = 3;

dar nu e OK:

$var = 1;
$foo = "valoare cu o lungime mult mai mare care nu incape pe un singur rand, ci se intinde pe mai multe randuri..."
if $buz eq "x";
$bar = 3;

Este mai simplu de inteles codul daca inainte si dupa expresia cea lunga se lasa cate un rand gol.

In Perl a fost introdus mai demult atributul "x" pentru regular expressions care apoi a fost introdus si in alte limbaje, ca Python de exemplu, cu care se specifica ca intr-o expresie se pot lasa oricate spatii goale care nu au nici o importanta, si bucatile din acea expresie se pot scrie chiar pe randuri diferite, si fiecare pot avea chiar comentarii pentru a fi ulterior mai usor de inteles acea expresie.
Iar utilizarea acestui atribut este de asemenea recomandata.
Eu personal nu folosesc deloc acel operator fiindca pentru mine ca orb nu este mai usor de inteles codul in acest mod.
Oricum nu pot vedea bucatile din expresie dintr-o aruncare de privire iar dintr-o citire rapida linie cu linie cu Jaws este imposibil de inteles, asa ca oricum trebuie citite caracter cu caracter.
Iar daca trebuie sa le citesc caracter cu caracter, este mai confuza situatia in care dupa fiecare cateva caractere din expresie apar multe spatii sau chiar linii noi...

[Manu]

Cred si eu ca e mult mai citet pentru cineva care vede atunci cand sunt puse spatii intre if, while, for si paranteza rotund acare deschide expresia de verificat, de asemenea intre diferitii operatori din expresie si ceea ce se afla de o parte si de alta, insa mie mi s-a parut tot timpul mai comod de citit daca nu sunt spatii, merg mai repede caracter cu caracter folosind sagetile stanga / dreapta.
Probabil ca nu m-am gandit la problema citirii cu Control + sageti, asta pentru ca eu am utilizat cel mai mult Notepad2 care se oprea la fiecare spatiu sau semn.

Indentarea cu spatii m-a facut tot timpul sa ma enervez, tendinta era sa incep sa merg cu sageata dreapta sa vad pe litere un rand, dar cand constatam ca deja am apasat de 10 ori sageata dreapta fara sa se auda nimic altceva decat "space, space, space"...

Carti de best practices mi-ar placea si mie, trebuie sa fie si pentru Java... o sa caut...

[IonPop]

Intr-adevar, depinde foarte mult de editor. Eu aproape ca pot spune ca navighez mai mult cu Control+sageti decat doar cu sageti, fiindca merge mult mai rapid.
Din acest motiv ma ajuta daca intre unele elemente este spatiu, fiindca altfel unele caractere sunt citite de Jaws impreuna chiar daca ambele sunt diverse semne cum ar fi ( si $.

Problema navigarii cu Control+Sageti este una complicata, si depinde si de editorul de text, dar si de Jaws, fiindca nu conteaza doar ca editorul sa nu sara doar de la spatiu la spatiu ca Notepad, dar si ca Jaws sa nu citeasca decat ceea ce trebuie, doar ca Jaws nu are de unde sa stie cat trebuie citit, fiindca nu stie cum functioneaza fiecare editor in parte.
Asa ca citind cu Control+sageti, Jaws poate citi cateva litere, apoi la o a doua apasare poate citi inca o data aceleasi litere, desi cursorul s-a mutat inaintea unei alte litere din acel grup.

Dupa cate am observat nu exista nici un fel de standard in acest domeniu, si fiecare editor permite navigarea in felul sau. Unele dintre ele mai permit modificarea unor setari in acest sens, dar cu atat mai mult este clar ca Jaws nu are de unde sa stie cat trebuie sa citeasca.

Ideal ar fi sa existe niste reguli standard pe baza carora toate editoarele sa poata fi configurate cum doreste utilizatorul, iar Jaws sa foloseasca si el aceleasi reguli si sa permita si el modificarea setarilor.
Doar ca ar fi oricum complicat fiindca ar putea fi nevoie de o multime de reguli. Asa ca si din acest motiv daca ne obisnuim cu un editor este mai greu sa trecem cu usurinta la altul.

Mie imi place TextPad fiindca desi si in el exista cazuri in care Jaws nu citeste cum ar trebui, in general functioneaza mai bine decat alte editoare care citesc o multime de caractere impreuna, chiar daca sunt de diverse tipuri, ca paranteze, semne egal, ghilimele, semne speciale etc.
Mai are si el o problema, cum este cazul unui text intre apostroafe de genul 'foo'.
Daca textul este intre ghilimele este citit ok, intai ghilimeaua, apoi textul apoi a doua ghilimea.
Daca se foloseste apostrof, Jaws citeste apostrophe foo apostrophe la prima Control+Sageata dreapta, si mai citeste inca o data exact acelasi lucru la o a doua apasare, chiar daca cursorul s-a mutat.
Jaws ar trebui sa stie pana unde se va muta cursorul la urmatoarea apasare de Control+Sageata, si sa citeasca doar pana acolo, nu mai mult, si nici mai putin.

Exista multe editoare care citesc mai putin, adica abia pana la un anumit caracter, iar apoi la o a doua apasare de Control+sageata se sare la urmatorul grup incat unele caractere nu sunt citite deloc, ceea ce e foarte rau.

[Vortex]

Eu prefer sa pun acolada pe rand nou, inteleg mai mult din cod la o citire rapida. Daca citesc doar prima parte din rand si continui in jos, imi dau seama ca a inceput un bloc de cod si pot sari peste el daca nu ma intereseaza.
Indentarea mi-o face automat Visual Studio, exista si o comanda de corectare a layout-ului codului pe care o folosesc din cand in cand, ca sa fie mai usor de citit pentru altii.

Nici pe mine nu ma deranjeaza indentarea la navigare pentru ca, in general, navighez cu ctrl+sageti.


Comentariile le pun tot dedesuptul codului, fara litere mari. Pun accent pe ceea ce exprima comentariul, nu pe estetica. Ca si IonPop, nu prea le folosesc decat in situatii complexe.

Dupa cum sunt recomandarile in C#, folosesc CamelCase pentru clase si metode, si pascalCase pentru variabile, inclusiv obiecte. La prima vedere pare cam naspa asta, nu faci usor diferenta cand citesti rand cu rand, dar nu prea am avut cazuri in care sa am confuzii. E drept ca nici nu ma ajuta pe mine personal, am vrut sa urmez standardul pentru ceilalti.

Spre deosebire de Manu, eu nu prea imi adaptez stilul de denumire in functie de limbaj. Am fost nevoit sa lucrez putin in Jaws Script si mi se parea foarte ciudat si verbose hungarian notation ala. L-am folosit la inceput, dupa care am renuntat la el.

Si pe mine m-au enervat functiile alea in python scrise unit.


Spatii nu prea las, pentru ca nu ma ajuta. Le pune Visual Studio.

[Manu]

Nici nu auzisem de Pascal Case, acum am vazut ca e vorba de Upper Camel Case, adica acel Camel Case care incepe cu litera mare, multi considerand de fapt Camel Case doar atunci cand se incepe cu litera mica.
Sunt atatea denumiri si pentru o simpla chestiune legata strict de forma...

Sar putin si la HTML...
Tot timpul am scris tagurile cu litere mici, de la margine de rand.
Pe tagurile pereche care incadreaza o secventa mai scurta de text le lipesc de acel text pe acelasi rand daca incape, ca de exemplu:

Cod: Selectaţi tot

<title>Titlul</title>
<h1 class="title">Titlul</h1>

[IonPop]

Nici eu nu indentez codul HTML si scriu tag-urile cu litere mici fiindca pe de o parte este mai usor, iar pe de alta parte este la fel ca in codul XHTML unde tag-urile trebuie scrise neaparat cu litere mici.

[Campus]

Salutare
Eu mi-am modificat destul de mult stilul in functie de limbajul folosit.
In php foloseam destul de mult nume de functii despartite prin underline si cu cuvinte cheie ex: get_line() pentru extragere date si set_line() pentru introducere date. Mai nou folosesc CamelCase.
in Autoit (care e de fapt un scripting destul de limitat) folosean nult ceea ce a fost numit aici pascalCase.
In C# folosesc CamelCase si indentarea implicita oferita de ide. Ca fapt divers eu folosesc SharpDevelop in loc de Visual Studio Express. Imi place ideea ca , chiar si aici, exista o alternativa ide open source pentru dezvoltatori.
Acolada deschisa o las, de regula pe randul cu functia dar acolada inchisa o pun intotdeauna pe un rand nou pentru ca ajuta foarte mult la debugging. Odata, in tineretile mele, aveam vreo 5 acolade inchisae pe acelasi rand si nu mai stiam de unde vine problema
Pentru mine ajuta foarte mult sa ai un editor bun, cum multe facilitati, indiferent de limbajul in care programezi. De exemplu, in php, Netbeans e minunat. In autoit, scite e excelent, cu toate limitarile limbajului, Culmea, in cazul meu, sharpdevelop a functionat mai bine decat visual studio express.
Pentru orice alta eventualitate sau in lipsa celor de mai sus folosesc notepad++ care epentru mine e unul din programele pe care le am pe toate calculatoarele.

[Manu]

Asadar, e 3 la 1 pentru utilizarea acoladei la sfarsit de rand.
Oare care e motivul pentru care cei mai multi se orienteaza spre utilizarea acestui stil? Sa fie vorba de economia randurilor de cod? Vizual sa fie mai putin de derulat in sus si in jos?
Intr-un limbaj Basic-like avem:
if ... then
Asta ar veni logic in sprijinul utilizarii acoladei la sfarsit de rand, nu se mai poate pune problema avantajului ca se pot urmarii mai usor delimitarile blocurilor de cod.
Logic ar fi sa utilizam acolada la inceput de rand, nu vad nici un motiv foarte clar pentru a face altfel, cu ea la sfarsit nu poate fi vorba de o logica in plus sau de o mai mare simetrie.

Cand spunem ca un program are x numar de linii de cod, luam in calcul si acoladele singure si randurile libere?
Obisnuiesc sa spun ca jocul meu de table are vreo 10000 linii, dar daca as pune acolada la sfarsit, acolo inca mergeam cu ea pe rand nou, ar avea considerabil mai putine.
Pare pana laurma foarte relativ numarul de linii de cod ale unui program, depinde deja de prea multi factori ce tin strict de forma.

[IonPop]

"Eu mi-am modificat destul de mult stilul in functie de limbajul folosit.".

In mod evident limbajul in care programam mai mult ne influenteaza stilul preferat, dar cred ca este recomandat ca pentru fiecare limbaj sa folosim stilul recomandat pentru el, mai ales daca codul sursa ar putea fi util si altora.

"Ca fapt divers eu folosesc SharpDevelop in loc de Visual Studio Express.".

Este acum accesibil SharpDevelop pentru Jaws? Eu l-am testat mai demult, dar tin minte ca nu l-am gasit prea accesibil.

"De exemplu, in php, Netbeans e minunat.".

Netbeans este accesibil pentru Jaws?

"Pentru orice alta eventualitate sau in lipsa celor de mai sus folosesc notepad++ care epentru mine e unul din programele pe care le am pe toate calculatoarele.".

Aa, acum inteleg.
Daca poti folosi Notepad++ care este un editor excelent, inseamna ca nu ai nevoie de Jaws.
Notepad++ este singurul editor in care am gasit aproape toate facilitatile oferite de TextPad, dar in plus suporta mult mai bine Unicode, asa ca probabil as folosi si eu acest editor daca ar fi accesibil.

[IonPop]

"Asadar, e 3 la 1 pentru utilizarea acoladei la sfarsit de rand.".

Asta nu prea are importanta. Daca dintre noi doar Vortex are aceasta preferinta nu inseamna ca este o metoda mai putin buna. Fiecare prefera varianta cea mai simpla si mai productiva pentru el si este absolut neimportant daca milioane de alti programatori au alte preferinte.

"Oare care e motivul pentru care cei mai multi se orienteaza spre utilizarea acestui stil? Sa fie vorba de economia randurilor de cod? Vizual sa fie mai putin de derulat in sus si in jos?".

Este drept ca si eu am intalnit de mult mai multe ori acolada la sfarsit de linie, dar fara studii stiintifice nu putem spune cu siguranta ca una dintre variante este mai folosita.
Cred ca si in acest caz preferintele sunt influentate de recomandarile de stil pentru diverse limbaje, de facilitatile oferite de diverse editoare etc.
Eu prefer sa pun acolada la sfarsit din urmatoarele motive:
- Nu ar avea nici o importanta pentru un orb daca s-ar gasi pe aceeasi coloana cu acolada pereche, pentru ca vizual nu ar face sa apara codul mai clar.
- Se face economie de un rand si nu mai trebuie sa apas inca o data in plus sageata in jos degeaba.
- Un lucru foarte important este faptul ca daca pun acolada pe un rand nou, dupa ce apas sageata in jos, aud ca pe acel rand este o acolada, dar nu stiu daca la inceput de rand, sau dupa nu stiu cate caractere, iar eu folosesc de foarte multe ori comenzile de a sari de la o acolada la acolada pereche, sau de selectie a intregului bloc, asa ca trebuie apoi sa tot misc sagetile stanga dreapta ca sa ajung inaintea acelei acolade si astfel pierd timp. Daca este la sfarsit de rand stiu ca trebuie doar sa apas tasta end urmata de sageata stanga. intotdeauna.
- Imi place sa o pun la sfarsit de rand si fiindca acest mod se practica in multe alte cazuri, nu doar pentru definirea functiilor, de exemplu atunci cand definesc un hash (sau dictionar, sau matrice asociativa). Atunci pot scrie ceva de genul:

$variabila = {
foo => 1,
bar => 2,
};

Nu cred ca am vazut niciodata sa puna cineva acolada pe un rand nou, ca:

$variabila =
{
foo => 1,
bar => 2,
};

"Intr-un limbaj Basic-like avem:
if ... then
Asta ar veni logic in sprijinul utilizarii acoladei la sfarsit de rand, nu se mai poate pune problema avantajului ca se pot urmarii mai usor delimitarile blocurilor de cod.".

In Bash se pune de obicei pe un rand nou, ceva de genul:

if [ $variabila ]
then
#codul care se executa
fi

Pentru a se pune pe un singur rand trebuie adaugat punct si virgula, cam cum trebuie sa se foloseasca si in Python cand se pun mai multe expresii pe acelasi rand:

if [ $variabila ]; then

Este totusi adevarat ca chiar daca necesita acel punct si virgula in plus, care face ca programul Bash sa arate si mai urat decat este, de foarte multe ori se prefera aceasta varianta cu "then" la sfarsit de linie, tocmai fiindca arata cam ciudat acel "then" singur pe linie.

"Logic ar fi sa utilizam acolada la inceput de rand, nu vad nici un motiv foarte clar pentru a face altfel, cu ea la sfarsit nu poate fi vorba de o logica in plus sau de o mai mare simetrie.".

Sigur ca ar fi mai logic, doar ca nu o logica legata de programare, ci logic doar fiindca ar fi normal sa se afle pe aceeasi coloana cu acolada pereche, nu una sa fie la sfarsit de rand iar alta la inceput sau indentata cu nu stiu cate spatii.
Doar ca acest lucru nu are o valoare prea mare, si utilizarea ei la sfarsit de linie este mai simpla.
Ai vazut ca in Python nici nu se mai folosesc acolade, si totusi codul este clar datorita indentarii, la fel ca in alte limbaje.

"Cand spunem ca un program are x numar de linii de cod, luam in calcul si acoladele singure si randurile libere?".

Depinde daca esti platit in functie de numarul de linii scrise.
Eu de obicei cand ma refer la numarul unei linii intr-un program, ma refer la numarul absolut, cu toate liniile indiferent daca sunt goale sau nu, fiindca numerotarea aceasta este utila in programare. Daca apare o eroare, mi se va spune numarul liniei in care a aparut, indiferent daca liniile anterioare sunt goale sau daca contin cod.
Daca vrem sa estimam asa intr-o discutie cate linii de cod are un program, putem sa nu tinem cont de liniile cu o singura acolada, sau cu comentarii, sau liniile goale (in functie de interes, adica daca vrem sa aratam ca programul nostru este mai mare sau mai mic).

"Obisnuiesc sa spun ca jocul meu de table are vreo 10000 linii, dar daca as pune acolada la sfarsit, acolo inca mergeam cu ea pe rand nou, ar avea considerabil mai putine.
Pare pana laurma foarte relativ numarul de linii de cod ale unui program, depinde deja de prea multi factori ce tin strict de forma.".

Intrebarea este: Ai fi mai multumit daca codul tau sursa ar fi mai mic de 10000 de linii?
Ca atunci poti face o inlocuire in editor "\n{\n" cu " {\n" sau similar, si ai avea parte de multumire instant.
Daca vrei sa aiba mai multe linii, poti sa lasi linii goale intre functii si blocuri de cod si vei fi de asemenea multumit de isprava.

[Manu]

Eu nu as fi mai multumit nici asa, nici asa, dar ma gandeam cum sa raspund, in caz ca as fi intrebat cate linii de cod are un astfel de joc.

Eu stiu ca toate acestea nu conteaza, tin strict de forma, dar topicul acesta este in special despre forma.

[IonPop]

Pai... cu aproximatie. Este important de stiut daca un program are cam 100 de linii, sau cam 1000 de linii, cam 4000 de linii, sau 10000 de linii, dar nu este prea important de stiut daca are 10000 sau 10123, ori daca are 100 de linii sau 102.