Tabulator eller mellemrum? Silicon Valley-serien rammer et ømt punkt

Igen mener jeg, det bør være editorens (og dermed den enkelte brugers) valg, hvordan linier bliver brudt, om tuborg-paranteser skal ned på næste linie osv. Det har ingen betydning for programflow eller logik, og det handler kun om, at den enkelte bruger skal have det bedst mulige overblik over koden.

Du beskriver en utop,i hvor alle har en editor der læse og parse alle sprog og præsentere dem, som brugerne ønsker. Og gemmer i et standardiseret og kanonisk format, så versionsstyringssystemer ikke påvirkes af de forskellige formatteringer. Men i den utopi kan det jo være lige meget om man bruger tabs eller mellemrum. Man kan ligesågodt bare helt lade være med indrykke i kodefilerne, det ens editor jo gøre for en.

I den virkelige verden , er der altid nogen, der lige laver et par rettelser i notepad, kate, libreoffice osv og committer det.

I fx JavaScript kan argumentlister til funktioner nemt fylde tusindvis af "normale" linier. Så hvis man ikke ombryder dem, vil det være ret ulæseligt for folk, der ikke har en smart editor. Og versionnsstyringssystemer vil producere nogle meget store diffs.

Man kan lade den enkelte bruger vælge mellem tabs og mellemrum. Og man kan lade den enkelte bruger vælge mellem editors.

Men i praksis fungerer det ikke godt, at lade den enkelte bruger vælge mellem begge dele.

At du vil sidde og aligne ting bekræfter mig kun i at space-fortalere bruger for meget tid på præsentation i stedet for semantik

myObject.setMaterial(albedo: Texture(contentsOfFile: ...),
                     glossiness: Texture(...),
                     normal: Texture(...), 
                     reflection: Texture(...),
                     coatingThickness: 100.0,
                     ior: 1.67,
                     transparency: false)

Alt andet lidt er det en semantisk logisk måde at præsentere det på. At det så præsentationsmæssigt også er mere tiltalende end verdens mest irriterende metodekald, er en added bonus. Så synes ikke det er helt fair, du affejer det som ren visuel lir uden semantisk indhold.

Så en browser rundt i sourcen, autoreplacer tabs med spaces, gemmer filerne, og committer ændringerne til hvad end source repo man bruger?

Hvis jeg husker rigtigt, så fungerede ældre versioner af PVCS ved at have en kopi af det kurante sourcetræ, og så en database med ændringer historisk og i div branches.

Hvis permissions så ikke var sat rigtigt op (og det var der vist en historisk grund til de ofte ikke var) kunne man browse direkte i det kurante træ og viewe, låse, og ændre filer helt uden om den normale check in/out mekanisme...

Anyway, det vigtigste med hensyn til tab/space (og kodestil, for den sags skyld) er konsistens. Sørg for at alle folk på et projekt følger de samme regler. Lad være med at have de tåbelige commit-wars på indentering og formatering, der udover at være barnlige gør det besværligt at se hvad der rent faktisk er ændret.

Jeg bryder mig ikke om Gos fascistoide tilgang, og jeg bryder mig heller ikke om formaterings stilen (det gør ophavsmændene vist ikke engang fuldt ud) - men der er ret stor værdi i den konsistens, det giver.

Hvis du bruger tabs, så vil de to linjer kun se korrekte ud med en tabulatorafstand, der matcher forfatterens.... og så er vi ligevidt. Næh, du... Mellemrum. Så er der ingen overraskelser.

At du vil sidde og aligne ting bekræfter mig kun i at space-fortalere bruger for meget tid på præsentation i stedet for semantik. Nej, præsentationen er ikke ligegyldig, men jeg bryder mig ikke om den slags justeringer du foreslår - det kan gøres bedre med anden kodestil :)

I visse syntaktisk rige sprog er man nødt til at blande indentering og
"alignment". Et eksempel fra min egen Haskell:

Dit argument falder til jorden, når en linje brydes.

Ja. Men hvem siger, den skal brydes? Det er jo din subjektive præference, og en anden bruger, der skal læse din kode, vil måske foretrække, at den ikke brydes, eller måske endda brydes et andet sted. Andre har andre skærmopløsninger og vil måske synes, det er nemmere, hvis linien ikke er brudt.

Igen mener jeg, det bør være editorens (og dermed den enkelte brugers) valg, hvordan linier bliver brudt, om tuborg-paranteser skal ned på næste linie osv. Det har ingen betydning for programflow eller logik, og det handler kun om, at den enkelte bruger skal have det bedst mulige overblik over koden.

Og så vil jeg undskylde for at puste til ilden i en relativt ligegyldig diskussion - der er heldigvis masser af rigtige problemer at håndtere i stedet ;-)

... at udviklere bruger alt for megen tid på code styles og design patterns og overholdelse af disse, end at skrive forståelig, fornuftig, selvforklarende kode, gerne med et rimeligt antal inline kommentarer hvor det giver mening.

Som nævnt før: Indent with tabs, align with spaces

Og ja, det er lidt mere besværlig når de skal blandes sammen, men giver den fordel at man ikke skal trækkes med kode der har en efter ens egen opfattelse helt skør indenteringsstørrelse.

Så, hvis du absolut vil skrive koden på den måde:

>--obj.method(arg1=var1, arg2=var2,
>--...........arg3=var3, arg4=var4)

I øvrigt er det i min egen erfaring meget sjældent at jeg laver alignment og dermed bruger mellemrum. Jeg vil foretrække:

>--obj.method(
>-->--arg1=var1,
>-->--arg2=var2,
>-->--arg3=var3,
>-->--arg4=var4
>--)

Det er så en anden kodestilskamp man kan tage :-)

Dit argument falder til jorden, når en linje brydes.

obj.method(arg1=var1, arg2=var2,
           arg3=var3, arg4=var4)

Hvis du bruger tabs, så vil de to linjer kun se korrekte ud med en tabulatorafstand, der matcher forfatterens.... og så er vi ligevidt. Næh, du... Mellemrum. Så er der ingen overraskelser.

I visse syntaktisk rige sprog er man nødt til at blande indentering og "alignment". Et eksempel fra min egen Haskell:

  let out_nms     = patternNames out_idds
      is_redomap  = case orig_soac of
                      SOAC.Redomap{} -> True
                      _              -> False

Udtrykket er allerede indenteret med ét niveau. Derudover skal de to grene i case-udtrykket først indenteres med et antal mellemrum der afhænger af længden på is_redomap-navnet, og derefter have et ekstra indenteringsniveau. De to indenteringer kunne godt udføres med tabs (jeg har i stedet brugt to mellemrum), men så ville man have en kompliceret sammenblanding af tabs og mellemrum. Det er nemt at komme til at lave fejl i. Jeg tror faktisk den mest anvendte Haskell-oversætter,, GHC, advarer hvis den finder tabs i koden.

An attempt to introduce some facts and practicality into one of those arguments that just never goes away.

En af pointerne med at bruge TAB karakteren er at den har en fornuftig repræsentation i de fleste fornuftige editors (og cat og lignende) - også dem er ikke har fået læsset en extra omgang logik på, fordi nogle folk mener at man skal bruge en visuelt orienteret indrykning i stedet for en semantisk.

Det eneste nogenlunde fornuftige argument jeg har hørt for at bruge space er error/warning rapportering fra compilere - og det ser jeg ikke som et specielt stærkt argument.

An attempt to introduce some facts and practicality into one of those arguments that just never goes away.

Så en browser rundt i sourcen, autoreplacer tabs med spaces, gemmer filerne, og committer ændringerne til hvad end source repo man bruger? Der er vel ingen der ikke har deres kildekode i et repository af en eller anden art?

Så er den klaret!

Da Robert Griesemer arbejdede på Go-sproget for Google var han godt og grundigt træt af code-style guidelines. Google's Java og C++ style guidelines er kæmpestore og en ret stor del af alle codereviews kommer tilbage med steder for style-guiden ikke er fulgt.

Løsningen var hvad der i dag er "go fmt". Man laver selve Go-sproget ekstremt regulært, så de fleste indenteringer er rimeligt oplagte. Derefter laver man et værktøj der tvinger indentering igennem på en fast måde.

Nu kan du gøre hvad du har lyst til i din editor og skrive kode som du har lyst til, inklusive at skrive åbentlyst grim kode. Når du gemmer dit projekt sætter du din editor til at kaste koden gennem "go fmt" og derefter er koden rettet til pænt. På standardmåden.

Effekten er temmeligt imponerende. Stort set samtlige Go-projekter følger denne standard og det gør andres kode regulær og derved meget nem at læse. Rust har sidenhen taget den ide til sig, men det ville være rart om flere sprog gjorde det.

Men for at det fungerer skal selve sprogets syntaks være designet så der er en oplagt regulær måde at notere et program på. Ellers kan visse konstruktioner ende med at tage sig umådeligt grimt ud.

"go fmt" benytter tabs i stedet for spaces, men det betyder meget lidt. Du kan bare sætte din editor til at konvertere tabs til spaces og arbejde med det hvis du hellere vil.

Mht til indrykningsfølsom syntax, så er jeg ikke den store fan. Jeg foretrækker helt klart syntax der er LALR(1) håndterbart.

Jeg mindes så også hvad der sker når nogen har browset lidt rundt i source træet og åbnet en række filer - incl makefiler - med en editor der autoreplacede tabs med spaces

<en måneds tid senere>

"Hvorfor kommer der sære fejl fra ? Det har da ikke været rørt i halve/hele år ?"!

Fordi visning af tekst med tabulatortegn ikke er standardiseret.

Kan ikke understreges nok. Der er editorer/IDEs der bruger TAB-positioner (fx hver 8. tegn), dvs at har samme effekt som , men og afhænger om space'ne skubber dig over nexte tabstop. Og da du ikke umiddelbart kan se forskel på tab og space, så dukker det op igen og igen i "tilfældige" linier fordi du aldrig kommer i bund med det.

I embedded udvikling er det ikke ualmndeligt at (dele af) samme source bruges på adskellige platforme med hvert sit udviklingemiljø, ofte med flere aldrende komponenter. Tilsvarende hvis du regelmæssigt udveksler source med nogen der bruger et anderledes miljø er det bare lettere helt at undgå tabs en gang for alle med den rette editor/IDE opsætning.

I bund og grund handler det jo om, at udvikleren skal være så effektiv som muligt, og i alle andre sammenhænge er det jo naturligt, at man indstiller sine værktøjer til sig selv - om værktøjet så er en bil (justering af spejle, rat og førersæde), en cykel (sadel og gear) eller et IDE.

Helt enig, men der ligger også noget i at os udviklere godt kan være noget gode til at pålægge andre måder og skrive kode på. I nogle tilfælde lærer vi af det, men min personlige erfaring er at vi ofte skændes over noget der i langt de fleste tilfælde er ligegyldigt. Essensen er nok at vi er for dårlige til at diskutere hvor noget giver mening fremfor hvornår noget ikke giver mening.

Tab vs space -diskussionen er fra min optik et klassisk eksempel herpå.

Det giver f.eks. forkert indrykning, når en linje skal indrykkes, så dens start passer med en bestemt position på den foregående linje, og ikke blot er +/- to eller fire tegn i forhold til den foregående linje.

Det er ikke et krav at denne indrykning bevares, men skulle man finde det ønskværdigt, så er det ikke svært at indstille sin tab størrelse, så koden ser ud som oprindeligt ment.

Hvis oversætteren vil fortælle dig om en fejl på linje N, søjle M, hvordan beregnes søjleantallet så? Hvor mange søjler skal en tabulator tælle som? Én? Otte? Din editor har en opsætning af dette - skal C-oversættere nu også til at have en tabulatorkonfigurationsfil?

Her bruger du selvfølgelig clang, som vil pille et udsnit af koden ud og highlighte den specifikke fejl, så du kan se hvor den er - uanset om antallet af kolonner formelt passer. Så slipper du også for at sidde og tælle tegn ;-)

Men interessant argument - og umiddelbart det stærkeste, jeg har set hidtil.

Er der egentlig noget godt argument for mellemrum som indrykning?

Hvis oversætteren vil fortælle dig om en fejl på linje N, søjle M, hvordan beregnes søjleantallet så? Hvor mange søjler skal en tabulator tælle som? Én? Otte? Din editor har en opsætning af dette - skal C-oversættere nu også til at have en tabulatorkonfigurationsfil?

Det giver f.eks. forkert indrykning, når en linje skal indrykkes, så dens start passer med en bestemt position på den foregående linje, og ikke blot er +/- to eller fire tegn i forhold til den foregående linje.

Hvis man positionerer med mellemrum for at det, man skriver, skal passe med linien ovenover, har man jo allerede taget et aktivt valg om flere ting:

• Der anvendes mellemrum og ikke tabulator til indrykning
• Editoren anvender monospace-font (det gør de fleste som udgangspunkt, men giver det egentlig den bedste læsbarhed?)
• Andre udviklere finder ens specifikke layout lige så let-læselig som man selv gør

Og det er især sidstnævnte, jeg opponerer imod. Nogle foretrækker, at ingen linier overskrider bredden på en udskrift, mens andre er ligeglade, for de har en skærm fra efter år 2000 og kunne aldrig drømme om at udskrive koden på papir. Nogle foretrækker, at parametre på en funktion skrives på hver deres linie, mens andre foretrækker dem på en enkelt linie.

Al den slags små tilpasninger bør IMHO være noget, editoren håndterer efter brugerens ønske - for det er ikke væsentligt for kodens afvikling, om parametre står på en eller flere linier, eller om programmøren har en bred eller smal skærm. En kodestandard bør kun handle om ting, som editoren ikke med rimelighed kan forventes at tage højde for, og som derfor skal være afstemt med andre deltagere i projektet.

I bund og grund handler det jo om, at udvikleren skal være så effektiv som muligt, og i alle andre sammenhænge er det jo naturligt, at man indstiller sine værktøjer til sig selv - om værktøjet så er en bil (justering af spejle, rat og førersæde), en cykel (sadel og gear) eller et IDE.

Ja, hvis kodestandarden for det givne projekt af uransagelige årsager har valgt at du skal bruge 4 mellemrum i stedet for tabulator.</p>
<p>Men hvorfor dog anvende mellemrum, hvis tabulator kan gøre det lige så godt? Hvis man skal samarbejde med andre udviklere, er det vigtigt, der er en fælles standard, så git/svn ikke bliver forurenet med ligegyldige ændringer af whitespace.

Fordi visning af tekst med tabulatortegn ikke er standardiseret. Argumentet om, at tabulatortegn har den fordel, at du kan indstille din visning til din favoritindrykning holder ikke. Det giver f.eks. forkert indrykning, når en linje skal indrykkes, så dens start passer med en bestemt position på den foregående linje, og ikke blot er +/- to eller fire tegn i forhold til den foregående linje.

Hvis du ønsker at ændre på indrykning (eller anden layout) på et program, du ikke har skrevet selv, sådan at det passer til din kodestil, så brug et værktøj, der kender syntaksen i sproget. Så kan du lave de ændringer du vil: Indrykning, placering af krølleklammer og semikolon, blanktegn eller ej omkring infix operatorer, navngivning af variable (underscore eller camelcase), osv.

Er der egentlig noget godt argument for mellemrum som indrykning?

Mange mellerumstilhængere anfører at tabs kan give uheldige effekter når de bruges til justering længere ind på linjen. De har naturligvis ikke fattet en bønne:

"Indent with tabs, align with spaces"

>-->--int var1.........= 0,
>-->--....another_var..= 1,
>-->--....third_var....= 2;

Fordi du naturligvis har sat din editor til at indsætte 4 mellemrum hver gang du trykker TAB.

Ja, hvis kodestandarden for det givne projekt af uransagelige årsager har valgt at du skal bruge 4 mellemrum i stedet for tabulator.

Men hvorfor dog anvende mellemrum, hvis tabulator kan gøre det lige så godt? Hvis man skal samarbejde med andre udviklere, er det vigtigt, der er en fælles standard, så git/svn ikke bliver forurenet med ligegyldige ændringer af whitespace.

Vi mennesker er ikke ens - nogle foretrækker store indrykninger, mens andre hellere vil bruge skærmpladsen på koden.

Ved at bruge tabulator, kan den enkelte udvikler selv bestemme, hvordan det skal se ud, uden at gå på kompromis med den fælles kodestandard. Det lader sig ikke på samme måde gøre, hvis der bruges mellemrum som indrykning.

Er der egentlig noget godt argument for mellemrum som indrykning?

Hvis det kun handler om, at man partout vil have at kollegerne skal se koden renderet på nøjagtig samme måde som en selv, er det vel fordi, man ikke har indset, at den visuelle repræsentation af koden ligesom IDE'et blot er et værktøj, der alt andet lige skal hjælpe den, der betjener det, bedst muligt?

De fleste editors laver automatisk indrykning ved linjeskift og benytter det tegn (tab eller spaces) som er sat i indstillingerne - også hvis man trykker på tab-tasten, så hvis man sidder og hamrer på space tasten gør man det forkert.

Fordi du naturligvis har sat din editor til at indsætte 4 mellemrum hver gang du trykker TAB.

Hvis jeg kan nøjes med at trykke en gang på tab. Hvorfor skulle jeg så trykke flere gange på space i stedet?

Heldigvis findes der værktøjer til at klare den slags, i PHP verdenen (hvor wordpress på INGEN måde skal ses som fortaler for konsistens eller kvalitet - tag et kig på koden og du vil se hvad jeg mener) kan man bruge PHP_CodeSniffer - som automatisk kan detektere og fikse brud på den aftalte standard.

Til andre sprog findes der lignende værktøjer, f.eks. pycodestyle til python, som meget nemt kan gøres til et skridt i ens build pipeline, i f.eks. Jenkins eller TeamCity. Gør man det er det meget nemt at sørge for at koden der ender i git/svn altsammen overholder den samme kodestandard.

En lignende diskussion, jeg ofte ser blandt udviklere er om tuborgklammer skal på samme linie eller næste linie ved f.eks. if, for, while - personligt er jeg fan af den sidste (tuborgklammen på næste linie), heldigvis er det også noget der er dækket af kodestandarder i de fleste sprog :)

<?php
 
if ($foo) {
    doStuff();
}
 
//Eller
if ($foo)
{
    doStuff();
}
 ?>
[php]

Der findes flere ældre programmeringssprog, hvor det bestemt ikke er ligegyldigt. I de moderne sprog er indrykning normalt kun af hensyn til programmøren.

Faktisk er der en tendens blandt nyere sprog til, at indrykning har betydning. Ikke på samme måde som i FORTRAN og COBOL, hvor ting skulle stå i bestemte hulkortssøjler, men som erstatning for blokstrukturmarkering med f.eks. krølleklammer og semikolon. Eksempler herpå er Python, Haskell og F#.

I sådanne sprog er det bestemt ikke ligegyldigt, om man bruger blanktegn (mellemrum) eller tabulartortegn, med mindre sproget standardiserer tabulatortegn til enten at ækvivalere et bestemt antal blanktegn eller til at rykke frem til en kolonne, der er et multipla af et bestemt antal tegn fra venstre margen (som er den oprindelige betydning). I betragtning af, at forskellige visningsprogrammer tolker tabulatortegn forskelligt, er det sikreste at forbyde dem. Det gør f.eks. F# (med mindre du eksplicit fortæller oversætteren at acceptere dem).

Umiddelbart er jeg ikke tilhænger af indrykningsfølsom syntaks. Godt nok sparer man nogle skilletegn, og man "tvinger" programmøren til at lave indrykning. Men det kan gøre det sværere for oversætteren at lokalisere syntaksfejl (ofte bliver fejlen rapporteret et forkert sted og med forkert årsagsangivelse), og begyndere bliver ofte forvirret, fordi de ikke er vant til, at usynlige tegn kan have betydning.

Makefile kræver TABhttp://stackoverflow.com/questions/2131213/can-you-make-valid-makefiles-without-tab-characters

NB: Jeg husker engang en mundtlig eksamen, hvor indrykningen i det forberedte program var totalt ødelagt. Meget af tiden gik med at lave indrykning, mens jeg præsenterede programmet. Nu findes der vel eksamen-guidelines, så den slags undgås. Der er et tilsvarende problem med CrLf.

I mange år havde den editor, som jeg skulle bruge ikke mulighed for masseindrykning. Til gengæld fandt jeg mange småfejl under den manuelle indrykning :-) Derudover så var der kollegaernes blikke pga. tastaturlarmen.

Indrømmet - jeg har ikke sat mig ind i Python, eller Whitespace for den sags skyld, så der er måske områder, hvor tabulator kommer til kort.

Men hvis vi holder os til de sprog, hvor white space (og dermed indrykninger) er en visuel ting, bør det håndteres af den visuelle rendering af koden på linie med highlighting o.l.

Og her giver det simpelthen bedre mening at bruge tabulator, da man så kan lade det være op til den enkelte udvikler at bestemme, hvor meget en indrykning skal fylde ved at indstille sin editor. Hvorimod 4 mellemrum altid bør fylde halvt så meget som 8 mellemrum, uanset valg af editor.

Compileren beskrives som værende ligeglad, så er det ikke bare for at vi skal kunne slå hinanden oven i hovedet med, nu har du igen ikke gjort/sagt det rigtigt for 375'te gang, kom nu ind i kampen !

Oversætteren er også ligeglad med om du har skrevet al din kode på én linje (undtagen C-præprocessoren), samt om dine variabelnavne alle er på ét tegn. Uanset hvorvidt mellemrum/tabulatortegn er en vigtig debat at tage (det er det ikke), så synes jeg det er et dårligt argument at det kan være det samme for oversætteren.

Det lugter lidt af noget vi ser i næsten alle faggrupper, men nu her også inde i en enkelt faggruppe, vi vil være lidt forskellige fra alle de andre, det har meget længe været sådan at den samme hændelse i forskellige sammenhænge bliver kaldt noget vildt forskelligt, f.eks et møde mellem forældre, pædagoger og børn om hvordan barnet klare sig, kaldes et i børnehaven og noget andet i folkeskolen og noget helt tredie i gymnasiet (de få gange det holdes der) ! Det skal være helt vores eget udtryk ! Det kan også gøre det til en større udfordring at skifte mellem grupperne, da man skal lære et nyt sæt udtryk, man vil helst ikke virke dum ! Compileren beskrives som værende ligeglad, så er det ikke bare for at vi skal kunne slå hinanden oven i hovedet med, nu har du igen ikke gjort/sagt det rigtigt for 375'te gang, kom nu ind i kampen !