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

Det kan lyde banalt at diskutere, om indrykning skal være to eller fire mellemrum - eller tabulator - men de fleste sprog har en vejledning til, hvordan kildekoden skal se ud.

Mellemrum eller tabulator? HBO's tv-serie Silicon Valley stak i tredje sæsons sjette afsnit hånden ned i den hvepserede, der hedder 'code style guides'. Skulle der sidde læsere derude, der ikke er bekendt med, hvorfor det er et følsomt emne, eller måske er for ophidsede til at kunne forklare det for pårørende, så kommer forklaringen her.

Programmører tilbringer mere tid på at læse kode end på at skrive den. Derfor er det vigtigt, at koden er til at læse. De fleste programmeringssprog er konstrueret, så koden er til at læse for mennesker og ikke kun for computere. Derfor skriver man noget i stil med 'HVIS solen.skinner SÅ is' - altså noget, der til forveksling ligner et naturligt sprog.

Men når flere programmører skal skrive kode til det samme program, så bliver de små forskelle mellem, hvordan koden skal se ud, pludselig vigtig.

Eksempelvis skal man være enige om, hvordan man navngiver variable i koden. Skal den hedde solenSkinner eller b_solen_skinner? De fleste programmeringssprog har en mere eller mindre officiel vejledning til, hvordan man formaterer sin kode, ligesom mange softwarefirmaer også har skrevet ned, hvordan deres kode skal se ud.

Læs også: Seniorudvikler: Sådan skriver vi selvforklarende kode

Så hvad er problemet med mellemrum og tabulator? Inden vi når så langt, så er det nødvendigt lige at slå fast, at vi her taler om de sprog, hvor indrykning af teksten kun har kosmetisk betydning. Der findes flere ældre programmeringssprog, hvor det bestemt ikke er ligegyldigt. I de moderne sprog er indrykning normalt kun af hensyn til programmøren.

Indrykning bruges til at vise, at de indrykkede linjer er noget, der hører ind under den ovenstående linje. Det, der foregår inde i en funktion, rykkes derfor lidt ind, så man kan se, at koden er en del af funktionen.

function MakeDevelopersAngry() {
    developers.SetMood(Angry);
}

Det er hér, det kontroversielle begynder. For hvordan skal teksten rykkes ind? I Pythons style guide er det fire mellemrumstegn. Google foretrækker derimod to mellemrums indrykning i C++ - og bestemt ingen tabulator. Mozilla foretrækker også to mellemrum - undtagen for Python, hvor det skal være fire.

Google holder fast i sine to mellemrum, så i Chromium-projektet anbefales udviklerne at bruge Pythons stil - bortset fra det med fire mellemrum til indrykning.

I et sprog som PHP er der delte meninger. PSR-2-guiden siger fire mellemrum og tabulator forbudt, mens WordPress siger tabulator for PHP-kode.

Google siger også to mellemrum i Java, mens den originale specifikation for Java sagde fire tegn eller tabulator sat til otte tegn.

Mange udviklingsværktøjer håndterer formateringen for dig. Microsofts Visual Studio sørger for eksempel for at lave indrykninger på fire tegn, når det er nødvendigt, og hvis man bruger tabulatortasten, så bliver det ikke gemt som tabulator, men som fire mellemrum. Det samme gør en lang række af de øvrige værktøjer til kodning.

Læs også: Se Anders Hejlsberg forklare, hvordan moderne compilere virker

Men hvis man er typen, der ikke vil lade et IDE (integrated development environment) blande sig, mens man koder, så er der faktisk forskel på tabulator og mellemrum.

Både tabulator og mellemrum er specialtegn, whitespace characters, men de opfører sig forskelligt og kan i udgangspunktet ikke bare byttes rundt. Mellemrum svarer altid til én blank plads, hvor der kunne stå et tegn. I programmering arbejder man næsten altid med skrifttyper, hvor alle tegn har samme faste bredde.

Tabulator er lidt mere kringlet, da indrykningen kan variere. Tabulator er som regel sat til otte tegn, men kan være helt ned til et enkelt tegn eller op til en linje.

Men der er altså tale om to forskellige tegn. Mellemrum er nummer 32 i ASCII, mens tabulator er tegn nummer 9. Compileren er, som det også påpeges i Silicon Valley-afsnittet, ligeglad. Den kan godt håndtere både mellemrum og tabulator og er også ligeglad med, hvor meget linjerne er indrykket.

For udviklerne er det derimod mere kildent. Ud over ren irritation over at læse kode, en anden har skrevet med 'forkert' indrykning, så kan indstillingen af tabulator også give problemer med, hvordan koden vises. Derfor lyder argumentet fra mellemrumssiden, at man skal bruge mellemrum, for det ser ens ud alle steder.

Fra tabulatorsiden lyder argumenterne derimod, at tabulator for det første klarer indrykningen med færre tastetryk, og for det andet kan man justere, hvor meget tabulatoren skal rykke koden ind, uden at ændre noget i koden, lidt ligesom at ændre skriftstørrelse, baggrundsfarve eller linjeafstand.

Indrykning er et klassisk stridspunkt i stilvejledninger for programmering, og Silicon Valley-forfatterne har angiveligt også hentet inspirationen fra den virkelig verden. Ligesom den kildekode, der blev vist i første afsnit af tredje sæson, er C-kode, der kan kompileres.

Desværre er det med mellemrum og tabulator ligesom med Dansk Sprognævn. Der er ofte valgfrihed, snarere end klokkeklare regler. Mange vælger derfor at se stort på traditioner inden for et programmeringssprog og vælger den stil, de finder mest tiltrækkende, uanset om det så handler om æstetik eller effektivitet.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (35)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Dave Pencroof

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 !

Troels Henriksen

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.

Yoel Caspersen Blogger

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.

Carsten Hansen

Makefile kræver TAB
http://stackoverflow.com/questions/2131213/can-you-make-valid-makefiles-...

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.

Torben Mogensen Blogger

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.

Martin Clemmensen

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]
Yoel Caspersen Blogger

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?

Torben Mogensen Blogger

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.

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.

Yoel Caspersen Blogger

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.

Yoel Caspersen Blogger

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.

Jens loggo

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.

Christoffer Kelm Kjeldgaard

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å.

Finn Thøgersen

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 <tab><tab> har samme effekt som <tab><space><space><tab>, men <tekst><tab><tekst> og <tekst><space><space><tab><tekst> 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.

Finn Thøgersen

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 <tudsegammelt projekt> ? Det har da ikke været rørt i halve/hele år ?"!

Jesper Louis Andersen

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.

Morten Saxov

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?

Sune Marcher

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


Han har nogle gode pointer, men falder helt af hesten med "mandate that the ASCII #9 TAB character never appear in disk files".

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.

Troels Henriksen

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.

Søren Hansen

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.

Jan K. Hansen

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 :-)

Kim Madsen

... 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.

Yoel Caspersen Blogger

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 ;-)

Sune Marcher

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.


Hvis du bruger tabs som de er tiltænkt, så er det én tab per semantisk indrykning.

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 :)

Sune Marcher

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.

Finn Thøgersen

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...

David Christensen

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


...men der er også megen semantik i alignment, afhængigt af programmeringssprogets understøttelse for named parameters. For eksempel, i Swift,

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.

Niels Elgaard Larsen

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.

Log ind eller Opret konto for at kommentere