Spatie -kamp
Als je je code deelt blijft het inspringen van de tekst consequent dezelfde afstanden tonen in verschillende editors.
Tabs worden in een applicatie vertaald naar een x aantal spaties, en dat kan iin edere editor anders uitkomen waardoor code slechter leesbaar wordt.

Ik lijn gewoon altijd alles netjes links aan de kantlijn uit.

Wat "00:48 door Anoniem" zegt.

Blijkbaar gebruiken slimme mensen spaties, en minder slimme mensen tabs. ;)

Zelf gebruik ik spaties, maar mijn editor gebruikt automatisch tabs helaas. Ik vind editors die tabs op meer dan 2 spaties instellen niet fijn werken. Dat levert niet te volgen brede code op. Twee spaties zijn precies geschikt voor 1 niveau inspringen (in C).

https://en.wikipedia.org/wiki/Indent_style#Horstmann_style maar dan zonder tab of meerdere spaties achter de accolade. En ook zonder extra spaties in de vergelijking, maar wel een spatie na een komma.


Dit blijft prima te volgen, ook als er diepe inspring niveau's in zitten. (de code tag in dit forum haalt spaties weg op nieuwe regels, dus ik kan het niet laten zien)

Andere methoden zijn vaak visueel of structureel niet zo goed. Er is wel een klein nadeel aan Horstmann: #macro's kunnen niet worden geplaatst achter een accolade. Dan moet Allman worden toegepast.

Wat pas echt slecht is dat is een editor waar je de breedte van de tabs op iets anders dan 8 kunt zetten.
Dan krijg je het fenomeen uit de 1e reactie.

Een goede editor heeft een "inspringen" functie waarvan je de breedte kunt instellen, en regelt zelf het converteren
tussen tabs en spaties aan de linkerzijde. Dus als je inspringen op 2 staat en je hebt 4 levels bereikt dan gebruikt
hij een tab ipv 8 spaties. Bij nog een level wordt het dan een tab plus 2 spaties. Gebruik je de functie om het inspring
nivo van een blok regels te wijzigen dan rekent hij het allemaal om.

Tabs horen 8 karakters breed te zijn, ongeacht wat de tab-toets doet. Preciezer, een tab-karacter springt naar de volgende tab-stop en die zijn elke 8 karakters, dat is de standaardinstelling. Doe je wat anders, moet je de specificatie meeleveren.

Kwestie van je editor instellen.

Niet zo heel slim dat je je editor kennelijk niet hebt weten te temmen.

Voor nieuwe code is dat leuk, voor oude niet: als je dan een change wilt terugzoeken krijg je van die filrs waar alle regels in veranderd zijn (door de autoformat) en je dus niet meer snel kunt zien wat er nu echt veranderd is in de code.

Overigens gaat er in C en C++ niets boven Kernighan and Ritchie opmaak:
met _ een spatie.

Ik zit ook in het spatie kamp. Doe je alles zelf, dan maakt het niets uit, maar als je met meerdere mensen aan één project werkt, merk je al snel dat tabs problemen geven met de layout. Zeker als er mac, windows en Linux mensen in dat project zitten met ieder zijn eigen soort editor.

Bij teksteditors zal een tab van 8 spaties standaard zijn, maar veel code editors gebruiken slechts 4 spaties. En terecht, omdat 4 spaties een duidelijke inspringing geeft en je veel vaker kunt inspringen voordat je rechts van de pagina afloopt dan bij 8 spaties. Ik zie ook vaak code waar met een tab van 2 spaties gewerkt is, om meer werkruimte over te houden na veel inspringen.

Een tab van 8 spaties is toch echt meer voor tekstschrijvers en niet voor code.


Zelf gebruik ik XCode en TextWrangler die beide standaard een tab van 4 spaties gebruiken. En ik heb bij beide ingesteld om tabs direct door spaties te vervangen. Ik gebruik de tab-toets dus wel, maar ze komen niet in het document terecht.

Ik denk dat zelfs dat niet opgaat. Op een schrijfmachine (en op vroege printers) zijn tabs mechanisch instelbaar. Vandaag de dag spelen tab-characters geen enkele rol meer in hoe teksten worden opgemaakt, daar worden veel verfijndere methoden voor gebruikt. Met proportionele fonts is het zelfs niet meer goed aan te geven hoe breed 8 posities eigenlijk zijn.

En dan dit:
https://en.wikipedia.org/wiki/Tab_key
Dat is op Wikipedia niet voorzien van een bronverwijzing, maar het klinkt plausibel. Ook voor tekst zijn 8 tekens nogal grote sprongen.

Terug naar programmacode. Ook mijn voorkeur gaat uit naar spaties, en dat lijkt hier de heersende voorkeur te zijn. Als je dit soort discussies op bijvoorbeeld Slashdot leest dan lijken daar juist de tab-aanhangers de overhand te hebben, of het meest mondig te zijn. Kan het een cultureel verschil tussen Nederland (of Europa) en de VS zijn?

Ik doe aan geen van beide.
Ik programmeer lekker in visual studio en ik heb op mijn toetsenbord 5 extra programmeerbare macro toetsen. Een daarvan is ingesteld op de visual studio functie "formatteer code". Die toets druk ik elke minuut eens even in, en tadaa, alle regel afstanden, prefixes en gekrulde haakjes staan weer mooi.
Overigens heeft visual studio ook dat hij zelf automatisch bij een enter dezelfde hoeveelheid spaties invoerder als de vorige regel had.

Dan is de hele rest van je argument te reduceren tot het verwarren van het tab-karakter en de tab-toets.

Want er zitten er altijd tussen die danwel karakter en toets verwisselen danwel hun editor niet in weten te stellen en hoe dan ook geen oog hebben voor wat de afspraak is binnen het project, wat die impliciet of expliciet ook moge zijn. Zulke mensen geven met meer dingen problemen dan alleen tabs.

Als ze ab werk al verwarrend zijn ingesteld legt dat meer druk op de gebruiker en zeg het iets over de houding van de auteurs -- die is niet ingesteld op samenwerking.

Dus niet. Alweer, tab-toets vs. tab-teken en standaard is acht, wil je iets anders dan moet je dat expliciet specificeren.

Tenzij je wil volhouden dat code-editors primair bedoeld zijn voor lekker je eigen ding doen en vooral niet samenwerken.

Alweer, tab-toets vs. tab-teken en standaard is acht, wil je iets anders dan moet je dat expliciet specificeren.

Sterker nog, wil je tabstops op ik noem een dwarsstraat kolommen 3, 9, 12, 24, 39, en 66, dan kon (en kan, mits proper geëmuleerd) je dat op terminal(-emulator) gewoon instellen. Maar dat moet je dan wel doen. Doe je dat niet en verwacht je dat het ding (of je mede-code-knutselaars) je gedachten te lezen dan gaan er dingen verkeerd, ja. Heel gek nu.

Maargoed, dit is kennelijk hele moeilijke materie want je maakt in een en hetzelfde bericht drie keer dezelfde denkfout.

Dat is dus zeg maar het hele eieren eten. Je kan het kennelijk wel maar je moet er echt even goed over nadenken.


Dit is best vreemd want het is simpelweg het mentaal invoegen van een ontkoppeling danwel indirectie. Dat kunnen doen, bijvoorbeeld wat je doet als je met pointers werkt, is een van de indicators van programmeertalent.

Duidelijk geen python programmeur of jade/pug :)

Het defect in die editors is dat een tab gelijk is gesteld aan 1 nivo van inspringen. Dat is niet goed, de reden daarvoor
geef je al aan. Een tab is 8 tekens en een inspringing kan wat anders zijn. Kan best dat de editor de tab toets gebruikt
voor een inspringing, maar dan moet ie geen tab teken in de file zetten. Als de inspringing op 4 staat moet ie 4 spaties
in de file zetten en als je dan nog een extra nivo inspringt dan pas een tab.

Het lijkt er op dat "we gebruiken spaties" vooral een workaround voor defecte editors is. Want als er discussie is over
hoeveel spaties een tab is (in plaats van dat vast ligt dat het 8 is) dan gaat het nooit meer wat worden als er verschillende
omgevingen in het spel zijn.

Overigens kun je dit soort dingen ook met tools converteren die werken op de tekstfiles, dit hoeft niet gecombineerd
te zijn met de editor maar kan net zo goed in een version control system ingebouwd zitten.

Dus Spatieman die hier regelmatig komt is dus eigenlijk heel slim ;-)

En verder, Linus op de kernel mailing lijst heeft ook een zeer streng paradigma en conventie, owee als je die overtreedt. De vriendelijke woorden zullen dan blijven vloeien via de letters op je beeldscherm rechtstreeks je eeuwig gekwetse ziel. (Understatement voor wie de kernel mailing lijst leest, die begrijpt het wel :-) )

Visual Studio heeft hier instellingen voor. Het gaat hier niet om de vraag of je op tab- of spatietoetsen drukt of op iets anders, het gaat erom wat er in de sources die je opslaat staat. Reken maar dat daar tabs en/of spaties staan. Wat is het bij jou?

Voor zover ik kan vinden zijn die 8 tekens geen harde, formeel vastgelegde standaard maar niet meer dan een gewoonte die ooit is ontstaan, een conventie. Het kan nuttig zijn om een conventie te volgen, maar het is geen wet, je mag ervan afwijken.

En veel voorstanders van de tab voor inspringen vinden die superieur omdat iedereen hem aan zijn eigen smaak kan aanpassen. Wil jij 4 posities inspringen zien? Zet je de tabgrootte op 4. Wil je er 2 of 5 zien? Zet je de tabgrootte op 2 of op 5. En omdat statements die over twee of meer regels lopen dan een puinhoop worden moet je natuurlijk binnen een statement met spaties inspringen.

Persoonlijk ben ik het niet met ze eens, in mijn ogen maken ze iets simpels nodeloos ingewikkeld. Maar dat is ook maar een mening, het staat iedereen vrij het ermee oneens te zijn. Het jammere is dat er nogal wat mensen rond lijken te lopen die heel star volhouden dat hun mening hierover (of over waar je accolades plaatst bijvoorbeeld) de enige is waar goede argumenten voor te vinden zijn. Maar het is geen universele waarheid, het is een persoonlijke voorkeur met argumenten die vanuit die voorkeur redeneren. Persoonlijke voorkeuren verschillen per persoon en zijn wat mij betreft allemaal precies even legitiem.

Naar mijn mening is de enige juiste houding om er niet moeilijk over te doen. Het belangrijkste in mijn ogen is om een source consistent te houden zodat je niet krijgt dat als de ene functie er goed uitziet de andere een puinhoop is en vice versa. Als je een source voor je snufferd krijgt waar een bepaalde stijl wordt gehanteerd, zet die stijl dan binnen die source voort. Als je hem omzet in een andere stijl, doe dat dan alleen als dat binnen je organisatie een geaccepteerde omzetting is (anders krijg je edit-oorlogen) en maak er een aparte commit van.

Dat is waar, maar met een gotcha: Je moet dan wel even netjes vertellen dat je dat doet. En zelfs dan is hiet niet altijd een goed idee om het te doen.

Bedenk dat de controle-tekens in de ASCII-set bedoeld zijn om teletypes aan te sturen. "Begin transmissie", "nieuwe regel", "typewagentje terug naar links", "nieuwe pagina", "hallo wie is daar?", "wakker worden!", en zo verder. Origineel is "backspace" zelfs niet-wissend, daar had je DEL voor nodig, het teken met alle posities op een zodat je door wat gaatjes in je papieren tape bij te prikken een teken altijd in DEL kon veranderen. En als (bedoeld!) bij-effect dat je twee tekens over elkaar kon printen, bijvoorbeeld een e en een ", maakt ë. Of een a en een ^, maakt â. (In eerdere kladversies van de standaard had de ^ nog een streep, later niet meer, precies hierom.) Dat werkt prima op papier (letterlijk, in de praktijk), maar wat minder op "glass terminals", want die domme computerjongens hebben vaak vergeten accent-ondersteuning mee te nemen. Maargoed, controle-gegevens dus. Het zijn "doe dit" instructies, niet "ik bedoel dit" specificaties.

Zo ook horizontal tab (er is ook een verticale tab), het is een efficiente manier om het typewagentje naar de juiste plek te krijgen (zoef), vergeleken met spaties printen (stap-stap-stap-stap-stap-stap-stap-stap). Tab-stops kun je instellen, maar je moet maar net weten hoe ze zijn ingesteld om ze nuttig te kunnen gebruiken.

Schrijf je een bestandje vol met tab-tekens en komt iemand anders langs met een andere editor of zelfs een bestandsbekijker ("pager", zoals "less", of tegenwoordig kun je er zelfs een browser voor inzetten, al is die er niet erg goed in), dan zal die absent een specificatie tab-stops van 8 karakters aannemen. En dat ziet er niet uit, zeker niet als sommige tabs door (2,3,4,6,8) spaties zijn vervangen, en sommige niet. Vandaar, verwar die toets en dat teken niet, en als je zonodig tab-stops op andere plekken wil hebben dan de default, zeg dat dan even, dan kan de kijker zijn programma correct instellen. Wat nog steed irritant is, maar beter dan het helemaal niet zeggen.

Niet allemaal precies eender, niet als je ook nog wil samenwerken met anderen. Wel iets anders willen dan de default en het niet willen hoeven vertellen, bijvoorbeeld, is minder handig dan de default pakken.

Yup.

2 spaties. vooral als je lange if/if/if dingen hebt is het gewoon fijner alles meer links op je scherm te hebben.

Als blokken zo diep nesten dat dit een argument wordt geen uitzondering voor je is dan is er reden om jezelf aan te leren om je code op een andere manier te structureren, bijvoorbeeld door sneller dan je gewend bent delen in afzonderlijke functies/methods onder te brengen. De reden hiervoor is dat de testbaarheid van een functie of method afneemt naarmate er meer verschillende executiepaden door mogelijk zijn, en elke conditie en loop verhoogt dat aantal. Als je minder complexe eenheden weet te maken zijn die eenheden makkelijker te testen, te debuggen, en daardoor te onderhouden.

Een maat hiervoor is cyclomatische complexiteit (bedacht door een zekere McCabe). Er zijn tools beschikbaar voor allerlei programmeertalen om die te berekenen.