Uskonnolliset sodat koodin muotoilusta eivät lannistu ohjelmoijien keskuudessa. Yksi tämän aiheen kiireellisimmistä kysymyksistä on kuinka sisentää ja tasata ohjelmien lähdekoodia - sarkaimet, välilyönnit tai yksi - yksi ja toinen - toinen? Jokaisella vaihtoehdolla on varmasti hyvät ja huonot puolensa.

Havaintoni mukaan kokeneiden ohjelmoijien joukossa useimmissa tapauksissa tilojen kannattajat silti voittaa, ja ratkaiseva argumentti tässä on kohdistettujen linjojen visuaalinen samankaltaisuus, riippumatta kunkin ohjelmoijan ohjelma-asetuksista. Ja he sopivat mieluummin välilyöntien määrästä sisennyksessä joukkueen sisällä. Mikä estää heitä sopimasta myös välilehden koosta, on epäselvää :)

Todennäköisesti välilyöntien käytön merkitys nousee esiin, jos ohjelmoijat eivät ole sopineet "välilehden" koosta, vaan ovat valmiita työskentelemään toistensa koodin kanssa, jolla on eri sisennykset. Tässä tapauksessa koodi ja kommentit eivät koskaan indeksoi, ja näin vakaan ulkonäön ylläpitämiseksi sinun ei tarvitse vaihtaa editorin asetuksia joka kerta. Tässä tapauksessa ongelma syntyy vain, kun yhdistetään eri ohjelmoijien kirjoittamia koodilohkoja yhdeksi tiedostoksi.

Erot välilyöntien ja sarkainten toiminnassa

Harkitse seuraavaa havainnollistavaa koodinpätkää:

If (mStatus != Status.PENDING) ( switch (mStatus) ( case RUNNING: throw new IllegalStateException("Tehtävää ei voida suorittaa: " + "tehtävä on jo käynnissä."); case FINISHED: heittää uusi IllegalStateException("Tehtävää ei voi suorittaa : " + "tehtävä on jo suoritettu " + "(tehtävä voidaan suorittaa vain kerran)"); ) )

Voimme nähdä, että tekstiviestilohkot ovat helppolukuisia, koska jokaisen rivin alku on vasemmalle tasattu. Kun kaikki sisennykset (sekä koodi että tasaus) tehdään välilyönnillä, tekstilohkot tasataan aina, millä tahansa tietokoneella ja missä tahansa lähdekoodieditorissa (lähdekoodia kirjoitettaessa yksivälistetty fontti, jossa on samanleveät välilyönnit kuten merkkejä perinteisesti käytetään). Mutta jos sisennyksen koko on epätavallinen toiselle ohjelmoijalle, hän ei voi yksinkertaisesti muuttaa sitä.

Jos kohdistamme emme välilyönnillä, vaan sarkaimilla, saamme itse saman ulkonäön, mutta toiselle ohjelmoijalle, jonka editori on määritetty erilaiselle taulukkosuhteelle, esimerkiksi ei 4, kuten meillä, vaan 8, rivit siirtyvät huomattavasti oikealle ja välilehden suhteella 2 - vasemmalle. Samanaikaisesti tekstiviestin toiset rivit hiipivät väistämättä ylös. Sama tapahtuu, kun kommentit kohdistetaan koodirivien lopussa. Ne eivät enää ole kauniisti kohdistettu vasemmalle lohkossa, jossa on eri pesämistasot.

Välivaihtoehtoa kutsutaan sisennysten luomiseksi - taulukointi ja tasaus - yhdistetty menetelmä. Tasaus alkaa sarkaimilla ja kun edellisen rivin taso saavutetaan, välilyönneillä. Tämän menetelmän haittapuolena on tämän menetelmän suhteellinen monimutkaisuus ja mahdollinen sekaannukset - loppujen lopuksi ilman ohjausmerkkien visualisointia ei ole heti selvää, missä sarkaimet ovat ja missä välilyönnit. On myös epäselvää, kuinka ne käyttäytyvät, kun ne kopioidaan koodin muihin paikkoihin.

Lisäksi edellä kuvattu menetelmä ei estä kommenttien kohdistusta väärin rivien lopussa. Ja kaikki ohjelmoijat, jotka myöhemmin muokkaavat koodiasi, eivät ymmärrä tai hyväksy ideaasi.

Joten mikä on oikea tapa muotoilla koodisi – välilyönnillä tai sarkaimilla? Tai kenties molemmat? Yritetään selvittää tämä.

Taulukon historia - mielenkiintoisia faktoja

Lyhyt retki historiaan. Taulukko (horisontaalinen taulukko) otettiin alun perin käyttöön mekaanisissa kirjoituskoneissa taulukoiden luomisen helpottamiseksi, ja sitä käytettiin myös kappaleiden sisennysten luomiseen. Sillä ei ollut jäykkää kokoa. Ennen työtä käyttäjä asetti itse tarvitsemansa sarkaimet erityisellä mekanismilla. Samalla tavalla se voidaan nyt tehdä MS Wordissa. Tämän seurauksena peräkkäisillä sarkainnäppäimen (merkitty ←) painalluksilla kelkka siirtyi jousen vaikutuksesta automaattisesti vasemmalle kaikkia aiemmin asetettuja asentoja pitkin siirtäen siten syöttöalueen oikealle.

Kun elektronisen tekniikan aika koitti, jotta pyörää ei keksittäisi uudelleen, he alkoivat tehdä sitä kirjoituskoneiden kuvalla ja kaltaisella tavalla. Lisäksi tämä tekniikka ei aluksi juurikaan eronnut heistä. Esimerkiksi teletyyppi oli itse asiassa lennättimen ja kirjoituskoneen symbioosi. Siksi sen kehittäjät yksinkertaisesti muunsivat kaikki sen avaimet ja jotkin muut elementit (carriage return, carriage return to new line, ja jostain syystä jopa signaalin rivin päähän saavuttamisesta) ASCII-koodeiksi. Sarkainnäppäimelle annettiin koodi 9, mutta koska mukautettujen sarkaimien asetusmekanismin emulointi oli vaikeaa, he päättivät yksinkertaisesti korjata sen.

Miksi kiinteän välilehden koon valinta osui 8 tutulle välille? Kirjoituskoneiden rivin pituus oli yleensä 80 merkkiä. Teletyypit, joita käytettiin ensimmäisissä tietokoneissa myös tiedon tuottamiseen, koska ne olivat kirjoituskoneiden perillisiä. Jopa reikäkorteilla tietoja alettiin tallentaa 80 merkin riveillä. Siten kirjoituskoneet asettavat tietyn standardin rivin pituudelle.

Koska taulukkoa käytettiin ensisijaisesti taulukon sarakkeiden luomiseen, sopivin koko ei saa olla pienempi kuin tavallisimpien sanojen pituusero, jos se kirjoitetaan sarakkeeseen (jotta seuraavaan sarakkeeseen siirtymistä varten ei tarvitsisi eri määrä taulukoita). Samanaikaisesti tämän koon olisi pitänyt sallia suurin mahdollinen sarakkeiden lukumäärä. Kolmas ehto on, että koon tulee mahtua rivin pituuteen 80 merkkiä useita kertoja.

Viimeisen ehdon mukaan kehittäjät saivat valita viidestä todellisesta vaihtoehdosta: 4, 5, 8, 10 ja 16. Kaksi ensimmäistä vaihtoehtoa eivät olleet kovin käteviä, koska englanninkielisten sanojen pituusero ylitti usein nämä arvot. . 16 merkin sisennys vaikutti liian suurelta, heikensi työkalun käytettävyyttä ja rajoitti voimakkaasti sarakkeiden määrää taulukoissa. Valittavana oli 8-10 merkkiä.

8 merkin arvo oli ensimmäinen arvo, joka täytti sanan pituuseroehdon. Lisäksi se oli ainoa, joka täytti toisen ehdon – suurimman mahdollisen sarakkeiden määrän rakentamisen. Vaihtoehto 10 merkin välilehdellä näytti kohtuuttoman tuhlaalta ja antoi vain 8 saraketta, mikä saattoi kaventaa välilehden laajuutta. Lisäksi sarakkeiden enimmäismäärän numero 10 näytti vaikuttavammalta psykologisesti. Kaikki nämä syyt ilmeisesti saivat teletypen kehittäjät käyttämään 8 merkin taulukkoa.

Muutama sana kappaleen sisennyksestä, koska se menee myös lähelle aihettamme. OST 29.115-88:n mukaan kirjoituskoneille tulostettaessa kappaleen sisennyksen tulee olla kolme vetoa, mutta on sallittua käyttää viiden vedon sisennystä. Lisäksi on määrätty sijoittaa 29 (+-1) riviä yhdelle sivulle (joka vastaa noin puolitoista väliä kirjoituskoneella). Vaatimus kolmen lyönnin sisennykselle puolentoista välein on melko outo, ja alla selitän miksi.

Typografisessa asettelussa kappaleen sisennys vastaa puolitoista kirjasinkokoa, eli karkeasti sanottuna pystyviivan kokoa (eli etäisyys rivin alareunasta toisen rivin alareunaan) kerrottuna luvulla 1,5. Koska typografisessa asettelussa puoliväliä ei käytetä melkein koskaan ja rivit seuraavat välittömästi peräkkäin, oikea kappale on tässä tapauksessa suunnilleen sama kuin kyrillisten aakkosten kolme keskimmäistä merkkiä.

Todennäköisesti OST 29.115-88:n kääntäjät typografian yksityiskohtiin menemättä ottivat tämän arvon vakiona kirjoituskoneiden yksivälisille kiinteille fonteille ja asettivat samalla puolentoista rivivälin standardiksi, koska yksivälisellä kirjasimilla fontti ja heikko tulostuslaatu, yksittäinen väli näytti todella huonolta.

Mutta typografisiin sääntöihin perustuva suurempi välilyönti vaatii myös kappaleen sisennyksen lisäämistä. Kun standardia laadittiin, tämä lisääntynyt 5-bitin offset oli jo intuitiivisesti laajalti käytössä. Ilmeisesti tästä syystä standardissa laillistettiin de facto lisääntynyt 5 vedon sisennys.

Muuten, kirjoituskoneet eivät vaikuttaneet vain näytön tekstitilan sarakkeiden lukumäärään, vaan myös sen pystysuoraan 30 rivin kokoon. Loppujen lopuksi, kun tulostetaan puolentoista väliajoin, niin monta riviä mahtuu yhdelle arkille!

Strateginen näkemys ongelmanratkaisusta

Tietenkin on loogisinta sisentää koodin sisäkkäiset tasot sarkaimilla, koska siihen se alunperin oli tarkoitettu - aloittaa tekstin tulostaminen eri kohdista. Lisäksi tietokoneaikana välilehtimerkki sopi erittäin hyvin loogisen jakajan rooliin. Peräkkäisten välilehtimerkkien määrä osoitti selvästi loogisen sisäkkäisyyden tason.

Tästä lähtien käy selväksi, että tilat ovat välttämätön kainalosauva. Valitettavasti jokaisen kielen välilehtien kokoa ei ole tiukasti vahvistettu. Ohjelmoijat siirtyvät kielestä toiselle säilyttäen usein edellisen kielen perinteet sekä mieltymyksensä. Näissä olosuhteissa välilyönnit ovat keino korjata lähteen ulkoasu ja suojata sen muotoilun leviämistä vastaan.

Ratkaisu voisi olla pakottaa välilehtien koko sitomaan ohjelmointikieleen. Ergonomian asiantuntijat voisivat selkeästi määrittää sopivimmat välilehtien koot kunkin kielen syntaksille, ja tämä koko voitaisiin korjata kääntäjässä, mikä antaa jatkuvia varoituksia, kun sitä rikotaan.

Koska emme voi vaikuttaa ongelman ratkaisustrategiaan, meidän on pakko jotenkin päästä ulos taktisesti olemassa olevan todellisuuden puitteissa. Selvittääksesi oikean vaihtoehdon itsellesi, tarkastellaan välilyöntejä ja välilehtiä hieman yksityiskohtaisemmin.

Avaruusongelmat

Kun ohjelmoija avaa jonkun toisen lähdekoodin sisennyksellä ja tasauksella välilyöntejä käyttäen, mutta tämä sisennys osoittautuu hänelle hankalaksi, hän itse asiassa ei voi tehdä mitään saadakseen sen sopivaan muotoon suorittamatta joitain monimutkaisia ​​​​käsittelyjä.

Toinen välilyöntien ongelma on virheet, joissa yksi sisennysvälit poistetaan vahingossa ja jäävät huomaamatta. Kun siirryt uudelle riville, editori luo automaattisesti saman virheellisen sisennyksen kuin edellinen rivi, ja tämä virhe voi levitä useille koodiriville. Tämän virheen korjaaminen vaatii jonkin aikaa tylsiin, puhtaasti mekaanisiin toimintoihin.

Lisäksi ylimääräisen sisennyksen poistamiseksi sinun on painettava Vaihto+Tab-näppäinyhdistelmää tavallisen askelpalauttimen painamisen sijaan. Mutta tämä on tietysti tottumiskysymys.

Välilehtiongelmat

Välilehdellä on vain yksi ongelma - kun sen koko muuttuu, kommenttien ja muiden tasattujen elementtien kohdistus häiriintyy, vaikka niitä ei yleensä ole niin paljon, että se tekisi lähteen lukemisesta vaikeaa, eikä niiden korjaaminen ole niin vaikeaa .

Lisäksi kukaan ei vaivaudu ottamaan editorissa käyttöön kirjoittajan asettaman välilehden koon, mikä pienentää ulkonäkö mitä se olisi, jos lähdekoodi muotoilisi yksinkertaisesti välilyönneillä. Varsinkin tällaisissa tapauksissa jotkut ohjelmoijat kirjoittavat suositellun välilehden koon koodin ylimpään kommenttiin - mielestäni erittäin oikea päätös.

Johtopäätökset

Ensin sanon muutaman sanan sisennysten koosta sellaisenaan. Useimmille ohjelmointikielille ihanteellinen sisennyksen koko on täsmälleen 4 merkkiä. Miksi juuri? Koska on jo käynyt ilmi, että suurin osa lähteistä on muotoiltu tällä tavalla, ja hienosäätö 3 tai 5 merkin subjektiiviseen "ihanteeseen" menettää merkityksensä.

Satunnainen 8 merkin sisennys tekee koodista tarpeettoman vaakasuoraan tahriintuneen eikä jätä tilaa kommenteille oikealla. Lisäksi operaattorien pituuden ylittävän sisennyksen koon vuoksi sisäkkäisten tikkaiden portaissa paljastuu operaattoreiden ja operandien välisiä aukkoja, jotka luovat visuaalisia aukkoja, mikä ei hyödytä koodin luettavuutta.

Ei myöskään kovin hyvä ratkaisu on käyttää kahden merkin sisennystä, jota myös tapahtuu. Tässä tapauksessa, vaikka leveystilaa säästyy, on pesimätasoilla navigointi melko vaikeaa, mikä väistämättä aiheuttaa kiihtyvää väsymistä.

Jos ohjelmoijat pitävät kiinni neljän merkin kultaisesta keskiarvosta, välilyöntien ja sarkainten kannattajien välisestä keskustelusta tulee merkityksetöntä. Sillä välin voimme antaa seuraavat suositukset:

1. Käytä vakiokokoisia sisennyksiä. Java, Pascal, C, C++ jne. De facto standardi on 4 merkin sisennys, vaikka kuinka paljon haluaisimme käyttää eri kokoa.
2. Jos noudatetaan kohtaa 1, sillä ei ole mitään väliä, mitä käytät sisennykseen. Jos teet niistä välilyöntejä, se on hyvä - koodisi näyttää luettavalta kaikkialla, eikä mikään indeksoi koskaan. Muut ohjelmoijat tottuvat oikeaan muotoiluun lukiessaan koodiasi. Jos sisentää ne sarkainilla, se on vielä parempi - annat muille ohjelmoijille valinnanvaraa - ota oikea välilehtikoko käyttöön editorissa ja lue oikein muotoiltu koodi tai lue se tavanomaisilla sisennyksillä, mutta hiipiviä kommentteja ja yksittäisiä rivit, joissa kohdistus käytettiin.
3. Kohdan 2 valinta voidaan tehdä sen mukaan, kuinka koodiasi käytetään jatkossa. Jos sen lohkot lisätään jonkun muun koodiin, on ehdottomasti järkevää valita taulukko, jotta lisäajan on helpompi säätää muotoilua. Jos lähde on tarkoitettu julkaistavaksi Internetissä, jossa välilehti on joko syöty tai vahvistettu 8 merkin pituiseksi, voit valita välilyöntejä poistaaksesi lisävaiheen lähteen valmistelemisesta julkaisua varten. Jos organisaatiosi on jo määrittänyt tietyt muotoilusäännöt, sinulla ei ole enää vaihtoehtoja :)

Jos olet kuitenkin päättänyt käyttää omaa merkkimäärääsi sisennyksissä, välilyöntien ja sarkainten käyttö riippuu välttämättä siitä, kuinka muut ohjelmoijat käyttävät koodiasi myöhemmin.

Jos säännöllistä huoltoa varten virheenkorjausten suhteen, on luultavasti parempi käyttää välilyöntejä. Koodiasi ei käsitellä pitkään, ja jos se on hyvin muotoiltu, kenenkään ei tarvitse erityisesti muuttaa sisennysten kokoa.

Jos muut ohjelmoijat käyttävät koodiasi aktiivisesti lisäämällä sen ohjelmiinsa tai yksinkertaisesti kehittämällä projektiasi, on parempi käyttää välilehtiä. Tässä tapauksessa toisen ohjelmoijan on helpompi mukauttaa koodisi tyyppi tietyssä ryhmässä hyväksyttyyn standardiin.

Jos sinulla on yksi mutta tarvitset toisen

On niin upea editori - Notepad++. Siinä sarkainten korvaaminen välilyönneillä ja päinvastoin tapahtuu yhdellä napsautuksella, joka tehdään valikon "Muokkaa → Toiminnot välilyönnillä" -osiossa. Käytän tätä editoria tislaamaan blogissa julkaistavaksi tarkoitettuja välilehtiä, koska jälkimmäinen muuttaa automaattisesti yhden sarkainmerkin yhdeksi välilyönniksi, mikä ei ole hyväksyttävää.

Johtopäätös

Monet saattavat kysyä, mitä tämän artikkelin kirjoittaja valitsi itselleen? Ja hän valitsi välilehden koon 4 tuttua paikkaa. En ole löytänyt tarpeeksi hyvää syytä käyttää välilyöntejä, jotta koodini olisi nähtävissä jollekin, joka ei ole halunnut asettaa koodieditorinsa sisennystä de facto 4 merkin standardiin.

Mitä tulee Windowsin Notepadiin, jossa ei ole välilehtien kokoa, ja muihin vastaaviin editoreihin, jotka pakottavat välilehdet 8 merkkiin, en voi kuvitella syytä miksi ohjelmoija avaisi koodini niissä, vaikka jo pitkään Kaikissa käyttöjärjestelmissä on kätevät erikoistuneet lähdekoodin editorit.

Muistiossa työskentely ei ole siistiä. Hex-editorissa on siistiä työskennellä :)

Uteliaille kehittäjille kysymys sarkainten ja välilyöntien käytöstä koodin muotoilussa on edelleen ajankohtainen. Voidaanko ne vaihtaa keskenään: esimerkiksi 2 välilyöntiä sarkain tai 4? Mutta yhtä standardia ei ole, joten joskus kehittäjien välillä syntyy väärinkäsityksiä. Lisäksi eri IDE:t ja niiden kääntäjät käsittelevät välilehtiä eri tavalla.

Ratkaisu ongelmaan on yleensä sopimus muotoilusäännöistä projektin tai ohjelmointikielen sisällä kokonaisuudessaan.

Googlen kehittäjäryhmä tutki Githubin arkiston projekteja. He analysoivat 14 ohjelmointikielellä kirjoitettua koodia. Tutkimuksen tarkoituksena oli selvittää sarkainten ja välilyöntien suhde eli suosituin tapa muotoilla tekstiä jokaiselle kielelle.

Toteutus

Analyysissä käytimme olemassa olevaa taulukkoa, johon on tallennettu Github-arkistojen nimet.

Muistakaamme, että noin kaksi kuukautta sitten kaikki avoimen lähdekoodin Github-koodi tuli saataville BigQuery-taulukoiden muodossa.

Kaikkia tietovarastoja ei kuitenkaan valittu analysoitavaksi, vaan vain 400 000 parasta arkistoa, jotka saivat eniten tähtiä tammi-toukokuussa 2016.

Tästä taulukosta poimittiin tiedostot, jotka sisältävät koodia 14 suosituimmalla ohjelmointikielellä. Tätä varten sql-kyselyn parametreiksi määritettiin vastaavien tiedostojen laajennukset - .java, .h, .js, .c, .php, .html, .cs, .json, .py, .cpp, . xml, .rb, .cc, .go.

SELECT a.id id, koko, sisältö, binaari, kopiot, näytteen_repon_nimi , näytteen_polku FROM (SELECT id, FIRST(polku) sample_path, FIRST(repo_name) sample_repo_name FROM WHERE REGEXP_EXTRACT(polku, r"\.([^\.]* )$") IN ("java", "h", "js", "c", "php", "html", "cs", "json", "py", "cpp", "xml", "rb","cc","go") GROUP BY id) a LIITTY b ON a.id = b.id

864,6 s kulunut, 1,60 TB käsitelty

Pyynnön täyttäminen kesti melko kauan. Tämä ei ole yllättävää, koska oli tarpeen suorittaa liitosoperaatio 190 miljoonan rivin taulukossa ja 70 miljoonan rivin taulukossa. Tietoa käsiteltiin yhteensä 1,6 Tt. Kyselyn tulokset ovat saatavilla tästä osoitteesta.

Taulukko sisältää tiedostoja ilman niiden kaksoiskappaleita. Alla on yksilöllisten tiedostojen kokonaismäärä ja niiden koko. Päällekkäisiä tiedostoja ei sisällytetty analyysiin.

Sen jälkeen jäljellä oli vain luoda ja suorittaa lopullinen pyyntö.

SELECT ext, sarkaimet, välilyönnit, countext, LOG((välilyönnit+1)/(sarkaimet+1)) suhde FROM (SELECT REGEXP_EXTRACT(sample_path, r"\.([^\.]*)$") ext, SUM( best="sarkain") sarkaimet, SUM(paras="välilyönti") välilyönnit, COUNT(*) countext FROM (SELECT sample_path, sample_repo_name, IF(SUM(line=" ")>SUM(line="\t"), "välilyönti", "sarkain") WITHIN RECORD paras, COUNT(rivi) WITHIN RECORD c FROM (SELECT LEFT(SPLIT(sisältö, "\n"), 1) rivi, sample_path, sample_repo_name FROM HAVING REGEXP_MATCH(rivi, r"[ \t]")) JOLLA c>10 # vähintään 10 riviä, jotka alkavat välilyönnillä tai sarkaimella) GROUP BY ext) ORDER BY countext DESC LIMIT 100

16,0 s kulunut, 133 Gt käsitelty

Jokaisen 133 Gt:n koodirivin analysointi kesti 16 sekuntia. Sama BigQuery auttoi saavuttamaan tällaisen nopeuden.

Useimmiten sarkaimet löytyvät C:stä ja välilyönnit useimmiten Javassa.

Vaikka joillekin tiettyjen ohjaussymbolien suhteella ei ole väliä, ja keskustelut tästä aiheesta vaikuttavat kaukaa haetulta. Tällä ei ole merkitystä myös joillekin IDE:ille, jotka tallentavat sarkaimet välilyöntinä. On myös IDE-laitteita, joissa tämä numero voidaan määrittää manuaalisesti.

Jokin aika sitten tämä ongelma selvitettiin sarjassa "Piilaakso". Mies ja tyttö olivat eri mieltä muotoilukysymyksestä. Tämän seurauksena vanha holivar ei vain johtanut väärinkäsityksiin ammatillisesti, vaan myös aiheuttanut ongelmia heidän henkilökohtaisissa suhteissaan.

Yksi hyvän ohjelmointityylin tunnusmerkeistä on johdonmukaisuus – mitä vähemmän yllätyksiä, sitä parempi. Johdonmukaisuus helpottaa ohjelman lukemista, pääasiassa vähentämällä häiriötekijöitä. Se myös ohjaa lukijan silmää, esimerkiksi funktion sijainnin johdonmukaisuus tai tiedostojen yhteys helpottaa niiden löytämistä jatkossa. Se helpottaa myös tyyliongelmien ratkaisemista, mikä auttaa lukijaa tottumaan siihen helpommin.

Koodin selkeys

Hyvä tyyli on välttämätöntä, jotta ohjelmasi on selkeä, ymmärrettävä ja helppo muuttaa. Jos olet epävarma, valitse ongelmaan ymmärrettävin tekniikka. Muista, että kaikki kirjoittamasi joudut todennäköisesti lukemaan uudelleen. Tee tulevaisuudestasi helpompi ja saat selkeyden heti.

Välilyönnit ja muotoilu

Välilyönnit voivat vähentää lukijan silmien rasitusta. Koska kääntäjä jättää välilyönnit huomioimatta, voit vapaasti sijoittaa ne mihin tahansa ja muotoilla koodisi välilyönneillä haluamallasi tavalla. Jos teet sen viisaasti, siitä on apua.

Välilyöntejä käytetään sisennyksen, lausekkeiden ympärillä olevan välilyönnin, funktioiden allekirjoitusten ja funktion argumenttien sijoittamiseen. Nämä eivät tietenkään ole kaikki paikat, joissa välilyöntejä käytetään, mutta sen pitäisi antaa sinulle käsitys paikoista, joissa välilyöntejä voidaan käyttää luettavuuden parantamiseksi.

Sisennys

Jos et jo sisennytä koodiasi, teet sen pian. Tämä on ehdottoman välttämätöntä, koska se auttaa sinua löytämään nopeasti tarvittavat koodin ohjausrivit tai löytämään siitä virheitä. Sinun tulee sisentää jokainen koodilohko:

Jos (tosi) (// koodilohko )

Kiinnikkeiden tyylit

On monia tapoja sisentää koodia, ja monet niistä riippuvat siitä, mihin sijoitat sulkeet. Jotkut ihmiset pitävät yllä käytetystä tyylistä. Jotkut ihmiset pitävät alla olevasta tyylistä:

Jos (tosi) (// koodilohko )

Muitakin tyylejä on:

Jos (tosi) (// koodilohko )

Valitset itse, minkä aaltosulkeetyylin valitset, vaikka suosittelenkin käyttämään samaa aaltosulkeetyyliä kaikille saman projektin parissa työskenteleville. Joka tapauksessa jokaisella tyylillä on argumentteja. On hyvä käyttää hakasuljetyyliä, jonka avulla näytölle mahtuu mahdollisimman paljon koodia, mutta johdonmukaisuus on yhtä tärkeää.

Sisennyksen leveys

Sisennyksen määrä on henkilökohtaisten mieltymysten asia – joka tapauksessa on yleensä parasta valita sisennyksen koko, joka on tarpeeksi pieni, jotta koodi mahtuu yhdelle näytölle. Pidän sisennyksen leveyttä välillä 2–8 kohtuullisena ja luettavana, vaikka olen havainnut, että yli neljä välilyöntiä sisennykselle voi johtaa liian pitkiin riveihin.

Yleensä liian pitkille riveille paras ratkaisu on vähentää koodin monimutkaisuutta tai ainakin vetää osa toiminnoista erillisiin toimintoihin. Tämä vähentää sisennystasojen määrää ja voi tehdä koodista luettavamman (jos se tehdään oikein).

Sarkaimet ja välilyönnit

Sarkainten tai välilyöntien käytöstä on jonkin verran kiistaa. Huomaa, että tämä ei ole sama asia kuin kysyä, sisennytäänkö välilyönneillä vai sarkaimilla. Useimmat ihmiset antavat tekstieditorin selvittää tämän puolestaan ​​(tai muuntaa sarkaimet välilyönneiksi).

Sarkainten ja välilyöntien todellinen ongelma on se, mitä tapahtuu, kun joku avaa koodisi. Voit asettaa välilehtiä mille tahansa määrälle sarakkeita, ja koodisi avaavalla henkilöllä voi olla eri välilehtien leveys. Tämä voi aiheuttaa tuhoa jopa hyvin muotoillulla koodilla. Vain välilyöntien käyttö korjaa tämän ongelman, koska kaikki näyttää samalta.

Joskus kunnollinen koodinmuotoilija löytyy tekstieditori, voi auttaa lieventämään tätä ongelmaa alustamalla koodin uudelleen. Voit myös muuttaa omia asetuksiasi näyttääksesi koodin oikein (vaikka tämä ei ole kovin mukavaa).

Paras ratkaisu, jos päätät käyttää välilehtiä, on olla erittäin varovainen niiden kanssa. Todellinen ongelma syntyy itse asiassa, kun sarkaimia ei käytetä vain sisennykseen, vaan myös nopeana tapana siirtää neljä tai kahdeksan merkkiä oikealle. Katsotaanpa esimerkiksi seuraavaa koodia:

Jos (pitkän_aikaisen_yksi && pitkän_ajan_kaksi) ( // koodi )

Jos toinen ehto muotoiltiin sarkaimella, jossa on neljä välilyöntiä ja sen jälkeen välilyönti, avattaessa toisessa editorissa, jonka sarkainleveys on kahdeksan välilyöntiä, koodi näyttää rumalta:

If (long_term_one && long_term_two) ( // koodi valintalausekkeen rungossa )

Jos muotoiluun käytettiin välilyöntejä, koodi näkyy oikein:

If (long_term_one && long_term_two) ( // jos lausekekoodi)

Väärä tilojen käyttö

Kuinka monta tilaa käytät, on sinun päätettävissäsi. On kuitenkin syytä olla tietoinen joistakin ongelmista. Ensinnäkin, mitä enemmän tyhjää tilaa, joka auttaa korostamaan ohjelman logiikkaa, sitä parempi. Mutta et halua, että aukkosi häiritsee sinua. Se ei ehkä hämmennä sinua tällä hetkellä, mutta saattaa hämmentää sinua tulevaisuudessa tai muita, jotka lukevat koodisi. Miltä huono muotoilu näyttää?

Jos(tosi)++i;

++j;

Sisennys kertoo, että nämä kaksi lauseketta käynnistyvät, kun ehdollinen lauseke suoritetaan, mutta niin ei todellisuudessa tapahdu. Kun jäljität syntaksivirheen sadoilla tai tuhansilla koodiriveillä, päädyt vain luiskaamaan koodia sen sijaan, että tarkistaisit huolellisesti jokaisen rivin. Mitä helpompi sinun on tarkistaa koodisi ja poimia tärkeitä yksityiskohtia, sitä nopeammin löydät vikoja, jotka hiipivät sisään huomaamatta. Kuten tässä esimerkissä, vain ensimmäinen lause kuuluu if-lauseen runkoon.

Joskus tyylejä ei haluta muuttaa yhden elementin vuoksi tai tekstiin on lisättävä useita välilyöntejä esteettisistä tai tekstin muotoilutyylisyistä. Ja sitten herää kysymys: "Kuinka lisätä välilyöntiä HTML:ään, jotta teksti näkyy kauniisti ja samalla vältetään koodin redundanssi?" Katsotaanpa tätä varten välilyöntejä ja esimerkkejä niiden käytöstä HTML-koodissa.

HTML-välilyönti Tapauksissa, joissa sinun ei tarvitse erottaa tekstin osia toisistaan, se auttaa rikkoutumaton tila

, jonka koodi näyttää tältä:

Tämä on niin kutsuttu "murtumaton tila".

Esimerkkejä katkeamattoman tilan käytöstä:

Jne. koska E. Veltistov 11 tuhatta ruplaa

Ohut tila Edellä käsitelty HTML-välilyöntikoodi on läsnä kaikkialla. Mutta on aikoja, jolloin tavallinen tila osoittautuu liian "isoksi". Sitten se korvataan ohut tila

 

. Tämä on tila, joka on neljäsosa käytetyn fontin leveydestä. Ohut väli on osoitettu seuraavasti:

ja sitä käytetään suurimmaksi osaksi numeroiden numeroiden erottamiseen, esimerkiksi "15 000 000 dollaria" tulisi kirjoittaa näin:

15 000 000 dollaria Huomautus: Ohut tila ei välttämättä näy oikein joidenkin selainten vanhemmissa versioissa, mutta kaikissa uusimmat versiot

toimii loistavasti.

Muuntyyppiset välilyönnit HTML:ssä

• Edellä käsiteltyjen tärkeimpien tyyppien lisäksi on muitakin.
•   - välilyönti N-kirjaimen pituus;
•   - välilyönti M-kirjaimen pituus;
• ‌ - nollapituus ei-yhdistettävä merkki;

15 000 000 dollaria Jos haluat laittaa useita välilyöntejä peräkkäin, ympäröi teksti tunnisteella

:

 
Verkkosivuston rakentaja "Nubex"
Space käyttäen CSS
Mahdollisuus luoda välilehtiä (sisennys) CSS:n avulla voidaan ratkaista seuraavalla tekniikalla:

   Verkkosivuston rakentaja "Nubex"
".
Halusin vastata kommentteihin, mutta volyymin ja halun olla riippumaton alkuperäisestä aiheesta, päätin luoda uuden aiheen.
Joten, leikkauksen alla - miksi sarkaimet ovat parempia kuin välilyönnit, tärkeimmät väärinkäsitykset sarkainkohdista ja niiden oikeasta käytöstä.
Aloitetaan siitä, että useimmat ihmiset (ainakin Habressa) pitävät parempana välilehdistä.
Itse asiassa outoa on, että monet eivät vieläkään tee eroa sisennyksen ja kohdistuksen välillä.  No, tämä on sisennys: 
for (int i = 0; i< 10; i++) {
 if (a[i] == 0)
 do_something(i);
}
 
Ja tämä on tasaus: 
int jokin_muuttuja = 0;  int v1 = 0;
Ensimmäinen voidaan tehdä sekä sarkain- että välilyönnillä, mutta kun teet sen sarkainilla, jokainen voi säätää sisennyksen leveyttä oman maun mukaan ja toinen - tiukasti välilyönnillä.
IDE:ssä on Smart Tabs -vaihtoehto tätä varten:
Jos käytät sarkaimia oikein (eli vain sisennykseen), voit helposti muuttaa välilehtien kokoa ohjelmointityyliäsi rikkomatta.
2 välilyöntiä per välilehti: 

5 välilyöntiä per välilehti: 

9 välilyöntiä per välilehti: 
Mistä ongelmista jäämme paitsi?
1. Jokainen ohjelmoija voi säätää välilehden pituutta oman maun mukaan. Aina toimii käytännössä.  Kun koodi on erittäin sisäkkäinen, voit asettaa sarkainleveydeksi kaksi välilyöntiä, muussa tapauksessa - neljä. 
2. On helpompi työskennellä kolmannen osapuolen kirjastojen kanssa.  Jotkut kirjastot tukevat tyyliä, jossa sarkainleveys on kaksi välilyöntiä, toiset neljä välilyöntiä.  Vain välilehtien käyttö ei rajoita tyyliä. 
Lainaan pari ajatusta edellisestä aiheesta: 
On vaikeaa työskennellä sellaisten projektien kanssa, jotka käyttävät testissä välilehtiä sisältäviä kirjastoja.  Oletetaan, että yhdessä kirjastossa välilehti on 3 merkkiä, toisessa 4 merkkiä.  Ja käytät 2 symbolia projektissa.  Tämän seurauksena osa koodistasi näkyy editorissa väärässä muotoilussa.

Itse asiassa taulukointia käyttävissä projekteissa tällaisia ​​ongelmia ei ole - koska taulukointi on dimensioton, mutta parin eri välilyöntikokoisen kirjaston tukeminen samanaikaisesti tulee ongelmalliseksi, koska  Et voi enää käyttää sarkaimia (joten IDE korvaa sarkaimet välilyönneillä).  Tietysti tämä ongelma on mahdollista ratkaista erilaisilla projekteilla eri asetuksilla, mutta tämä on silti kainalosauva, ja se räjäyttää silti mielesi eri pesäkokoista. 
Vuohen on helppo päästää puutarhaan.  Oletetaan, että sarkaimesi on yhtä suuri kuin 4 välilyöntiä.  Joku muokkasi jotain käyttämällä eri välilehtikokoa tai lisäämällä välilyöntejä.  Kaikki näytti hyvältä hänen mielestään, mutta koodirivisi menee jonnekin.

Samoin taulukointi on mittaton.  Tämä ongelma ilmenee vain projekteissa, joissa käytetään välilyöntejä.  Jos välilehtiä käytetään, ne voivat olla vähintään 2 tai 10 merkin pituisia. 
Sinun on jatkuvasti säädettävä erilaisia ​​​​editoreja tarvitsemasi välilehden kokoon.  Vaikka sinun tarvitsee vain katsoa koodia muokkaamatta sitä.  Muuten kaikki hajoaa.  Tämä on erityisen hankalaa, kun joudut tekemään jotain koodisi kanssa kolmannen osapuolen koneessa.

Oletetaan, että avaan Kate ja korjaan nopeasti jonkin tiedoston koodin.  Hups, sarkainkoko on kaksi välilyöntiä.  Sinun täytyy mennä asetuksiin.  Ja seuraavassa tiedostossa toisesta kirjastosta on neljä välilyöntiä.  Sinun on käytettävä välilyöntiä sarkaimen sijasta sisennykseen, kauheaa.  Välilehtien kanssa ei ole tällaista ongelmaa. 
Ylimääräisiä komplikaatioita niille, jotka työskentelevät samanaikaisesti projekteissa, joissa koodausstandardit vaativat erilaisia ​​sisennyksiä.  Jos standardit edellyttävät taulukoinnin käyttöä, tämä on silti se aina kipeä hammas.  Välilyönnissä kaikki on jälleen paljon yksinkertaisempaa.

Kuten edellä mainittiin, tämä ongelma koskee erityisesti ongelmia, ei välilehtiä. 
Lisäksi välilyönnillä on sellaisia ​​haittoja, kuten mahdottomuus liikkua nopeasti näppäimistön nuolinäppäimillä (napsauttaa jokaista välilyöntiä, ei lohkon läpi), mahdollisuus tehdä virhe (3 välilyönnin laittaminen yhteen paikkaan neljän sijasta, mikä tuhoaa edelleen rakenne), tiedostokoon kasvu ja paljon muuta.
Johtopäätös
Välilyönnillä ei ole merkittävää etua välilehtiin verrattuna, emmekä pakota ohjelmoijaa kehyksiin emmekä pakota häntä kärsimään välilehdistä, jotka ovat liian pieniä (tai liian suuria) hänelle. 
Main
Sillä ei ole oikeastaan ​​väliä mitä käytät.  On tärkeää, että seuraat koodisi järjestystä ja pysynyt aina samassa tyylissä.  Ota sarkainten/välilyöntien näyttö käyttöön, vaihda joskus sarkainkokoa toiseen ja tarkasta koodia silmälläsi varmistaaksesi, ettet ole lisännyt välilyöntejä sarkainten sijasta tai sarkaimia välilyöntien sijaan. 
UPD: huomautus kommenttien mukaan
Olen pitkään halunnut kirjoittaa artikkelin välilehdistä.  Mutta ei "Tabs VS Spaces", vaan siitä, kuinka välilehtiä käytetään oikein.  Kommentit vahvistivat, että monet eivät tienneet sisennyksestä ja tasauksesta.  Tämän artikkelin tarkoitus ei ole ollenkaan se, että kaikki välilehtiä käyttävät ovat oikeassa.  On koodausstandardeja, kieliominaisuuksia ja henkilökohtaisia ​​mieltymyksiä. 
Tärkeintä on tuntea sisennyssäännöt ja osata käyttää niitä.  Ja älä koskaan sekoita kahta tyyliä.  Huomaa - älä sekoita sarkaimia ja välilyöntejä, mutta älä sekoita kahta tyyliä. 
Henkilökohtaisesti suosittelen käyttämään aiheessa kuvattua lähestymistapaa, mutta vain, jos käyttämäsi koodin standardit eivät tarkoita jotain muuta.