Ang mga relihiyosong digmaan sa paksa ng pag-format ng code ay hindi humupa sa mga programmer. Isa sa mga pinakapinipilit na tanong sa paksang ito ay kung paano mag-indent at mag-align sa source code ng mga program - mga tab, mga puwang, o isa - isa, at ang isa - ang isa? Ang bawat pagpipilian ay tiyak na may mga kalamangan at kahinaan nito.

Ayon sa aking obserbasyon, sa mga batikang programmer, sa karamihan ng mga kaso, ang mga tagasuporta ng mga espasyo ay nanalo pa rin, at ang mapagpasyang argumento dito ay ang visual na pagkakapareho ng mga nakahanay na linya, anuman ang mga setting ng programa ng bawat indibidwal na programmer. At mas gusto nilang sumang-ayon sa bilang ng mga puwang sa indentation sa loob ng koponan. Ano ang pumipigil sa kanila na sumang-ayon din sa laki ng tab ay hindi malinaw :)

Marahil, ang kaugnayan ng paggamit ng mga puwang ay lumitaw kung ang mga programmer ay hindi sumang-ayon sa laki ng "tab", ngunit handang magtrabaho kasama ang code ng bawat isa na may iba't ibang mga indentasyon. Sa kasong ito, ang code at mga komento ay hindi kailanman mag-crawl, at upang mapanatili ang ganoong katatag na hitsura, hindi mo kailangang magpalit ng mga setting ng editor sa bawat oras. Ang problema sa kasong ito ay lilitaw lamang kapag pinagsama ang mga bloke ng code na isinulat ng iba't ibang mga programmer sa isang file.

Mga pagkakaiba sa pag-uugali ng mga puwang at tab

Isaalang-alang ang sumusunod na naglalarawang piraso ng code:

Kung (mStatus != Status.PENDING) ( switch (mStatus) ( case RUNNING: throw new IllegalStateException("Cannot execute task: " + "the task is already running."); case FINISHED: throw new IllegalStateException("Cannot execute task : " + "ang gawain ay naisakatuparan na " + "(isang gawain ay maaaring isakatuparan lamang ng isang beses)"); ) )

Makikita natin na ang mga text message block ay madaling basahin dahil ang simula ng bawat linya ay naiwang nakahanay. Kapag ang lahat ng mga indent (parehong code at alignment) ay ginawa gamit ang mga puwang, ang mga bloke ng teksto ay palaging nakahanay, sa anumang computer at sa anumang source code editor (pagkatapos ng lahat, kapag nagsusulat ng source code, isang monospaced na font na may mga puwang ng parehong lapad bilang ang mga karakter ay tradisyonal na ginagamit). Ngunit kung ang laki ng indentation ay hindi karaniwan para sa isa pang programmer, hindi niya ito basta-basta mababago.

Kung hindi tayo nakahanay sa mga puwang, ngunit sa mga tab, kung gayon tayo mismo ay makakakuha ng parehong hitsura, ngunit para sa isa pang programmer na ang editor ay na-configure para sa ibang ratio ng tabulation, halimbawa, hindi 4, tulad ng sa amin, ngunit 8, ang mga linya ay lilipat. malaki sa kanan, at may tab ratio na 2 - sa kaliwa. Kasabay nito, ang mga pangalawang linya ng text message ay hindi maaaring hindi gumapang. Ang parehong bagay ay mangyayari sa pagkakahanay ng mga komento sa dulo ng mga linya ng code. Hindi na sila magiging maayos na naka-left-align sa buong block na may iba't ibang antas ng nesting.

Ang isang intermediate na opsyon ay tinatawag na paglikha ng mga indentasyon - tabulasyon, at pagkakahanay - isang pinagsamang paraan. Nagsisimula ang pagkakahanay sa mga tab, at kapag naabot na ang antas ng nakaraang linya, na may mga puwang. Ang kawalan ng pamamaraang ito ay ang pagiging kumplikado ng pamamaraang ito at potensyal na pagkalito - pagkatapos ng lahat, nang hindi pinapagana ang visualization ng mga control character, hindi agad malinaw kung nasaan ang mga tab at kung nasaan ang mga puwang. Hindi rin malinaw kung paano sila kikilos kapag kinopya sa ibang mga lugar sa code.

Bukod dito, ang pamamaraang inilarawan sa itaas ay hindi magliligtas sa iyo mula sa maling pagkakahanay ng mga komento sa dulo ng mga linya. At hindi lahat ng programmer na mag-e-edit sa iyong code ay mauunawaan o tatanggapin ang iyong ideya.

Kaya ano ang tamang paraan upang i-format ang iyong code - na may mga puwang o tab? O baka pareho? Subukan nating malaman ito.

Kasaysayan ng tabulasyon - mga kagiliw-giliw na katotohanan

Isang maikling iskursiyon sa kasaysayan. Ang tabulation (horizontal na tabulasyon) ay orihinal na ipinakilala sa mga mekanikal na makinilya para sa kaginhawahan ng paglikha ng mga talahanayan at ginamit din upang lumikha ng indentasyon ng talata. Wala itong matibay na sukat. Bago magtrabaho, ang gumagamit mismo ang nagtakda ng mga paghinto ng tab na kailangan niya gamit ang isang espesyal na mekanismo. Sa parehong paraan na maaari na itong gawin sa MS Word. Bilang resulta, sa sunud-sunod na pagpindot ng tab key (itinalaga bilang ←), ang karwahe, sa ilalim ng pagkilos ng isang spring, ay awtomatikong lumipat sa kaliwa kasama ang lahat ng dating itinakda na mga posisyon, sa gayon ay inililipat ang input area sa kanan.

Nang dumating ang oras para sa elektronikong teknolohiya, upang hindi muling likhain ang gulong, sinimulan nilang gawin ito sa imahe at pagkakahawig ng mga makinilya. Bukod dito, sa una ang pamamaraan na ito ay hindi gaanong naiiba sa kanila. Halimbawa, ang teletype ay talagang isang symbiosis ng telegraph at ng typewriter. Samakatuwid, ang mga developer nito ay na-convert lamang ang lahat ng mga susi nito at ilang iba pang mga elemento (carriage return, carriage return sa isang bagong linya, at sa ilang kadahilanan kahit na ang signal para sa pag-abot sa dulo ng linya) sa mga ASCII code. Ang tab key ay itinalaga ng isang code na 9, ngunit dahil ang pagtulad sa mekanismo para sa pagtatakda ng mga custom na paghinto ng tab ay mahirap, nagpasya silang gawin itong maayos.

Bakit nahulog sa 8 pamilyar na espasyo ang pagpili ng nakapirming laki ng tab? Bilang isang patakaran, ang mga makinilya ay may haba ng linya na 80 mga character. Teletypes, na ginagamit sa unang mga computer upang mag-output ng impormasyon, masyadong, dahil sila ang tagapagmana ng mga typewriter. Kahit na sa mga punched card, nagsimulang mag-imbak ang impormasyon sa mga linya ng 80 character. Kaya, ang mga makinilya ay nagtatakda ng isang tiyak na pamantayan para sa haba ng linya.

Dahil ang tabulasyon ay pangunahing ginagamit upang lumikha ng mga haligi ng talahanayan, ang pinaka-maginhawang sukat ay dapat na hindi bababa sa pagkakaiba sa haba ng mga pinakakaraniwang salita kung nakasulat sa isang hanay (upang lumipat sa susunod na hanay ay hindi na kailangang gumawa ng ibang bilang ng mga tabulasyon). Kasabay nito, ang laki na ito ay dapat na pinapayagan para sa maximum na posibleng bilang ng mga column. Ang ikatlong kundisyon ay ang laki ay dapat magkasya sa haba ng linya na 80 character nang maraming beses.

Ayon sa huling kondisyon, ang mga developer ay may pagpipilian sa sumusunod na limang tunay na mga pagpipilian: 4, 5, 8, 10 at 16. Ang unang dalawang pagpipilian ay hindi masyadong maginhawa, dahil ang pagkakaiba sa mga haba ng mga salitang Ingles ay madalas na lumampas sa mga halagang ito. . Ang 16-character na indentation ay tila napakalaki, nabawasan ang kakayahang magamit ng tool, at lubhang nilimitahan ang bilang ng mga column sa mga talahanayan. May pagpipilian sa pagitan ng 8 at 10 character.

Ang halaga ng 8 character ay ang unang halaga na nasiyahan sa kondisyon ng pagkakaiba sa haba ng salita. Bilang karagdagan, ito lamang ang nasiyahan sa pangalawang kundisyon—pagbuo ng maximum na posibleng bilang ng mga column. Ang opsyon na may 10-character na tab ay mukhang hindi makatwirang aksayado at nagbigay lamang ng 8 column, na maaaring medyo paliitin ang saklaw ng tab. Bilang karagdagan, ang bilang 10 para sa maximum na bilang ng mga hanay ay mukhang mas kahanga-hanga sa sikolohikal. Ang lahat ng mga kadahilanang ito, tila, ay nag-uudyok sa mga developer ng teletype na mag-tabulate ng eksaktong 8 character.

Ilang salita tungkol sa indentation ng talata, dahil napupunta rin ito sa isang lugar na malapit sa aming paksa. Ayon sa OST 29.115-88, kapag nagpi-print sa mga typewriter, ang indentation ng talata ay dapat na katumbas ng tatlong stroke, ngunit pinapayagan itong gumamit ng indentation ng limang stroke. Bilang karagdagan, inireseta na maglagay ng 29 (+-1) na linya sa isang pahina (na humigit-kumulang tumutugma sa isa at kalahating puwang sa isang makinilya). Ang kinakailangan para sa isang indentation ng 3 beats sa isang isa at kalahating pagitan ay medyo kakaiba, at sa ibaba ay ipapaliwanag ko kung bakit.

Sa typographic na layout, ang indentation ng talata ay katumbas ng isa't kalahating laki ng font, iyon ay, halos pagsasalita, ang laki ng patayong linya (ibig sabihin, ang distansya mula sa ibaba ng isang linya hanggang sa ibaba ng isa pa), na pinarami ng 1.5. Dahil sa typographic na layout ang kalahating espasyo ay halos hindi na ginagamit, at ang mga linya ay sumusunod kaagad sa isa't isa, ang tamang talata sa kasong ito ay humigit-kumulang katumbas ng tatlong gitnang mga character ng Cyrillic alphabet.

Marahil, ang mga compiler ng OST 29.115-88, nang hindi nag-uulat ng mga detalye ng palalimbagan, ay kinuha ang halagang ito bilang isang pare-pareho para sa mga monospace na nakapirming mga font ng mga typewriter, at sa parehong oras ay itinatag ang isa't kalahating line spacing bilang isang pamantayan, dahil may isang monospace font at mababang kalidad ng pag-print, ang solong espasyo ay mukhang napakasama.

Ngunit ang pinataas na espasyo, batay sa mga panuntunan sa typographic, ay nangangailangan din ng pagtaas ng indentasyon ng talata. Sa oras na binuo ang pamantayan, ang tumaas na 5-beat offset na ito ay intuitive na malawakang ginagamit. Tila, ito ang dahilan kung bakit ang de facto na tumaas na indentation ng 5 stroke ay ginawang legal sa pamantayan.

Sa pamamagitan ng paraan, naiimpluwensyahan ng mga makinilya hindi lamang ang bilang ng mga haligi ng mode ng teksto ng monitor, kundi pati na rin ang vertical na sukat nito na 30 linya. Pagkatapos ng lahat, kapag nagpi-print na may isa't kalahating pagitan, iyan ang eksaktong kung gaano karaming mga linya ang magkasya sa isang sheet!

Estratehikong pananaw sa paglutas ng problema

Siyempre, ito ay pinaka-lohikal na mag-indent ng mga antas ng nesting ng code na may mga tab, dahil iyon ang orihinal na nilayon - upang simulan ang pag-print ng teksto mula sa iba't ibang mga posisyon. Bilang karagdagan, sa panahon ng computer, ang karakter ng tab ay napakahusay na angkop sa papel ng isang lohikal na divisor. Ang bilang ng magkakasunod na mga character sa tab ay malinaw na nagpahiwatig ng antas ng lohikal na pugad.

Mula dito nagiging malinaw na ang mga espasyo ay isang kinakailangang saklay. Pagkatapos ng lahat, sa kasamaang-palad, ang laki ng tab para sa bawat wika ay hindi mahigpit na naayos. Ang mga programmer ay lumipat mula sa wika patungo sa wika, madalas na pinapanatili ang mga tradisyon ng nakaraang wika, pati na rin ang kanilang mga kagustuhan. Sa mga kundisyong ito, ang mga puwang ay isang panukala upang ayusin ang hitsura ng pinagmulan at protektahan laban sa pagkalat ng pag-format nito.

Ang solusyon ay maaaring pilitin ang laki ng tab na itali sa programming language. Malinaw na matutukoy ng mga ergonomic na eksperto ang mga pinaka-maginhawang laki ng tab para sa syntax ng bawat wika, at maaaring ayusin ang laki na ito sa compiler, na nagbibigay ng mga paulit-ulit na babala kapag ito ay nilabag.

Dahil hindi natin maiimpluwensyahan ang diskarte para sa paglutas ng problema, napipilitan tayong lumabas kahit papaano sa loob ng balangkas ng umiiral na katotohanan. Upang malaman ang tamang opsyon para sa iyong sarili, tingnan natin ang mga isyu ng mga espasyo at tab nang mas detalyado.

Mga isyu sa espasyo

Kapag ang isang programmer ay nagbukas ng source code ng ibang tao na may indentation at alignment gamit ang mga puwang, ngunit ang indentation na ito ay lumalabas na hindi maginhawa para sa kanya, siya, sa katunayan, ay hindi maaaring gumawa ng anumang bagay upang dalhin ito sa isang maginhawang form nang hindi nagsasagawa ng ilang mga kumplikadong manipulasyon.

Ang isa pang problema sa whitespace ay ang mga error kung saan ang isa sa mga puwang ng indentation ay hindi sinasadyang naalis at hindi natutukoy. Kapag lumipat ka sa isang bagong linya, awtomatikong gagawa ang editor ng parehong maling indentation gaya ng nakaraang linya, at maaaring kumalat ang error na ito sa ilang linya ng code. Ang pagwawasto sa error na ito ay mangangailangan ng ilang oras na ginugol sa mapurol, puro mekanikal na operasyon.

Bilang karagdagan, upang alisin ang labis na indentation, sa halip na ang karaniwang pagpindot sa Backspace, kailangan mong pindutin ang kumbinasyon ng Shift+Tab key. Ngunit ito, siyempre, ay isang bagay ng ugali.

Mga problema sa tab

Ang tab ay may isang problema lamang - kapag ang laki nito ay nagbago, ang pagkakahanay ng mga komento at iba pang nakahanay na mga elemento ay nagambala, bagaman, bilang isang panuntunan, hindi gaanong marami sa kanila na ginagawang mahirap basahin ang pinagmulan, at ang pagwawasto sa mga ito ay hindi napakahirap. .

Bilang karagdagan, walang nag-abala sa iyo na paganahin lamang sa editor ang laki ng tab na itinakda ng may-akda, na binabawasan hitsura sa kung ano ang mangyayari kung ang source code ay simpleng na-format na may mga puwang. Lalo na para sa mga ganitong kaso, isinulat ng ilang programmer ang inirekumendang laki ng tab sa tuktok na komento sa code - sa palagay ko, isang napakatamang desisyon.

Mga konklusyon

Una, magsasabi ako ng ilang salita tungkol sa laki ng mga indent. Para sa karamihan ng mga karaniwang programming language, ang perpektong laki ng indentation ay eksaktong 4 na character. Bakit eksakto? Dahil napag-alaman na ang karamihan sa mga mapagkukunan ay na-format sa ganitong paraan, at ang mahusay na pagsasaayos sa subjective na "ideal" ng 3 o 5 na mga character ay nawawala ang kahulugan nito.

Ang paminsan-minsang 8-character na indentation ay ginagawa ang code na hindi kinakailangang ma-smeared nang pahalang at hindi nag-iiwan ng puwang para sa mga komento sa kanan. Bilang karagdagan, dahil sa labis na laki ng indentation sa haba ng mga operator, ang mga gaps sa pagitan ng mga operator at operand ay nakalantad sa mga hakbang ng nesting ladder, na lumilikha ng mga visual gaps, na hindi nakikinabang sa pagiging madaling mabasa ng code.

Gayundin, hindi isang napakahusay na solusyon ang paggamit ng dalawang-character na indentation, na nangyayari rin. Sa kasong ito, kahit na ang lapad na espasyo ay nai-save, ito ay nagiging medyo mahirap na i-navigate ang mga antas ng nesting, na hindi maaaring hindi nagiging sanhi ng pinabilis na pagkapagod.

Kung ang mga programmer ay mananatili sa ginintuang ibig sabihin ng 4 na mga character, ang debate sa pagitan ng mga tagapagtaguyod ng mga puwang at mga tab ay magiging walang kaugnayan. Pansamantala, maaari naming ibigay ang mga sumusunod na rekomendasyon:

1. Gumamit ng mga karaniwang indent na laki ng de facto. Para sa Java, Pascal, C, C++, atbp. Ang de facto na pamantayan ay 4 na character ng indentation, gaano man natin gustong gumamit ng ibang laki.
2. Kung susundin ang punto 1, hindi mahalaga kung ano ang iyong ginagamit upang mag-indent. Kung gagawin mo ang mga ito ng mga puwang, ito ay magiging mabuti - ang iyong code ay magmumukhang nababasa sa lahat ng dako, at walang mag-crawl. Ang ibang mga programmer ay magiging bihasa sa tamang pag-format kapag binabasa ang iyong code. Kung i-indent mo ang mga ito gamit ang mga tab, magiging mas mahusay ito - bibigyan mo ang iba pang mga programmer ng pagpipilian - i-on ang tamang laki ng tab sa editor at basahin ang wastong na-format na code, o basahin ito gamit ang karaniwang mga indent, ngunit gumagapang na mga komento at indibidwal mga linya kung saan inilapat ang pagkakahanay.
3. Ang pagpili sa punto 2 ay maaaring gawin depende sa kung paano gagamitin ang iyong code sa hinaharap. Kung ang mga bloke nito ay ipapasok sa code ng ibang tao, tiyak na makatuwirang piliin ang tabulasyon upang gawing mas madali para sa inserter na ayusin ang pag-format. Kung ang pinagmulan ay inilaan para sa paglalathala sa Internet, kung saan ang tab ay kinakain o naayos sa 8 mga character, pagkatapos ay maaari kang pumili ng mga puwang upang alisin ang karagdagang hakbang ng paghahanda ng pinagmulan para sa publikasyon. Kung nakapagtatag na ang iyong organisasyon ng ilang partikular na panuntunan sa pag-format, wala ka nang pagpipilian :)

Kung, anuman ang mangyari, determinado kang gamitin ang iyong sariling bilang ng mga character sa indentation, kung gayon ang paggamit ng mga puwang at tab ay kinakailangang nakadepende sa kung paano ginamit ang iyong code ng ibang mga programmer.

Kung para sa regular na pagpapanatili sa mga tuntunin ng pag-aayos ng bug, malamang na mas mahusay na gumamit ng mga puwang. Ang iyong code ay hindi gagana nang matagal, at kung ito ay mahusay na na-format, kung gayon walang sinuman ang partikular na kakailanganing baguhin ang laki ng mga indent.

Kung ang iyong code ay aktibong gagamitin ng iba pang mga programmer, ipinapasok ito sa kanilang mga programa o simpleng pagbuo ng iyong proyekto, kung gayon mas mahusay na gumamit ng mga tab. Sa kasong ito, magiging mas madali para sa isa pang programmer na iakma ang uri ng iyong code sa pamantayang tinatanggap sa isang partikular na grupo.

Kung mayroon ka ngunit kailangan mo ng isa pa

Mayroong napakagandang editor - Notepad++. Sa loob nito, ang pagpapalit ng mga tab na may mga puwang at kabaligtaran ay ginagawa sa isang pag-click, na ginawa sa seksyon sa menu na "I-edit → Mga Operasyon na may Mga Puwang". Ginagamit ko ang editor na ito upang i-transcribe ang mga naka-tab na piraso ng code na nilalayon para sa paglalathala sa isang blog, dahil awtomatikong binabago ng huli ang isang character ng tab sa isang espasyo, na hindi katanggap-tanggap.

Konklusyon

Marami ang maaaring magtanong, ano ang pinili ng may-akda ng artikulong ito para sa kanyang sarili? At pumili siya ng laki ng tab na 4 na pamilyar na espasyo. Hindi ako nakahanap ng sapat na dahilan para gumamit ng mga puwang upang ang aking code ay makikita ng isang tao na hindi nagtakdang itakda ang indentasyon ng kanilang code editor sa de facto na pamantayan ng 4 na character.

Tulad ng para sa Notepad mula sa Windows, na walang setting ng laki ng tab, at iba pang katulad na mga editor na pinipilit ang mga tab na maging 8 character, hindi ko maisip ang isang dahilan kung bakit bubuksan ng isang programmer ang aking code sa kanila, samantalang sa loob ng mahabang panahon. Ang lahat ng mga operating system ay may maginhawang espesyal na mga editor para sa source code.

Ang pagtatrabaho sa isang notepad ay hindi cool. Ang sarap magtrabaho sa isang hex editor :)

Para sa mga matanong na developer, nananatiling may-katuturan ang isyu ng paggamit ng mga tab at puwang upang i-format ang code. Maaari ba silang palitan: halimbawa, 2 puwang bawat tab o 4? Ngunit walang iisang pamantayan, kaya minsan ang mga hindi pagkakaunawaan ay lumitaw sa pagitan ng mga developer. Bilang karagdagan, iba't ibang mga IDE at kanilang mga compiler ang humahawak sa mga tab nang iba.

Ang solusyon sa isyu ay karaniwang isang kasunduan sa pag-format ng mga panuntunan sa loob ng proyekto o programming language sa kabuuan.

Sinuri ng isang pangkat ng mga developer mula sa Google ang mga proyekto sa repositoryo ng Github. Sinuri nila ang code na nakasulat sa 14 na programming language. Ang layunin ng pag-aaral ay tukuyin ang ratio ng mga tab at espasyo - iyon ay, ang pinakasikat na paraan ng pag-format ng teksto para sa bawat wika.

Pagpapatupad

Para sa pagsusuri, gumamit kami ng umiiral na talahanayan kung saan naitala ang mga pangalan ng Github repository.

Tandaan natin na mga dalawang buwan na ang nakalipas lahat ng open source na Github code ay naging available sa anyo ng mga BigQuery table.

Gayunpaman, hindi lahat ng mga repositoryo ay pinili para sa pagsusuri, ngunit tanging ang nangungunang 400,000 mga repositoryo na may pinakamalaking bilang ng mga bituin na kanilang natanggap para sa panahon mula Enero hanggang Mayo 2016.

Mula sa talahanayang ito, nakuha ang mga file na naglalaman ng code sa 14 pinakasikat na programming language. Upang gawin ito, ang mga extension ng kaukulang mga file ay tinukoy bilang mga parameter ng sql query - .java, .h, .js, .c, .php, .html, .cs, .json, .py, .cpp, . xml, .rb, .cc, .go.

PUMILI ng a.id id, laki, nilalaman, binary, mga kopya, sample_repo_name , sample_path FROM (SELECT id, FIRST(path) sample_path, FIRST(repo_name) sample_repo_name MULA SA KUNG SAAN REGEXP_EXTRACT(path, r"\.([^\.]* )$") IN ("java","h","js","c","php","html","cs","json","py","cpp","xml", "rb","cc","go") GROUP BY id) a SUMALI b SA a.id = b.id

864.6s ang lumipas, 1.60 TB ang naproseso

Medyo matagal bago makumpleto ang kahilingan. Hindi ito nakakagulat, dahil kinakailangan na magsagawa ng join operation sa isang talahanayan ng 190 milyong mga hilera na may isang talahanayan ng 70 milyong mga hilera. Isang kabuuang 1.6 TB ng data ang naproseso. Ang mga resulta ng query ay makukuha sa address na ito.

Naglalaman ang talahanayan ng mga file nang wala ang mga duplicate nito. Nasa ibaba ang kabuuang bilang ng mga natatanging file at ang kabuuang sukat ng mga ito. Ang mga duplicate na file ay hindi kasama sa pagsusuri.

Pagkatapos noon, ang natitira na lang ay bumuo at ilunsad ang panghuling kahilingan.

PUMILI ng ext, mga tab, puwang, countext, LOG((spaces+1)/(tabs+1)) lratio FROM (SELECT REGEXP_EXTRACT(sample_path, r"\.([^\.]*)$") ext, SUM( best="tab") na mga tab, SUM(best="space") space, COUNT(*) countext FROM (SELECT sample_path, sample_repo_name, IF(SUM(line=" ")>SUM(line="\t"), "space", "tab") SA LOOB NG RECORD pinakamaganda, COUNT(linya) SA LOOB NG RECORD c MULA SA (PILI SA KALIWA(SPLIT(nilalaman, "\n")), 1) linya, sample_path, sample_repo_name MULA SA PAGKAKAROON NG REGEXP_MATCH(linya, r"[ \t]")) MAY c>10 # hindi bababa sa 10 linya na nagsisimula sa espasyo o tab) GROUP BY ext) ORDER BY countext DESC LIMIT 100

Lumipas ang 16.0s, naproseso ang 133 GB

Ang pagsusuri sa bawat linya ng 133 GB ng code ay tumagal ng 16 na segundo. Ang parehong BigQuery ay nakatulong upang makamit ang ganoong bilis.

Kadalasan, ang mga tab ay matatagpuan sa C, at ang mga puwang ay kadalasang matatagpuan sa Java.

Bagama't para sa ilan ang ratio ng ilang mga simbolo ng kontrol ay hindi mahalaga, at ang mga debate sa paksang ito ay tila malayo. Hindi rin ito mahalaga para sa ilang IDE, na nag-iimbak ng mga tab bilang isang bilang ng mga puwang. Mayroon ding mga IDE kung saan maaaring manu-manong i-configure ang numerong ito.

Ilang oras na ang nakalipas, ang problemang ito ay nilalaro sa seryeng "Silicon Valley". Hindi nagkasundo ang lalaki at babae sa isyu sa pag-format. Bilang isang resulta, ang lumang holivar ay hindi lamang humantong sa hindi pagkakaunawaan sa propesyonal, ngunit lumikha din ng mga problema sa kanilang mga personal na relasyon.

Ang isa sa mga palatandaan ng isang mahusay na istilo ng programming ay ang pagkakapare-pareho—mas kaunting mga sorpresa, mas mabuti. Ang pagkakapare-pareho ay ginagawang mas madaling basahin ang isang programa, pangunahin sa pamamagitan ng pagbabawas ng mga abala. Ginagabayan din nito ang mga mata ng mambabasa, halimbawa, ang pagkakapare-pareho sa lokasyon ng isang function o koneksyon ng mga file ay ginagawang mas madaling mahanap ang mga ito sa hinaharap. Ginagawa rin nitong mas madali ang paglutas ng mga problema ng istilo, na tumutulong sa mambabasa na mas madaling masanay dito.

Kaliwanagan ng code

Ang magandang istilo ay kinakailangan upang matiyak na ang iyong programa ay malinaw, naiintindihan, at madaling baguhin. Kung may pagdududa, piliin ang pinaka-naiintindihan na pamamaraan para sa problema. Tandaan na lahat ng iyong isusulat, malamang na kailangan mong muling basahin. Gawing mas madali ang iyong hinaharap at makakuha ng kalinawan kaagad.

Mga Puwang at Pag-format

Maaaring mabawasan ng whitespace ang strain sa mga mata ng mambabasa. Dahil binabalewala ng compiler ang mga puwang, malaya kang ilagay ang mga ito kahit saan at i-format ang iyong code gamit ang mga puwang gayunpaman gusto mo. Kung gagawin mo ito nang matalino, ito ay makakatulong.

Ginagamit ang mga puwang upang i-format ang indentation, espasyo sa paligid ng mga statement, function signature, at ilagay ang mga argumento ng function. Siyempre, hindi lang ito ang mga lugar kung saan ginagamit ang whitespace, ngunit dapat itong magbigay sa iyo ng ideya ng mga lugar kung saan maaaring gamitin ang whitespace upang mapabuti ang pagiging madaling mabasa.

Indentation

Kung hindi mo pa na-indent ang iyong code, gagawin mo ito sa lalong madaling panahon. Ito ay talagang kinakailangan dahil makakatulong ito sa iyong mabilis na mahanap ang mga kinakailangang linya ng kontrol ng code o makahanap ng mga error dito. Dapat mong i-indent ang bawat bloke ng code:

Kung (totoo) ( // block ng code )

Mga istilo ng bracket

Mayroong maraming mga paraan upang i-indent ang code, at marami sa mga ito ay nakasalalay sa kung saan mo ilalagay ang mga panaklong. Mas gusto ng ilang tao ang istilong ginamit sa itaas. Mas gusto ng ilang tao ang istilong ipinapakita sa ibaba:

Kung (totoo) ( // block ng code )

Mayroong iba pang mga estilo:

Kung (totoo) ( // block ng code )

Aling istilo ng brace ang pipiliin mo ay nasa iyo, bagama't inirerekomenda ko ang paggamit ng parehong istilo ng brace para sa lahat ng nagtatrabaho sa parehong proyekto. Anyway, may mga argumento para sa bawat istilo. Mahusay na gumamit ng istilo ng bracket na nagbibigay-daan sa iyong magkasya ng mas maraming code sa screen hangga't maaari, ngunit ang pagkakapare-pareho ay kasinghalaga.

Lapad ng Indent

Kung magkano ang gusto mong i-indent ay isang bagay ng personal na kagustuhan—sa anumang kaso, sa pangkalahatan ay pinakamahusay na pumili ng laki ng indent na sapat na maliit upang magkasya ang code sa isang screen. Itinuturing kong makatwiran at nababasa ang anumang lapad ng indentation sa pagitan ng 2 at 8, bagama't nalaman kong higit sa apat na espasyo para sa indentation ay maaaring magresulta sa mga linyang masyadong mahaba.

Sa pangkalahatan, ang pinakamahusay na solusyon para sa mga linya na masyadong mahaba ay upang bawasan ang pagiging kumplikado ng code, o hindi bababa sa i-pull out ang ilan sa mga functionality sa magkahiwalay na mga function. Babawasan nito ang bilang ng mga antas ng indentation at maaaring gawing mas nababasa ang code (kung ginawa nang tama).

Mga tab at espasyo

Medyo may kontrobersya sa paggamit ng mga tab o espasyo. Tandaan na hindi ito katulad ng pagtatanong kung nag-indent ka gamit ang mga puwang o tab. Hinahayaan ng karamihan ng mga tao ang text editor na malaman ito para sa kanila (o piliing i-convert ang mga tab sa mga puwang).

Ang tunay na problema sa mga tab at espasyo ay kung ano ang mangyayari kapag may nagbukas ng iyong code. Maaari kang magtakda ng mga tab para sa anumang bilang ng mga column, at ang taong nagbubukas ng iyong code ay maaaring magkaroon ng ibang lapad ng tab. Ito ay maaaring nakakalito kahit na may mahusay na na-format na code. Ang paggamit lamang ng mga puwang ay nag-aayos ng problemang ito dahil lalabas ang lahat ng pareho.

Minsan may makikitang disenteng code formatter sa text editor, ay maaaring makatulong na mapagaan ang problemang ito sa pamamagitan ng muling pag-format ng code. Maaari mo ring baguhin ang iyong sariling mga setting upang maipakita nang tama ang code (bagaman hindi ito masyadong maganda).

Ang pinakamahusay na solusyon, kung magpasya kang gumamit ng mga tab, ay maging maingat sa kung ano ang ginagamit mo sa mga ito. Ang tunay na problema, sa katunayan, ay lumitaw kapag ang mga tab ay ginagamit hindi lamang para sa indentation, ngunit bilang isang mabilis na paraan upang ilipat ang apat o walong character sa kanan. Halimbawa, tingnan natin ang sumusunod na code:

Kung (long_term_one && long_term_two) ( // code )

Kung ang pangalawang kundisyon ay na-format gamit ang tab na naka-indent ng apat na puwang na sinusundan ng isang puwang, pagkatapos ay kapag binuksan sa isa pang editor na may lapad ng tab na walong puwang, ang code ay magmumukhang pangit:

If (long_term_one && long_term_two) ( // code sa katawan ng selection statement )

Kung ginamit ang mga puwang para sa pag-format, ipapakita nang tama ang code:

If (long_term_one && long_term_two) ( // if statement code)

Maling paggamit ng mga espasyo

Nasa sa iyo kung gaano karaming mga puwang ang iyong gagamitin. Ngunit, ito ay nagkakahalaga ng pagkakaroon ng kamalayan sa ilang mga isyu. Una, ang mas maraming puting espasyo na tumutulong na bigyang-diin ang lohika ng iyong programa, mas mabuti. Ngunit hindi mo nais na ang iyong mga puwang ay magulo sa iyo. Maaaring hindi ka malito nito sa ngayon, ngunit maaaring malito ka sa hinaharap, o sinumang magbabasa ng iyong code. Ano ang hitsura ng masamang pag-format?

Kung(totoo)++i;

++j;

Sinasabi sa amin ng indentation na ang dalawang expression ay gagana kapag ang conditional statement ay naisakatuparan, ngunit hindi iyon ang aktwal na nangyayari. Kapag sinusubaybayan mo ang isang error sa syntax sa daan-daan o libu-libong linya ng code, matatapos mo lang ang pag-skimming sa code sa halip na maingat na suriin ang bawat linya. Kung mas madali para sa iyo na suriin ang iyong code at piliin ang mahahalagang detalye, mas mabilis kang makakahanap ng mga bug na gumagapang nang hindi napapansin. Gaya sa halimbawang ito, ang unang pahayag lamang ang nabibilang sa katawan ng pahayag na kung.

May mga pagkakataong ayaw mong baguhin ang mga istilo para sa kapakanan ng isang elemento, o kailangan mong magpasok ng ilang puwang sa teksto para sa mga kadahilanan ng aesthetics o estilo ng pag-format ng teksto. At dito lumitaw ang tanong: "Paano magdagdag ng puting espasyo sa HTML upang ang teksto ay maipakita nang maganda, at sa parehong oras maiwasan ang redundancy ng code?" Upang gawin ito, tingnan natin ang mga uri ng mga puwang at mga halimbawa ng kanilang paggamit sa HTML code.

HTML na hindi nakakasira ng espasyo Sa mga kaso kung saan hindi mo kailangang paghiwalayin ang mga bahagi ng teksto sa isa't isa, makakatulong ito hindi nasisira na espasyo

, ang code na ganito ang hitsura:

Ito ang tinatawag na "non breaking space".

Mga halimbawa ng paggamit ng non-breaking space:

Atbp dahil E. Veltistov 11 libong rubles

Manipis na espasyo Ang HTML whitespace code na tinakpan namin sa itaas ay nasa lahat ng dako. Ngunit may mga pagkakataon na ang isang regular na espasyo ay lumalabas na masyadong "malaki". Pagkatapos ito ay pinalitan ng manipis na espasyo

 

. Ito ay isang puwang na isang-kapat ng lapad ng font na ginamit. Ang isang manipis na espasyo ay ipinahiwatig tulad ng sumusunod:

at ginagamit, para sa karamihan, upang hatiin ang mga digit ng mga numero, halimbawa, "$15,000,000" ay dapat isulat nang ganito:

$15,000,000 Tandaan: Maaaring hindi maipakita nang tama ang manipis na espasyo sa mga mas lumang bersyon ng ilang browser, ngunit sa lahat pinakabagong bersyon

mahusay na gumagana.

Iba pang mga uri ng mga puwang sa HTML

• Bilang karagdagan sa mga pinaka-nauugnay na uri na tinalakay namin sa itaas, may iba pa.
•   - puwang ang haba ng titik N;
•   - puwang ang haba ng titik M;
• ‌ - zero-length na hindi nagkokonekta na character;

$15,000,000 Kung kailangan mong maglagay ng maraming puwang sa isang row, palibutan ng tag ang text

:

 
Tagabuo ng website na "Nubex"
Space gamit ang CSS
Ang opsyon ng paglikha ng mga tab (indentation) gamit ang CSS ay maaaring malutas gamit ang sumusunod na pamamaraan:

   Tagabuo ng website na "Nubex"
".
Gusto kong tumugon sa mga komento, ngunit dahil sa dami at pagnanais na maging malaya mula sa orihinal na paksa, nagpasya akong lumikha ng isang bagong paksa.
Kaya, sa ilalim ng hiwa - bakit ang mga tab ay mas mahusay kaysa sa mga puwang, ang pinaka makabuluhang maling kuru-kuro tungkol sa mga tab at kung paano gamitin ang mga ito nang tama.
Magsimula tayo sa katotohanan na karamihan sa mga tao (kahit sa Habré) ay mas gusto ang mga tab.
Sa katunayan, ang kakaiba ay marami pa rin ang hindi nakikilala sa pagitan ng indentation at alignment.  Well, ito ang indentation: 
para sa (int i = 0; i< 10; i++) {
 if (a[i] == 0)
 do_something(i);
}
 
At ito ang pagkakahanay: 
int some_variable = 0;  int v1 = 0;
Ang una ay maaaring gawin sa parehong mga tab at puwang, ngunit kapag ginawa mo ito sa mga tab, lahat ay maaaring ayusin ang lapad ng indent sa kanilang sariling panlasa at walang napupunta kahit saan.
Ang IDE ay may opsyon na Smart Tab para dito:
Kung gumamit ka ng mga tab nang tama (ibig sabihin, para lamang sa indentation), madali mong mababago ang laki ng mga tab nang hindi nilalabag ang iyong istilo ng programming.
2 puwang bawat tab: 

5 puwang bawat tab: 

9 na puwang bawat tab: 
Kaya anong mga problema ang nawawala sa atin?
1. Maaaring ayusin ng bawat programmer ang haba ng tab upang umangkop sa kanyang panlasa. Laging gumagana sa pagsasanay.  Kapag mataas ang nested ng code, maaari mong itakda ang lapad ng tab sa dalawang puwang, kung hindi - sa apat. 
2. Mas madaling magtrabaho sa mga third-party na aklatan.  Sinusuportahan ng ilang library ang isang istilo na may lapad na tab na dalawang puwang, ang ilan ay may lapad na apat na puwang.  Ang paggamit lamang ng mga tab ay hindi nagpapataw ng mga paghihigpit sa estilo. 
Sipiin ko ang ilang mga saloobin mula sa nakaraang paksa: 
Mahirap magtrabaho sa mga proyekto na gumagamit ng mga library na naglalaman ng mga tab sa pagsubok.  Sabihin nating sa isang library ang tab ay 3 character, sa isa pa ay 4 na character.  At gumamit ka ng 2 simbolo sa proyekto.  Bilang resulta, ang ilang bahagi ng iyong code ay ipapakita sa editor na may maling pag-format.

Sa katunayan, sa mga proyektong gumagamit ng tabulasyon ay walang ganoong mga problema - dahil ang tabulasyon ay walang sukat, ngunit ang sabay-sabay na pagsuporta sa isang pares ng mga aklatan na may iba't ibang laki ng space-tab ay nagiging problema, dahil  Hindi mo na magagamit ang tab (upang palitan ng IDE ang mga tab ng mga puwang).  Siyempre, may pagkakataon na malutas ang problemang ito sa iba't ibang mga proyekto na may iba't ibang mga setting, ngunit ito ay isang saklay pa rin, at ito ay pumuputok pa rin sa iyong isip mula sa iba't ibang laki ng pugad. 
Madaling ipasok ang isang kambing sa hardin.  Sabihin nating ang iyong tab ay katumbas ng 4 na espasyo.  May nag-tweak ng kaunti sa pamamagitan ng paggamit ng ibang laki ng tab o tahasang paglalagay ng mga puwang.  Ang lahat ay mukhang maayos para sa kanya, ngunit ang iyong linya ng code ay mapupunta sa isang lugar.

Gayundin, ang tabulasyon ay walang sukat.  Ang problemang ito ay nangyayari lamang sa mga proyektong gumagamit ng mga espasyo.  Kung saan ginagamit ang mga tab, maaari silang maging hindi bababa sa 2 o 10 character ang lapad. 
Kailangan mong patuloy na ayusin ang iba't ibang mga editor sa laki ng tab na kailangan mo.  Kahit na kailangan mo lang tingnan ang code nang walang pag-edit.  Kung hindi, ang lahat ay babagsak.  Ito ay lalong hindi maginhawa kapag kailangan mong gawin ang iyong code sa isang third-party na makina.

Sabihin nating binuksan ko si Kate para mabilis na ayusin ang code sa ilang file.  Oops, dalawang puwang ang laki ng tab.  Kailangan mong pumunta sa config.  At sa susunod na file mula sa isa pang library mayroong apat na puwang.  Kakailanganin mong gumamit ng espasyo sa halip na isang tab para sa indentation, grabe.  Walang ganoong problema sa mga tab. 
Mga karagdagang komplikasyon para sa mga nagtatrabaho nang sabay-sabay sa mga proyekto kung saan ang mga pamantayan ng coding ay nangangailangan ng iba't ibang mga indentasyon.  Kung ang mga pamantayan ay nangangailangan ng paggamit ng tabulasyon, kung gayon ito pa rin ang palaging masakit na ngipin.  Sa kaso ng mga puwang, muli ang lahat ay mas simple.

Tulad ng tinalakay sa itaas, ang problemang ito ay partikular na umiiral sa mga problema, at hindi sa mga tab. 
Bilang karagdagan, ang mga puwang ay may mga kawalan tulad ng imposibilidad ng mabilis na paglipat gamit ang mga arrow ng keyboard (nag-click sa bawat puwang, at hindi sa pamamagitan ng isang bloke), ang posibilidad na magkamali (paglalagay ng 3 puwang sa isang lugar sa halip na 4, na sumisira sa karagdagang istraktura), isang pagtaas sa laki ng file at marami pang iba.
Konklusyon
Ang mga puwang ay walang anumang makabuluhang kalamangan sa mga tab, at hindi namin pinipilit ang programmer sa isang balangkas at hindi siya pinipilit na magdusa sa mga tab na masyadong maliit (o masyadong malaki) para sa kanya. 
Pangunahing
Hindi talaga mahalaga kung ano ang iyong ginagamit.  Mahalagang subaybayan mo ang pagkakasunud-sunod ng iyong code at palaging nananatili sa parehong estilo.  I-on ang pagpapakita ng mga tab/space, minsan baguhin ang laki ng tab sa ibang laki at i-on ang iyong mga mata sa code upang matiyak na hindi ka nagpasok ng mga puwang sa halip na mga tab o tab sa halip na mga puwang sa isang lugar. 
UPD: tandaan ayon sa mga komento
Matagal ko nang gustong magsulat ng artikulo tungkol sa mga tab.  Ngunit hindi tungkol sa "Mga Tab VS Space", ngunit tungkol sa kung paano gamitin nang tama ang mga tab.  Kinumpirma ng mga komento na marami ang hindi nakakaalam tungkol sa indentation at alignment.  Ang punto ng artikulong ito ay hindi lahat na lahat ng gumagamit ng mga tab ay tama.  May mga pamantayan sa coding, may mga tampok ng wika, at may mga personal na kagustuhan. 
Ang pinakamahalagang bagay ay ang malaman ang mga patakaran para sa indentation at magamit ang mga ito.  At huwag kailanman paghaluin ang dalawang estilo.  Tandaan - hindi "huwag paghaluin ang mga tab at espasyo", ngunit huwag paghaluin ang dalawang estilo. 
Sa personal, inirerekumenda ko ang paggamit ng diskarte na inilarawan sa paksa, ngunit kung ang mga pamantayan ng code na iyong pinagtatrabahuhan ay hindi nagpapahiwatig ng ibang bagay.