400.000 projekter kan ikke tage fejl: Mellemrum slår tabulator

31. august 2016 kl. 10:1528
Skal man bruge mellemrum eller tabulator til indrykning i programkode? En Google-udvikler har set nærmere på én milliard filer på Github.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Mellemrum eller tabulator? Den ene er universel og entydig, den anden er effektiv og fleksibel, men valget mellem dem deler vandene, når udviklere skal blive enige om, hvordan man bedst laver indrykning i programkode.

Nu har Google-udvikler Felipe Hoffa set nærmere på én milliard filer på Github fordelt på 400.000 open source-repositories eller projekter, og konklusionen er en overbevisende sejr til mellemrum.

Spørgsmålet om tabulator eller mellemrum blev trukket frem i lyset, da det blev gjort til et centralt punkt i tv-serien Silicon Valley i den seneste sæson af serien.

Analysen blev gjort mulig gennem et tidligere projekt, Google annoncerede i juni, Big Query, hvor Google har indsamlet mere end tre terabyte data fra 2,8 millioner open source-projekter på Github med det formål at kunne analysere på en enorm mængde kode fra mange forskellige udviklere.

Artiklen fortsætter efter annoncen

Det kan eksempelvis bruges til at finde frem til, hvor mange gange udviklere har skrevet en kommentar i koden såsom 'This should never happen'.

Og nu har Felipe Hoffa altså afgjort kampen mellem mellemrum og tabulator. Det mest interessante er dog, at der er variation mellem forskellige programmeringssprog. I et sprog som Python er indrykning vigtig, og her er mellemrum standard, så det er ikke overraskende, at Python-koden næsten udelukkende bruger mellemrum.

Google er til gengæld stor fortaler for tabulator, og der er ingen Go-kode i analysen, hvor udviklere har veget fra kursen og sneget mellemrum ind.

Sproget C skiller sig også ud ved at hælde mest mod tabulator, men med en næsten ligelig fordeling mellem de to.

Analysen har kun set på filer fra de 400.000 højst rangerede respositories på Github, ligesom filerne skulle have mindst 10 kodelinjer med indrykning.

28 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
27
4. september 2016 kl. 12:56

Rigtig dårlig ide - ødelægger diff af din kode!!

Nu kan man jo diffe med ignorering af whitespace.

I øvrigt, hvis jeg skal overtage ansvaret for noget kode starter jeg med at fjerne alle tabs (og nogle andre småting som ikke er relevante her), checke ind og lave et build med samme versionsinfo. Så kan jeg verificere, at output er identisk (embedded sw, ikke windows sw).

26
4. september 2016 kl. 10:02

Rigtig dårlig ide - ødelægger diff af din kode!!

24
1. september 2016 kl. 19:14

Hvis man har brug for at splitte sin if statement op i to så i stedet for at beholde den ene på samme linje, så lav en ny linje for hver ny condition.

Ja, det er hvad jeg gør. Også selv om det som en anden siger, er layout, ikke programmering.

Det er ganske vigtigt for mig, at jeg kan se tilbage på gammel kode og umiddelbart danne mig indtryk af, hvad det gør. Udfra remarks selvfølgelig, men kodeopstillingen giver også gode clues. Ligesådan gør selvfølgelig valg af navne på variable og funktioner.

Til gengæld, hvis koden danner f,eks, HTML, så er selve HTMLens opstilling ikke så vigtig på output. Samme med JS og CSS. Her laver jeg gerne minifying.

Det vigtigste er, at selve sourcen fra min side er readable.

23
1. september 2016 kl. 15:53

Tabulator hvis dagnummeret er et primtal? Jonathan Swift ville have elsket denne debat. Dumt spørgsmål (jeg har ikke gidet undersøge det): Hvis man altid autoformatterer kode, der ikke lige passer til ens personlige stil, bare fordi, får man så ikke en frygtelig masse betydningsløse ændringer, når man graver i versionshistorikken på et program? Man skal tænke lige så meget på dem, der kommer efter en, som på sig selv. Mindst.

22
1. september 2016 kl. 10:34

Nej, der bliver indsat 4 enkeltstående mellemrum, I stedet for et \t når man trykker på tab.

Selv er jeg fløjtende ligeglad om der er det ene eller andet i min kode. Men det kunne aldrig falde mig ind at trykke gentagne gange på en knap i stedet for 1/4 så mange tryk på en anden. Selvfølgelig med mindre at sproget eller code convention på arbejdet dikterer andet

21
1. september 2016 kl. 06:08

Mange af de projekter jeg arbejder med har haft flere udviklere inde over. Hver har haft sin egen tilgang til indrykninger. Når jeg møder en fil som ikke matcher min måde at gøre det på beder jeg IDE'en autoformatere koden efter min preference. Det har endnu aldrig ført til fejlende tests eller fejl i UI. Men jeg arbejder heller ikke i sprog hvor indrykning er en del af syntaksen.

20
31. august 2016 kl. 23:51

En space og en tabulator indrykning er det samme.

To space indrykning og to tabulator er ikke det samme.

Flere space indrykning (bekrig selv hinanden med antal) er layout.

Rigtige programmører bevæger sig ikke ud i layout, kun kode. Vælg selv din indryknings-layout-antal.

19
31. august 2016 kl. 22:45

Hvis man har brug for at splitte sin if statement op i to så i stedet for at beholde den ene på samme linje, så lav en ny linje for hver ny condition.

  1. ---|if ($foo) {
  2. ---|---|if ($bar == $baz &&
  3. ---|---| $qux > 10) {

Så flyt begge conditions ned. Så er der styr på indenteringen igen.

  1. ---|if ($foo){
  2. ---|---|if (
  3. ---|---|---|$bar == $baz &&
  4. ---|---|---|$qux > 10 &&
  5. ---|---|---|$tabsErBedst = true // Nej der mangler ikke et = :-)
  6. ---|---|){

18
31. august 2016 kl. 19:24

Er det efterhånden ikke ligegyldigt. Vi har IDE'er som abstrahere mange gamle udviklings paradimer såsom space vs tabs. Så længe det er konsekvent igennem kodebasen.

16
31. august 2016 kl. 18:55

I serverside kode, som kun jeg ser, bruger jeg altid bare tabs. Det fylder mindre end spaces, man kan selv sætte hvor mange spaces en tab skal fylde (jeg har den konsekvent på 3), og så kan man sætte en fast afstand ved et enkelt tryk.

Mine indrykninger er så også meget kosmetiske alene for at lette overskuleligheden, og jeg deler gerne condition udtryk (f.eks. en IF med mange OR eller AND) over flere linjer for at holde kort enkelt linjelængde, hvilket måske kan synes at gå over gevind for nogle.

Readability er ét og alt.

15
31. august 2016 kl. 18:51

Visual studio oversætter et tryk på tab til spaces.

14
31. august 2016 kl. 18:45

Det er vel ikke en appeal to popularity fallacy, hvis målet er standarder for samarbejde i f.eks. et team.

Jeg synes, hvis man har et IDE, hvor man kan bruge TABs men at det oversættes til spaces for andre, eller man automatisk kan indsætte korrekt antal spaces med tryk på på TAB ell. lign., så ville jeg i et givent project benytte hvad flertallet benytter. Udadtil. I min egen kode bruger jeg konsekvent TABs.

Visse open source projecter har sat en standard for deres kode med f.eks. spaces, så ville jeg bruge det til dem, men stadig internt arbejde med tabs.

Så det er nok ikke så meget hvad folk selv foretrækker, mere om deres IDE er gearet til at følge den "officielle" standard for et project.

13
31. august 2016 kl. 18:43

Ja, "The Design of Design" er en skøn bog.

12
31. august 2016 kl. 17:35

Hej PHK - kan du evt. give os et kort svar uden at jeg nødvendigvis må læse bogen?

I øvrigt bruger jeg space i min kode, bare til orientering... men argumentationen med at flertallet har ret dur i min optik overhovedet ikke.

11
31. august 2016 kl. 16:20

-er fordi det er det der fungerer bedst i mange IDEer - det svære.

I min foretrukne editor betyder et tryk på TAB tasten, at min kode bliver rykket ind (eller ud) så den, på en intelligent måde, passer med koden på linjen oven over. Det er således aldrig nødvendigt at fedte rundt med tabulator og mellemrumstegn til indrykning.

Jeg har så valgt, at indrykningsfunktionen skal benytte mellemrum, så koden ikke ændrer udseende når den vises på konsollen med diff, grep, patch m.v. - men det er jo ikke relevant for alle...

Nogle har altså god grund til at vælge det ene og andre har god grund til at vælge det andet. Så må man bare håbe, at de ikke skal arbejde på den samme kode. :-)

10
31. august 2016 kl. 14:10

Jeg bruger altid tabs på lige linier og spaces på ulige.

Det er vigtigt at kunne indgå kompromis.

9
31. august 2016 kl. 14:07

...tilbage i 70'erne, løb vi ofte rundt i gården og råbte "500.000.000.000 fluer kan ikke tage fejl - SPIS LORT!"

8
31. august 2016 kl. 12:46

Du skal læse Frederick P. Brooks bog "Design of design", der får du svaret.

6
31. august 2016 kl. 12:28

Men hvorfor skal andre udviklere bestemme om jeg foretrækker at indrykningen skal være 2, 4, 8 eller noget helt andet. Med tabulator styrer jeg selv hvordan koden ser ud.

Al fred være med det, så længe du konsekvent bruger tabs til al indrykning, og så mellemrum til at justere ting under hinanden. Fx, hvis "---|" repræsenterer et tab:

[perl] ---|if ($foo) { ---|---|if ($bar == $baz && ---|---| $qux > 10) { [/perl]

(Læg mærke til, at det er mellemrum der bruges til at justere $qux under $bar.)

Min erfaring er, at her vil mange der bruger tabs være fristet til også at bruge tabs til at justere $qux under $bar:

[perl] ---|if ($foo) { ---|---|if ($bar == $baz && ---|---|---|$qux > 10) { [/perl]

Men så er det jo, at man ikke kan justere tab-størrelsen uden at ødelægge formatteringen:

[perl] -|if ($foo) { -|-|if ($bar == $baz && -|-|-|$qux > 10) { [/perl]

Derfor er jeg stærk fortaler for mellemrum, behandlet som tabs af ens editor. Så kan man manipulere dem som var de tabs, og koden vil se korrekt indrykket ud for alle.

5
31. august 2016 kl. 11:16

Men hvorfor skal andre udviklere bestemme om jeg foretrækker at indrykningen skal være 2, 4, 8 eller noget helt andet. Med tabulator styrer jeg selv hvordan koden ser ud.

4
31. august 2016 kl. 11:15

Når jeg programmer i visual Studio så benytter jeg tabs.

Når jeg programmer i Linux 'vi(m)' så er vim sat til at oversætte tabs til mellemrum.

3
31. august 2016 kl. 11:03

Men mellemrum ser koden ens ud i alle editors, samt diff i konsollen.

2
31. august 2016 kl. 10:46

Jeg hælder mest til tabulator. Ved kode med mange indryk efter hinanden er det bare nemere at skelne mellem tabulator end om mellemrum blev ramt 1,3 eller 5 gange.

Hvad med jer?

1
31. august 2016 kl. 10:30

Det er da hyggeligt nok, men ku de ikke lige søge igennem efter OWASPtop10 nu de er i gang.. Eller har andre gjort det allerede?