Războaiele religioase pe tema formatării codului nu se potolesc printre programatori. Una dintre cele mai presante întrebări pe această temă este cum să indentați și să aliniați în codul sursă al programelor - file, spații sau unul - unul, iar celălalt - celălalt? Fiecare opțiune are cu siguranță avantajele și dezavantajele sale.

Conform observației mele, printre programatorii experimentați, în majoritatea cazurilor, susținătorii spațiilor încă câștigă, iar argumentul decisiv aici este uniformitatea vizuală a liniilor aliniate, indiferent de setările programului fiecărui programator individual. Și preferă să cadă de acord asupra numărului de spații din indentare în cadrul echipei. Ceea ce îi împiedică să cadă, de asemenea, de acord cu privire la dimensiunea filei nu este clar :)

Probabil, relevanța utilizării spațiilor apare dacă programatorii nu au convenit asupra dimensiunii „filei”, dar sunt gata să lucreze cu codul celuilalt care are indentări diferite. În acest caz, codul și comentariile nu se vor accesa cu crawlere și pentru a menține un aspect atât de stabil, nu va trebui să comutați setările editorului de fiecare dată. Problema în acest caz va apărea numai la îmbinarea blocurilor de cod scrise de diferiți programatori într-un singur fișier.

Diferențe în comportamentul spațiilor și al filelor

Luați în considerare următoarea bucată de cod ilustrativă:

Dacă (mStatus != Status.PENDING) ( comutați (mStatus) (case RUNNING: throw new IllegalStateException("Nu se poate executa sarcina: " + "sarcina este deja în execuție."); case FINISHED: throw new IllegalStateException("Nu se poate executa sarcina. : " + "sarcina a fost deja executată " + "(o sarcină poate fi executată o singură dată)"); ))

Putem vedea că blocurile de mesaje text sunt ușor de citit, deoarece începutul fiecărei linii este aliniat la stânga. Când toate indentările (atât codul, cât și alinierea) sunt făcute cu spații, atunci blocurile de text vor fi întotdeauna aliniate, pe orice computer și în orice editor de cod sursă (la urma urmei, la scrierea codului sursă, un font monospațiat cu spații de aceeași lățime întrucât caracterele sunt folosite în mod tradițional). Dar dacă dimensiunea indentării este neobișnuită pentru un alt programator, el nu o va putea schimba pur și simplu.

Dacă ne aliniem nu cu spații, ci cu file, atunci noi înșine vom obține același aspect, dar pentru un alt programator al cărui editor este configurat pentru un alt raport de tabulare, de exemplu, nu 4, ca al nostru, ci 8, liniile se vor deplasa foarte la dreapta și cu un raport de file de 2 - la stânga. În același timp, cele doua rânduri ale mesajului text se vor strecura inevitabil. Același lucru se va întâmpla cu alinierea comentariilor la sfârșitul liniilor de cod. Nu vor mai fi frumos aliniați la stânga pe tot parcursul unui bloc care are diferite niveluri de cuibărit.

O opțiune intermediară se numește crearea de indentări - tabulare și aliniere - o metodă combinată. Alinierea începe cu tab-uri, iar când se atinge nivelul liniei anterioare, cu spații. Dezavantajul acestei metode este complexitatea relativă a acestei metode și potențiala confuzie - la urma urmei, fără a permite vizualizarea caracterelor de control, nu este imediat clar unde sunt filele și unde sunt spațiile. De asemenea, nu este clar cum se vor comporta atunci când sunt copiate în alte locuri din cod.

Mai mult, metoda descrisă mai sus nu vă va scuti de alinierea greșită a comentariilor la sfârșitul rândurilor. Și nu toți programatorii care vă vor edita ulterior codul vă vor înțelege sau accepta ideea.

Deci, care este modul corect de a vă formata codul - cu spații sau file? Sau poate ambele? Să încercăm să ne dăm seama.

Istoria tabulării - fapte interesante

O scurtă excursie în istorie. Tabularea (tabularea orizontală) a fost introdusă inițial în mașinile de scris mecanice pentru comoditatea creării de tabele și a fost, de asemenea, folosită pentru a crea indentarea paragrafelor. Nu avea o dimensiune rigidă. Înainte de muncă, utilizatorul însuși setează opritoarele de care avea nevoie folosind un mecanism special. La fel se poate face acum și în MS Word. Ca urmare, prin apăsări succesive ale tastei Tab (desemnată ca ←), căruciorul, sub acțiunea unui arc, s-a deplasat automat spre stânga de-a lungul tuturor pozițiilor setate anterior, deplasând astfel zona de intrare la dreapta.

Când a venit vremea tehnologiei electronice, pentru a nu reinventa roata, au început să o facă după imaginea și asemănarea mașinilor de scris. Mai mult, la început această tehnică nu era cu mult diferită de ei. De exemplu, teletipul era de fapt o simbioză între telegraf și mașina de scris. Prin urmare, dezvoltatorii săi au convertit pur și simplu toate cheile și alte elemente (întoarcerea căruciorului, întoarcerea căruciorului la o nouă linie și, dintr-un motiv oarecare, chiar semnalul pentru atingerea sfârșitului liniei) în coduri ASCII. Tasta Tab a primit un cod de 9, dar din moment ce emularea mecanismului pentru setarea tabulatorilor personalizate a fost dificilă, au decis să o rezolve pur și simplu.

De ce alegerea dimensiunii fixe a filei a căzut pe 8 spații familiare? De regulă, mașinile de scris aveau o lungime de rând de 80 de caractere. Teletipurile, folosite și în primele computere pentru a scoate informații, deoarece erau moștenitorii mașinilor de scris. Chiar și pe cărțile perforate, informațiile au început să fie stocate în rânduri de 80 de caractere. Astfel, mașinile de scris stabilesc un anumit standard pentru lungimea liniei.

Deoarece tabularea a fost folosită în principal pentru a crea coloane de tabel, dimensiunea cea mai convenabilă nu ar trebui să fie mai mică decât diferența de lungime a cuvintelor cele mai comune dacă sunt scrise într-o coloană (astfel încât pentru a trece la următoarea coloană nu ar fi necesar să faceți un număr diferit de tabelări). În același timp, această dimensiune ar fi trebuit să permită numărul maxim posibil de coloane. A treia condiție este ca dimensiunea să se încadreze în lungimea liniei de 80 de caractere de mai multe ori.

Conform ultimei condiții, dezvoltatorii aveau de ales dintre următoarele cinci opțiuni reale: 4, 5, 8, 10 și 16. Primele două opțiuni nu erau foarte convenabile, deoarece diferența dintre lungimile cuvintelor engleze depășea adesea aceste valori. . Indentația de 16 caractere părea excesiv de mare, a redus capacitatea de utilizare a instrumentului și a limitat sever numărul de coloane din tabele. Era de ales între 8 și 10 caractere.

Valoarea a 8 caractere a fost prima valoare care a îndeplinit condiția de diferență a lungimii cuvântului. În plus, a fost singura care a îndeplinit a doua condiție – construirea unui număr maxim posibil de coloane. Opțiunea cu o filă de 10 caractere a părut nerezonabil de risipă și a dat doar 8 coloane, ceea ce ar putea restrânge oarecum domeniul de aplicare al filei. În plus, numărul 10 pentru numărul maxim de coloane arăta mai impresionant din punct de vedere psihologic. Toate aceste motive, aparent, i-au înclinat pe dezvoltatorii de teletip să tabuleze exact 8 caractere.

Câteva cuvinte despre indentarea paragrafelor, deoarece se apropie și de subiectul nostru. Conform OST 29.115-88, la imprimarea pe mașini de scris, indentarea paragrafului trebuie să fie egală cu trei linii, dar este permisă utilizarea unei indentări de cinci linii. În plus, este prescris să plasați 29 (+-1) linii pe o pagină (care corespunde aproximativ la o distanță și jumătate pe o mașină de scris). Cerința pentru o indentare de 3 bătăi la un interval de o jumătate și jumătate este destul de ciudată, iar mai jos voi explica de ce.

În aspectul tipografic, indentarea paragrafului este egală cu o dimensiune a fontului și jumătate, adică, aproximativ vorbind, dimensiunea liniei verticale (adică, distanța de la partea de jos a unei linii la partea de jos a alteia), înmulțită cu 1,5. Deoarece în aspectul tipografic jumătatea de spațiu nu este folosit aproape niciodată, iar liniile urmează imediat una după alta, paragraful corect în acest caz este aproximativ egal cu cele trei caractere din mijloc ale alfabetului chirilic.

Probabil, compilatorii OST 29.115-88, fără a intra în detalii ale tipografiei, au luat această valoare ca o constantă pentru fonturile fixe monospațiu ale mașinilor de scris și, în același timp, au stabilit o distanță între rânduri și jumătate ca standard, deoarece cu un monospațiu font și calitate scăzută de imprimare, spațierea unică arăta foarte prost.

Dar spațierea crescută, bazată pe reguli tipografice, necesită, de asemenea, o indentare sporită a paragrafelor. La momentul în care a fost elaborat standardul, acest offset crescut de 5 bătăi era deja utilizat pe scară largă în mod intuitiv. Aparent, acesta este motivul pentru care indentația crescută de facto a 5 lovituri a fost legalizată în standard.

Apropo, mașinile de scris au influențat nu numai numărul de coloane din modul text al monitorului, ci și dimensiunea verticală de 30 de linii. La urma urmei, atunci când tipăriți cu intervale de unu și jumătate, exact câte linii încap pe o coală!

Viziune strategică a rezolvării problemelor

Desigur, este cel mai logic să indentați nivelurile de imbricare a codului cu file, pentru că asta a fost destinat inițial - pentru a începe tipărirea textului din diferite poziții. În plus, în era computerului, caracterul tabulator era foarte potrivit pentru rolul unui divizor logic. Numărul de caractere de tabulatură consecutive a indicat clar nivelul de imbricare logică.

De aici devine evident că spațiile sunt o cârjă necesară. La urma urmei, din păcate, dimensiunea filei pentru fiecare limbă nu este strict fixă. Programatorii trec de la o limbă la alta, păstrând adesea tradițiile limbajului precedent, precum și preferințele acestora. În aceste condiții, spațiile sunt o măsură pentru a fixa aspectul sursei și a proteja împotriva răspândirii formatării acesteia.

Soluția ar putea fi să forțați ca dimensiunea filei să fie legată de limbajul de programare. Experții în ergonomie ar putea defini în mod clar dimensiunile de tabulatură cele mai convenabile pentru sintaxa fiecărei limbi, iar această dimensiune ar putea fi fixată în compilator, emitând avertismente persistente atunci când este încălcată.

Deoarece nu putem influența strategia de rezolvare a problemei, suntem nevoiți să ieșim cumva tactic în cadrul realității existente. Pentru a găsi opțiunea potrivită pentru dvs., să ne uităm puțin mai detaliat la problemele spațiilor și filelor.

Probleme de spațiu

Când un programator deschide codul sursă al altcuiva cu indentare și aliniere folosind spații, dar această indentare se dovedește a fi incomodă pentru el, el, de fapt, nu poate face nimic pentru a-l aduce într-o formă convenabilă fără a efectua niște manipulări complexe.

O altă problemă cu spațiile albe sunt erorile în care unul dintre spațiile de indentare este eliminat accidental și rămâne nedetectat. Când treceți la o linie nouă, editorul va crea automat aceeași indentare eronată ca și linia anterioară, iar această eroare se poate răspândi pe mai multe linii de cod. Corectarea acestei erori va necesita ceva timp petrecut cu operațiuni plictisitoare, pur mecanice.

În plus, pentru a elimina excesul de indentare, în loc de apăsarea obișnuită pe Backspace, trebuie să apăsați combinația de taste Shift+Tab. Dar aceasta, desigur, este o chestiune de obicei.

Probleme cu filele

Tab are o singură problemă - atunci când dimensiunea se schimbă, alinierea comentariilor și a altor elemente aliniate este întreruptă, deși, de regulă, nu sunt atât de multe încât să îngreuneze citirea sursei, iar corectarea lor nu este atât de dificilă. .

În plus, nimeni nu te deranjează să activezi pur și simplu în editor dimensiunea filei care a fost setată de autor, reducând aspect la ce ar fi dacă codul sursă ar fi pur și simplu formatat cu spații. Mai ales pentru astfel de cazuri, unii programatori scriu dimensiunea recomandată a filei în comentariul de sus la cod - în opinia mea, o decizie foarte corectă.

Concluzii

În primul rând, voi spune câteva cuvinte despre dimensiunea indentărilor ca atare. Pentru cele mai comune limbaje de programare, dimensiunea ideală a indentării este de exact 4 caractere. De ce anume? Pentru că s-a dovedit deja că majoritatea surselor sunt formatate în acest fel, iar ajustarea fină la „idealul” subiectiv de 3 sau 5 caractere își pierde sensul.

Indentarea ocazională de 8 caractere face ca codul să fie întins inutil pe orizontală și nu lasă loc pentru comentarii în partea dreaptă. În plus, datorită excesului de mărime a indentării pe lungimea operatorilor, în treptele scării de imbricare sunt expuse goluri între operatori și operanzi, care creează goluri vizuale, care nu avantajează lizibilitatea codului.

De asemenea, o soluție nu foarte bună este să folosiți indentarea cu două caractere, care apare și. În acest caz, deși spațiul de lățime este economisit, devine destul de dificil să navighezi pe nivelele de cuibărit, ceea ce provoacă inevitabil oboseală accelerată.

Dacă programatorii țin de media de aur a 4 caractere, atunci dezbaterea dintre susținătorii spațiilor și filelor va deveni irelevantă. Între timp, putem da următoarele recomandări:

1. Utilizați indentări de dimensiune standard de facto. Pentru Java, Pascal, C, C++ etc. Standardul de facto este de 4 caractere de indentare, indiferent cât de mult am dori să folosim o dimensiune diferită.
2. Dacă se urmărește punctul 1, atunci absolut nu contează ce folosiți pentru indentare. Dacă le faci spații, va fi bine - codul tău va arăta ușor de citit peste tot și nimic nu se va accesa cu crawlere. Alți programatori se vor obișnui cu formatarea corectă atunci când vă citesc codul. Dacă le indentați cu file, atunci va fi și mai bine - veți oferi altor programatori o alegere - activați dimensiunea corectă a filei în editor și citiți codul formatat corect sau citiți-l cu indentările obișnuite, dar comentarii târâtoare și individuale linii în care a fost aplicată alinierea.
3. Alegerea de la punctul 2 poate fi făcută în funcție de modul în care va fi utilizat codul dvs. în viitor. Dacă blocurile sale vor fi inserate în codul altcuiva, atunci este cu siguranță logic să selectați tabularea pentru a fi mai ușor pentru inserator să ajusteze formatarea. Dacă sursa este destinată publicării pe Internet, unde fila este fie consumată, fie fixată la 8 caractere, atunci puteți selecta spații pentru a elimina pasul suplimentar de pregătire a sursei pentru publicare. Dacă organizația dvs. a stabilit deja anumite reguli de formatare, atunci nu mai aveți de ales :)

Dacă, indiferent de ce, ești hotărât să folosești propriul tău număr de caractere în indentare, atunci utilizarea spațiilor și a tabulatorilor va depinde în mod necesar de modul în care codul tău este utilizat ulterior de alți programatori.

Dacă pentru întreținere regulată în ceea ce privește remedierea erorilor, probabil că este mai bine să folosiți spații. Codul dvs. nu va fi lucrat mult timp, iar dacă este bine formatat, atunci nimeni nu va trebui să schimbe în mod special dimensiunea indentărilor.

Dacă codul dvs. va fi utilizat în mod activ de către alți programatori, inserându-l în programele lor sau pur și simplu dezvoltând proiectul dvs., atunci este mai bine să utilizați file. În acest caz, va fi mai ușor pentru un alt programator să adapteze tipul codului dvs. la standardul acceptat într-un anumit grup.

Dacă aveți unul, dar aveți nevoie de altul

Există un editor atât de minunat - Notepad++. În ea, înlocuirea file-urilor cu spații și invers se face cu un singur clic, realizat în secțiunea din meniul „Editare → Operații cu spații”. Folosesc acest editor pentru a transcrie bucăți de cod cu file destinate publicării pe un blog, deoarece acesta din urmă schimbă automat un caracter de filă cu un spațiu, ceea ce este inacceptabil.

Concluzie

Mulți își pot pune întrebarea, ce a ales autorul acestui articol pentru sine? Și a ales o dimensiune a filei de 4 spații familiare. Nu am găsit un motiv suficient de bun pentru a folosi spații, astfel încât codul meu să fie vizibil pentru cineva care nu s-a hotărât să seteze indentarea editorului de cod la standardul de facto de 4 caractere.

În ceea ce privește Notepad-ul de la Windows, care nu are o setare pentru dimensiunea filei, și alți editori similari care forțează filele să fie de 8 caractere, nu îmi pot imagina un motiv pentru care un programator mi-ar deschide codul în ele, în timp ce deja de mult timp Toate sistemele de operare au editori specializați convenabil pentru codul sursă.

Să lucrezi într-un notepad nu este grozav. Este grozav să lucrezi într-un editor hexadecimal :)

Pentru dezvoltatorii curioși, problema folosirii filelor și spațiilor pentru a formata codul rămâne încă relevantă. Pot fi interschimbate: de exemplu, 2 spații pe filă sau 4? Dar nu există un standard unic, așa că uneori apar neînțelegeri între dezvoltatori. În plus, diferitele IDE-uri și compilatorii lor gestionează filele în mod diferit.

Soluția problemei este de obicei un acord privind regulile de formatare în cadrul proiectului sau al limbajului de programare în ansamblu.

O echipă de dezvoltatori de la Google a examinat proiecte din depozitul Github. Ei au analizat codul scris în 14 limbaje de programare. Scopul studiului a fost de a identifica raportul dintre file și spații - adică cel mai popular mod de formatare a textului pentru fiecare limbă.

Implementarea

Pentru analiză, am folosit un tabel existent în care sunt înregistrate numele depozitelor Github.

Să ne amintim că în urmă cu aproximativ două luni, tot codul Github open source a devenit disponibil sub formă de tabele BigQuery.

Cu toate acestea, nu toate depozitele au fost selectate pentru analiză, ci doar primele 400 de mii de depozite cu cel mai mare număr de stele pe care le-au primit pentru perioada ianuarie-mai 2016.

Din acest tabel, au fost extrase fișiere care conțin cod în cele 14 cele mai populare limbaje de programare. Pentru a face acest lucru, extensiile fișierelor corespunzătoare au fost specificate ca parametri ai interogării sql - .java, .h, .js, .c, .php, .html, .cs, .json, .py, .cpp, . xml, .rb, .cc, .go.

SELECT ID a.id, dimensiune, conținut, binar, copii, sample_repo_name , sample_path FROM (SELECT id, FIRST(cale) sample_path, FIRST(repo_name) sample_repo_name FROM WHERE REGEXP_EXTRACT(cale, r"\.([^\.]* )$") IN ("java","h","js","c","php","html","cs","json","py","cpp","xml", "rb","cc","go") GROUP BY id) a JOIN b ON a.id = b.id

Au trecut 864,6 s, au fost procesate 1,60 TB

Solicitarea a durat destul de mult pentru a fi finalizată. Acest lucru nu este surprinzător, deoarece a fost necesar să se efectueze o operație de îmbinare pe un tabel de 190 de milioane de rânduri cu un tabel de 70 de milioane de rânduri. Au fost procesate un total de 1,6 TB de date. Rezultatele interogării sunt disponibile la această adresă.

Tabelul conține fișiere fără duplicatele lor. Mai jos este numărul total de fișiere unice și dimensiunea lor totală. Fișierele duplicat nu au fost incluse în analiză.

După aceea, nu a mai rămas decât să genereze și să lanseze cererea finală.

SELECT ext, tabs, spaces, counttext, LOG((spaces+1)/(tabs+1)) lraport FROM (SELECT REGEXP_EXTRACT(sample_path, r"\.([^\.]*)$") ext, SUM( tab-uri best="tab"), SUM(best="space") spații, COUNT(*) context FROM (SELECT sample_path, sample_repo_name, IF(SUM(line=" ")>SUM(line="\t"), „space”, „tab”) WITHIN RECORD cel mai bun, COUNT(line) WITHIN RECORD c FROM (SELECT LEFT(SPLIT(conținut, „\n”)), 1) line, sample_path, sample_repo_name FROM HAVING REGEXP_MATCH(line, r"[ \t]")) AVÂND c>10 # cel puțin 10 linii care încep cu spațiu sau tab) GROUP BY ext) ORDER BY context DESC LIMIT 100

Au trecut 16,0 secunde, 133 GB procesați

Analiza fiecărei linii de 133 GB de cod a durat 16 secunde. Același BigQuery a ajutat la atingerea unei astfel de viteze.

Cel mai adesea, filele se găsesc în C, iar spațiile se găsesc cel mai adesea în Java.

Deși pentru unii raportul dintre anumite simboluri de control nu contează, iar dezbaterile pe această temă par exagerate. Acest lucru nu contează nici pentru unele IDE-uri, care stochează file ca un număr de spații. Există și IDE-uri în care acest număr poate fi configurat manual.

Cu ceva timp în urmă, această problemă a fost jucată în seria „Silicon Valley”. Tipul și fata nu au fost de acord cu privire la problema formatării. Drept urmare, vechiul holivar nu numai că a dus la neînțelegeri profesionale, ci a creat și probleme în relațiile lor personale.

Unul dintre caracteristicile unui stil bun de programare este consecvența - cu cât sunt mai puține surprize, cu atât mai bine. Consecvența face un program mai ușor de citit, în primul rând prin reducerea distragerilor. De asemenea, ghidează privirea cititorului, de exemplu, consistența în locația unei funcții sau conectarea fișierelor le face mai ușor de găsit în viitor. De asemenea, facilitează rezolvarea problemelor de stil, ajutând cititorul să se obișnuiască mai ușor.

Claritatea codului

Un stil bun este necesar pentru a vă asigura că programul dvs. este clar, ușor de înțeles și ușor de schimbat. Dacă aveți îndoieli, alegeți cea mai înțeleasă tehnică pentru problemă. Amintiți-vă că tot ce scrieți, probabil va trebui să recitiți. Faceți-vă viitorul mai ușor și obțineți claritate imediat.

Spații și formatare

Spațiile albe pot reduce tensiunea asupra ochilor cititorului. Deoarece compilatorul ignoră spațiile, sunteți liber să le plasați oriunde și să formatați codul cu spații după cum doriți. Dacă o faci cu înțelepciune, îți va fi de ajutor.

Spațiile sunt folosite pentru a formata indentarea, spațiul în jurul instrucțiunilor, semnăturile funcției și plasarea argumentelor funcției. Desigur, acestea nu sunt toate locurile în care sunt folosite spațiile albe, dar ar trebui să vă ofere o idee despre locurile în care spațiul alb poate fi folosit pentru a îmbunătăți lizibilitatea.

Indentare

Dacă nu vă indentați deja codul, o veți face în curând. Acest lucru este absolut necesar deoarece vă va ajuta să găsiți rapid liniile de control necesare ale codului sau să găsiți erori în el. Ar trebui să indentați fiecare bloc de cod:

Dacă (adevărat) (​// bloc de cod)

Stiluri de paranteze

Există multe modalități de a indenta codul și multe dintre ele depind de locul în care plasați parantezele. Unii oameni preferă stilul folosit mai sus. Unii oameni preferă stilul prezentat mai jos:

Dacă (adevărat) (​// bloc de cod)

Există și alte stiluri:

Dacă (adevărat) (​// bloc de cod)

Ce stil de bretele alegeți depinde de dvs., deși recomand să folosiți același stil de bretele pentru toți cei care lucrează la același proiect. Oricum, există argumente pentru fiecare stil. Este bine să folosești un stil de paranteză care să îți permită să încadrezi cât mai mult cod pe ecran, dar consecvența este la fel de importantă.

Lățimea indentării

Cât de mult doriți să indentați este o chestiune de preferință personală - în orice caz, în general, cel mai bine este să alegeți o dimensiune suficient de mică pentru ca codul să se potrivească pe un ecran. Consider că orice lățime de indentare între 2 și 8 este rezonabilă și lizibilă, deși am descoperit că mai mult de patru spații pentru indentare pot duce la linii prea lungi.

În general, cea mai bună soluție pentru liniile prea lungi este reducerea complexității codului sau cel puțin extragerea unei anumite funcționalități în funcții separate. Acest lucru va reduce numărul de niveluri de indentare și poate face codul mai lizibil (dacă este făcut corect).

File și spații

Există oarecum o controversă cu privire la utilizarea filelor sau a spațiilor. Rețineți că acest lucru nu este același lucru cu a întreba dacă indentați cu spații sau file. Majoritatea oamenilor lasă editorul de text să descopere acest lucru pentru ei (sau aleg să convertească filele în spații).

Adevărata problemă cu file și spații este ceea ce se întâmplă atunci când cineva deschide codul tău. Puteți seta file pentru orice număr de coloane, iar persoana care vă deschide codul poate avea o lățime diferită a filei. Acest lucru poate fi dificil chiar și cu un cod bine formatat. Folosirea doar a spațiilor rezolvă această problemă, deoarece totul va apărea la fel.

Uneori, un formatator de cod decent poate fi găsit în editor de text, poate ajuta la atenuarea acestei probleme prin reformatarea codului. De asemenea, puteți modifica propriile setări pentru a afișa codul corect (deși acest lucru nu este foarte frumos).

Cea mai bună soluție, dacă decideți să utilizați file, este să fiți foarte atenți cu ce le folosiți. Adevărata problemă, de fapt, apare atunci când filele sunt folosite nu numai pentru indentare, ci și ca o modalitate rapidă de a muta patru sau opt caractere la dreapta. De exemplu, să ne uităm la următorul cod:

Dacă (lung_term_one && long_term_two) ( // cod )

Dacă a doua condiție a fost formatată folosind o filă indentată patru spații urmată de un spațiu, atunci când este deschisă într-un alt editor cu o lățime a filei de opt spații, codul va arăta urât:

If (long_term_one && long_term_two) ( // cod în corpul instrucțiunii de selecție )

Dacă au fost folosite spații pentru formatare, codul se va afișa corect:

If (long_term_one && long_term_two) ( // dacă codul declarației)

Utilizarea incorectă a spațiilor

Câte spații folosești depinde de tine. Dar, merită să fii conștient de unele probleme. În primul rând, cu cât este mai mult spațiu alb care ajută la evidențierea logicii programului dvs., cu atât mai bine. Dar nu vrei ca golurile tale să te dezorienteze. S-ar putea să nu vă încurce în acest moment, dar vă poate deruta pe dvs. în viitor sau pe oricine altcineva care vă citește codul. Cum arată formatarea proastă?

Dacă(adevărat)++i;

++j;

Indentația ne spune că cele două expresii se vor declanșa atunci când instrucțiunea condiționată este executată, dar nu asta se întâmplă de fapt. Când urmăriți o eroare de sintaxă pe sute sau mii de linii de cod, ajungeți doar să treceți cu ușurință codul în loc să verificați cu atenție fiecare linie. Cu cât vă este mai ușor să revizuiți codul și să alegeți detaliile importante, cu atât mai repede puteți găsi erori care se strecoară neobservate. Ca și în acest exemplu, doar prima instrucțiune aparține corpului instrucțiunii if.

Există momente când nu doriți să schimbați stilurile de dragul unui singur element sau trebuie să inserați mai multe spații în text din motive de estetică sau stil de formatare a textului. Și aici apare întrebarea: „Cum să adăugați spațiu alb în HTML, astfel încât textul să fie afișat frumos și, în același timp, să evitați redundanța codului?” Pentru a face acest lucru, să ne uităm la tipurile de spații și la exemplele de utilizare a acestora în codul HTML.

Spațiu HTML care nu se sparge În cazurile în care nu trebuie să separați părți ale textului unele de altele, vă va ajuta spatiu de nerupere

, al cărui cod arată astfel:

Acesta este așa-numitul „spațiu fără rupere”.

Exemple de utilizare a spațiului neîntrerupt:

Etc. pentru că E. Veltistov 11 mii de ruble

Spațiu subțire Codul HTML pe care l-am acoperit mai sus este omniprezent. Dar există momente când un spațiu obișnuit se dovedește a fi prea „mare”. Apoi este înlocuit cu spatiu subtire

 

. Acesta este un spațiu care are un sfert din lățimea fontului utilizat. Un spațiu subțire este indicat după cum urmează:

și este folosit, în cea mai mare parte, pentru a împărți cifrele numerelor, de exemplu, „15.000.000 USD” ar trebui scris astfel:

15.000.000 USD Nota: Este posibil ca spațiul subțire să nu se afișeze corect în versiunile mai vechi ale unor browsere, dar în toate ultimele versiuni

functioneaza grozav.

Alte tipuri de spații în HTML

• Pe lângă cele mai relevante tipuri pe care le-am discutat mai sus, există și altele.
•   - spatiati lungimea literei N;
•   - spatiati lungimea literei M;
• ‌ - caracter fără legătură cu lungimea zero;

15.000.000 USD Dacă trebuie să puneți mai multe spații pe rând, înconjurați textul cu o etichetă

:

 
Creator de site-uri web „Nubex”
Spațiu folosind CSS
Opțiunea de a crea file (indentare) folosind CSS poate fi rezolvată folosind următoarea tehnică:

   Creator de site-uri web „Nubex”
".
Am vrut să răspund la comentarii, dar datorită volumului și dorinței de a fi independent de subiectul inițial, am decis să creez un nou subiect.
Deci, sub tăietură - de ce filele sunt mai bune decât spațiile, cele mai semnificative concepții greșite despre file și cum să le folosești corect.
Să începem cu faptul că majoritatea oamenilor (cel puțin pe Habré) preferă file.
De fapt, lucrul ciudat este că mulți încă nu fac distincția între indentare și aliniere.  Ei bine, aceasta este indentarea: 
pentru (int i = 0; i< 10; i++) {
 if (a[i] == 0)
 do_something(i);
}
 
Și aceasta este alinierea: 
int some_variable = 0;  int v1 = 0;
Prima se poate face atât cu file, cât și cu spații, dar când o faci cu file, fiecare poate ajusta lățimea indentării după propriul gust și nimic nu merge nicăieri, iar a doua - strict cu spații.
IDE-ul are o opțiune Smart Tabs pentru aceasta:
Dacă utilizați filele corect (și anume, doar pentru indentare), puteți modifica cu ușurință dimensiunea filelor fără a încălca stilul dvs. de programare.
2 spatii pe fila: 

5 spații pe filă: 

9 spații pe filă: 
Deci, ce probleme ratam?
1. Fiecare programator poate ajusta lungimea filei după gustul său. Întotdeauna functioneaza in practica.  Când codul este foarte imbricat, puteți seta lățimea filei la două spații, în caz contrar - la patru. 
2. Este mai ușor să lucrați cu biblioteci terțe.  Unele biblioteci acceptă un stil cu o lățime a filei de două spații, altele cu o lățime de patru spații.  Doar folosirea filelor nu impune restricții asupra stilului. 
Voi cita câteva gânduri din subiectul anterior: 
Este dificil să lucrezi cu proiecte care folosesc biblioteci care conțin file în test.  Să presupunem că într-o bibliotecă fila este de 3 caractere, în alta este de 4 caractere.  Și folosești 2 simboluri în proiect.  Ca rezultat, o parte a codului dvs. va fi afișată în editor cu formatare incorectă.

De fapt, în proiectele care utilizează tabularea nu există astfel de probleme - deoarece tabularea este adimensională, dar suportarea simultană a câtorva biblioteci cu dimensiuni diferite ale filelor de spațiu devine problematică, deoarece  Nu mai puteți folosi tab (astfel încât IDE-ul să înlocuiască file cu spații).  Desigur, există o șansă de a rezolva această problemă cu diferite proiecte cu setări diferite, dar aceasta este încă o cârjă și încă îți supără mintea de la diferitele dimensiuni de cuib. 
Este ușor să lași o capră să intre în grădină.  Să presupunem că fila este egală cu 4 spații.  Cineva a modificat puțin ceva folosind o dimensiune diferită a filei sau inserând în mod explicit spații.  Totul arăta bine pentru el, dar linia ta de cod va merge undeva.

La fel, tabularea este adimensională.  Această problemă apare numai în proiectele care utilizează spații.  Acolo unde sunt folosite file, acestea pot avea cel puțin 2 sau 10 caractere lățime. 
Trebuie să ajustați în mod constant diverse editori la dimensiunea filei de care aveți nevoie.  Chiar dacă trebuie doar să te uiți la cod fără a edita.  Altfel totul se va prăbuși.  Acest lucru este mai ales incomod atunci când trebuie să faceți ceva cu codul dvs. pe o mașină terță parte.

Să presupunem că deschid Kate pentru a remedia rapid codul dintr-un fișier.  Hopa, dimensiunea filei este de două spații.  Trebuie să intri în configurație.  Și în următorul fișier dintr-o altă bibliotecă sunt patru spații.  Va trebui să folosești un spațiu în loc de o filă pentru indentare, groaznic.  Nu există o astfel de problemă cu filele. 
Complicații suplimentare pentru cei care lucrează simultan cu proiecte în care standardele de codificare necesită indentări diferite.  Dacă standardele necesită utilizarea tabulării, atunci acesta este încă acel dinte mereu dureros.  În cazul spațiilor, iarăși totul este mult mai simplu.

După cum sa discutat mai sus, această problemă există în mod specific cu probleme, și nu cu file. 
În plus, spațiile au astfel de dezavantaje precum imposibilitatea deplasării rapide cu săgețile de la tastatură (clic pe fiecare spațiu, și nu printr-un bloc), posibilitatea de a face o greșeală (punând 3 spații într-un loc în loc de 4, ceea ce distruge mai departe). structura), o creștere a dimensiunii fișierului și mult mai mult.
Concluzie
Spațiile nu au niciun avantaj semnificativ față de file și nu constrângem programatorul într-un cadru și nu îl forțăm să sufere cu file prea mici (sau prea mari) pentru el. 
Principal
Chiar nu contează ce folosești.  Este important să urmăriți ordinea codului dvs. și mereu lipit de același stil.  Porniți afișarea filelor/spațiilor, uneori schimbați dimensiunea filei cu una diferită și treceți-vă ochii prin cod pentru a vă asigura că nu ați introdus spații în loc de file sau file în loc de spații undeva. 
UPD: nota conform comentariilor
Îmi doream de mult să scriu un articol despre file.  Dar nu despre „Tabs VS Spaces”, ci despre cum să folosești corect filele.  Comentariile au confirmat că mulți nu știau despre indentare și aliniere.  Ideea acestui articol nu este deloc că toți cei care folosesc file au dreptate.  Există standarde de codare, există caracteristici de limbă și există preferințe personale. 
Cel mai important lucru este să cunoști regulile de indentare și să le poți folosi.  Și nu amestecați niciodată cele două stiluri.  Notă - nu „nu amestecați file și spații”, dar nu amestecați cele două stiluri. 
Personal, recomand să folosiți abordarea descrisă în subiect, dar numai dacă standardele codului cu care lucrați nu implică ceva diferit.