Eu folosesc două spații (atunci când lucrez singur) pentru că îmi place să am textul aliniat așa cum vreau eu.
Când lucrez cu mai mulți sau când preiau proiecte legacy urmez standardul folosit până atunci.
Intotdeauna spatii. Numarul lor depinde de limbaj si de coding standards (limbaj, framework etc - de exemplu, in Ruby indentez cu 2 spatii, PHP 4, Objective-C 4).
In afara de vechiul argument cu marimea (ca intr-adevar, daca indentezi cu tab-uri, la un fisier de 1000 de linii o sa ai niste biti in minus) nu e nici unul care sa aiba un sens adevarat.
Plus, argumentul meu suprem: daca folosesti tab-uri pentru indentare, vei folosi negresit spatii pentru aliniere; de ce ai vrea sa combini 2 lucruri diferite cand poti avea absolut totul indentat si aliniat cu spatii?
Exemplu:
// exemplu tab-uri + spatii
enum status {
^Ipublished.=.1;
^Idraft.....=.2;
^Ideleted...=.3;
};
// ^I - tab
// . - space
// exemplu doar spatii
enum status {
....published.=.1;
....draft.....=.2;
....deleted...=.3;
};
// . - space
Am vazut ca faci Ruby most of the time, dar tine cont ca exista coding standards si pentru alte limbaje - php, de exemplu, arata ciudat spatiat cu 2 si daca faci totul ca la carte, urmezi coding standards impuse de limbaj.
Ca sa-ti dau un exemplu clar, daca as face acelasi lucru ca tine as scrie Ruby spatiat cu 4, pentru ca primul coding standard pe care l-am adoptat folosea 4 spatii. Sounds fair?
Fair enough! Dar e aceeasi treaba ca la numarul de spatii:
0 - 80 caractere = awesome
80 - 120 caractere = acceptabil
Ca sa dau un exemplu clar, coding standard-ul de php spune ca soft limit e la 120.
Ma rog, ideea e ca mie mi se pare relevant sa folosesti coding standard-ul fiecarui limbaj pe care-l folosesti si asa ai cele mai putine batai de cap
Codul indentat la doar doua spatii te forteaza sa lucrezi in anumite limite: de exemplu cand incepi sa faci nesting aiurea sau pur si simplu generezi bad code - cu doua spatii se vede ca ceva nu este OK cu ochiul liber pentru ca totul este prea codensat si deja cand incerci sa il citesti numele de var se amesteca. That’s a code smell.
Tab-ul, colegul meu isi poate seta tab width 2 in timp ce eu lucrez cu tab width 4 = toata lumea fericita.
Nu-mi plac spatiile, in special cand trebuie sa le sterg, dar nu fac un caz din asta.
@dakull Mie imi pare tocmai invers. Daca folosesti 4 spatii risti sa te duci mult prea in dreapta daca faci prea mult nesting, si in felul asta vei vedea.
PS: Editorul meu are o setare frumoasa care transforma 2 spatii in tab width 4, deci n-am absolut nici o problema cu cine ce foloseste.
@bogdanconstantinescu Exemplul tau triseaza. Un TAB nu se vede ca un caracter de tipul ^ ci ca 4 spatii.
Tu acolo ai comparat ^(asta e caracter, nu spatiu, tab = … && tab != ^) vs …(4 puncte)
@IonutBajescu Asa-i ca n-ai dat vreodata cat -t file intr-un terminal? Eu am folosit caracterul respectiv (pe care-l foloseste cat) ca sa exemplific amalgamul de TAB (indent) + space (aliniere) intr-un fisier in care se folosesc tab-uri - pentru ca oricum vei folosi spatii intr-un fisier indentat cu tab-uri.
Asa ca sorry, nu mi se pare ca ai inteles ce am vrut eu sa arat.
Eu ma refer ca caracterul folosit nu isi are locul in acest topic.
Pentru ca diferenta dintre tab si space este modificata vizual in exemplul tau, care arata tab-ul ca si cum n-ar fi acolo.
Si da, ai dreptate, s-ar putea ca nici acum sa nu fi inteles ce ai dorit sa spui mai exact.
Hai sa explic pe scurt si foarte simplu de inteles.
Intentare:
TAB:
Folosesti tab pentru indentare
Folosesti space pentru aliniere
SPACE:
Folosesti space pentru indentare si aliniere
Concluzie:
Daca folosesti tab pentru indentare, inevitabil vei folosi space pentru aliniere => fisierul tau e eterogen (codul inconjurat de tab-uri si spatii)
Daca folosesti space pentru indentare vei avea un fisier omogen, codul fiind doar inconjurat de spatii
PS:
Asta e si ideea, tab e un caracter, pe care editorul tau il afiseaza ca 4 spatii, el in sine, e doar un caracter; de fapt, cum l-am prezentat eu acolo e mult mai aproape de realitate decat il “vezi” tu.