Indentation in code tags

Beste,

Ik heb net een stukje code geplaatst in een topic. Het valt me op dat de indentatie van de code niet meer klopt. Dit is me eerder ook al opgevallen. Als ik gewoon spaties gebruik in plaat van tabs lijkt het wel goed te gaan.

Is hier iets aan te doen?

Voorbeeldje met spaties:


int main()
{
    a[ 0 ][ 0 ][ 0 ] = emptyRoom;
    a[ 0 ][ 0 ][ 1 ] = someoneInRoom;
    
    StateFunction currentFunctionPointer = NULL;
    
    while (1) {
        int darkness = readDarkness();
        int movement = readMovement();
        int bed = readBed();
        
        StateFunction nextFunctionPointer = a[darkness][movement][bed];
        int stateChanged = (currentFunctionPointer != nextFunctionPointer);
        if (stateChanged) {
            currentFunctionPointer = nextFunctionPointer;
        }
        currentFunctionPointer(stateChanged);
    }
    return 0;
}

Voorbeeldje met tabs


int main()
{
	a[ 0 ][ 0 ][ 0 ] = emptyRoom;
	a[ 0 ][ 0 ][ 1 ] = someoneInRoom;

	StateFunction currentFunctionPointer = NULL;
	
	while (1) {
        int darkness = readDarkness();
        int movement = readMovement();
        int bed = readBed();

        StateFunction nextFunctionPointer = a[darkness][movement][bed];
        int stateChanged = (currentFunctionPointer != nextFunctionPointer);
        if (stateChanged) {
            currentFunctionPointer = nextFunctionPointer;
        }
        currentFunctionPointer(stateChanged);
    }
    return 0;
}

Tja dat is het probleem met tabs. Dat gaat altijd en overal fout.
Beter nooit meer gebruiken.

Meeste IDE's hebben wel de mogelijkheid om te kiezen tussen tabs of spaties.
Tabs is nooit een goede keuze, interpretatie verschilt per editor en is altijd ellende...

He is wel gek dat in het voorbeeld met tabs, er alléén tabs staan t/m de eerste WHILE. Daarna zijn het ook allemaal spaties.
Dus je tekst is eigenlijk geen goed voorbeeld.

Als ik zelf een stukje tekst maak met 1 of 2 tabs aan het begin van de regel, zie ik dat hier geloof ik wél correct.


tabs:
	een tab
	een tab
		twee tabs
		twee tabs
einde tabs

Inderdaad, dat werkt.

e: (hieronder) Ja, nu zie ik bij jou ook geen spaties aan het begin van de regels, maar allemaal tabs.

Ah, ik denk dat ik het al zie, CO interpreteert een tab als 8 spaties breed. In mijn voorbeeldje met tabs zijn ook niet alle tabs tabs. |:(

Bij mij gaan tabs vrijwel altijd goed als ik VS, VSCode en notepad++ gebruik. Nu staan die wel allemaal op tab = 4 spaces.

Zo zou het wel met tabs zijn:


int main() {
	Args args = { .nextState = NULL, .onEntry = true };
	void (*currentState)(Args*)  = FirstState;
	
	for(int i=0; i<10; i++)
	{
		currentState(&args);
		
		bool stateChanged = args.nextState != NULL && currentState != args.nextState;
		if(stateChanged)
		{
			currentState = args.nextState;
		}
		args.onEntry = stateChanged;
	}

	return 0;
}

Goed, dan is dat ook weer opgehelderd. Persoonlijk houd ik van tab = 4 spaties, met 8 wordt het allemaal zo groot. De uitzondering is HTML, daar ga ik eerder voor tab = 2 spaties. Maar dat is smaak en dat lijkt me een zeer slecht plan om een discussie over te starten. :)

Wat mij betreft is dit topic afgedaan.

[Bericht gewijzigd door hardbass op (18%)]

Op 11 oktober 2023 11:24:47 schreef hardbass:
Ah, ik denk dat ik het al zie, CO interpreteert een tab als 8 spaties breed.

Nou, in HTML zijn tabs standaard 8 spaties. Dat valt te beïnvloeden via CSS dus wellicht kan ik dat naar 4 spaties zetten om code blokken niet te breed te maken.

Op 11 oktober 2023 11:11:09 schreef deKees:
Tja dat is het probleem met tabs. Dat gaat altijd en overal fout.
Beter nooit meer gebruiken.

Humor!
Zo'n 40 jaar terug gebruikten wij in ons bedrijf een zelfgeschreven taal (ongeveer vergelijkbaar met basic) samen met een zelfgeschreven compiler.
Niks mis mee, maar in die taal had een regel die begon met "spatie tab" een andere betekenis als een regel die begon met een "tab".
De gebruikte tekstverwerker zag geen verschil tussen die twee verschillende regels, dus beide regels begon met 8 blanke posities. Dat is leuk foutzoeken.

Doet me denken aan "whitespace" https://esolangs.org/wiki/Whitespace 8)7

Op 11 oktober 2023 11:11:09 schreef deKees:
Tja dat is het probleem met tabs. Dat gaat altijd en overal fout.
Beter nooit meer gebruiken.

Gewoon verbieden in elke taal, simpel: Syntax error als er een TAB in staat.
Bouw ik standaard in elke build in.

Vroeger, denk jaren-zestig, waren tabs gewoon 8 lang. Dwz een tab verplaatst de cursor naar de eerstvolgende "veelvoud-van-8" positie (als je de eerste kolom kolom-nul noemt).

Dat heeft lang stand gehouden. Ergens jaren 80 tot 90 begonnen steeds meer plekken de tab instelbaar te maken. En dat heeft tot vervelende situaties geleid: Precies wat je nu ziet. De een stelt tabs van 4 in een ander 2 of 3.

Mijn advies: Ga er van uit dat tabs altijd overal verschillend staan en gebruik ze niet. Stel evt je editor in (als dat kan) dat ie als je op tab drukt, je naar de volgende tab stuurt maar in je bestand het juiste aantal spaties zet. Ik edit meestal met "emacs" en in "c-mode" is tab gewoon; "Zet de huidige regel op de juiste indentatie". En altijd alleen-spaties. Als ik daar iets aan heb moeten instellen heb ik dat meer dan 25 jaar geleden gedaan.

Op 11 oktober 2023 22:04:11 schreef rew:
Dat heeft lang stand gehouden. Ergens jaren 80 tot 90 begonnen steeds meer plekken de tab instelbaar te maken.

Daar hadden ze meteen de doodstraf op moeten zetten.
Alleen maar ellende van gekomen.

Net als "the most expensive one-byte mistake".

Mijn vaders puur mechanische schrijfmachine had al instelbare tabs 60 jaar geleden. Maar tabs zijn nu eenmaal bedoeld om tabellen te maken, niet voor indentatie. Dus niet gebruiken in code, in het belang van het gemeen, en van de coder zelf in de eerste plaats. Alles gebruiken waar het voor dient.

Maar die kreten om doodstraf en syntax error klinken mij nogal stalinistisch, waarom niet gewoon vertrouwen op het simpele gezonde boerenmensenverstand, ook wel genoemd "opvoeding"? Mensen die per se willen kliederen vinden wel een andere manier hoor, er zijn er genoeg.

Overigens gebruik ik zelf slechts een enkele spatie als indentering, zoveel te meer plaats blijft er over op de regel om nuttige dingen te schrijven.

Op 11 oktober 2023 21:44:56 schreef henri62:
Gewoon verbieden als er een TAB in staat.

En de kroegen hebben het al; zo zwaar ;).

Op 11 oktober 2023 23:23:14 schreef Paulinha_B:
Maar die kreten om doodstraf en syntax error klinken mij nogal stalinistisch, waarom niet gewoon vertrouwen op het simpele gezonde boerenmensenverstand, ook wel genoemd "opvoeding"?

Omdat ze het nog steeds niet leren ook niet na tig jaren.

Er is meer tijd verspild aan coding guidelines dan aan het maken van unit tests/testcode. Lees dit eens: https://hilton.org.uk/blog/contstrained-coding-style met de briljante uitspraak van Joel Spolsky. (Zijn boeken staan hier bij mij in de kast)

@benleentje: TAP, en maar hopen dat we geen TAP stop krijgen. ;-)

Als je een goede IDE gebruikt wordt code style steeds meer automatisch opgelost. Zelf ben ik redelijk fan van visual studio. Deze helpt goed met de opmaak. Zeker als je in C# programmeert. Wat ook erg prettig is, hij geeft met kleuren aan wat iets is. Dat maakt het erg overzichtelijk.

Wat betreft die tabs, wat Paulinha_B aangeeft, verheldert de zaak wel. Ik kan me goed voorstellen dat het op een mechanische schrijfmachine een erg prettige feature is. Ik zie het al gebeuren dat dat ene getalletje in je tabel net een spatie te veel naar rechts staat. Ziet er niet uit natuurlijk, maar de backspace bestond toen niet.

Het is vervelend, maar iets waar we mee moeten leren leven. Er zijn nu eenmaal meerdere standaarden. Dus ook voor tabs. :) Net als tijd, karakter sets, ect. ect. Moeten we dan nu maar een stroomstoot onder de tab zetten? Ik denk het niet.

@ohm pi, dat lijkt me erg naar. Hoe kan je dan de code nog lezen als een spatie voor een tab een andere functionaliteit krijgt? Of gaf jullie editor daar wel een verschil in aan?

Als je een goede IDE gebruikt wordt code style steeds meer automatisch opgelost. Zelf ben ik redelijk fan van visual studio. Deze helpt goed met de opmaak. Zeker als je in C# programmeert. Wat ook erg prettig is, hij geeft met kleuren aan wat iets is. Dat maakt het erg overzichtelijk.

Dat is een kwestie van smaak en van gewoonte. Ik heb de gloeiende pest aan IDE's en word knettergek van het gebruik van kleurtjes als ik code aan het schrijven ben. Als ik een machine nieuw opzet is het dan ook een vaste routine om het gebruik van kleuren in vim uit te schakelen, "syntax off" in de .vim en nog zo een en ander.

Maar goed dat we niet allemaal identiek zijn, en maar goed dat er omgevingen zijn waar dat wordt getolereerd en zelfs ondersteund.

Op 12 oktober 2023 08:33:46 schreef hardbass:

@ohm pi, dat lijkt me erg naar. Hoe kan je dan de code nog lezen als een spatie voor een tab een andere functionaliteit krijgt? Of gaf jullie editor daar wel een verschil in aan?

[bijlage]

Van oorsprong gebruikten we de taal in de tijd dat er nog geen microcomputers bestonden. We werkten op een PDP8 of PDP11. Eerst met een line-editor. Daar zag je maar één regel van je programma op het scherm. Later kregen we een editor waar je 25 regels op je scherm zag. Voor mij was dat een gigantische verbetering. Met de komst van de microcomputer gebruikten we eerst PFE en later UltraEdit. In UltraEdit kon je in ieder geval blank-characters zichtbaar maken. Op de PDP8 en PDP11 ging dat niet.
In die tijd waren de programmaatjes ook klein, dus het foutzoeken was nog wel te doen, en op een bepaald moment wist je wel waar het mis kon gaan. Alleen de eerste keer kijk je raar.

Op 12 oktober 2023 14:22:45 schreef Paulinha_B:
[...]
Ik ... word knettergek van het gebruik van kleurtjes als ik code aan het schrijven ben.

Ik vind het prachtig. Je ziet aan afwijkende kleuren dat daar ergens iets fouts gaat. (Waarom wordt "Pietje" niet groen? O,ja! Vergeten te declareren). Dat zie je al voordat je ga compileren, assembleren en linken.
In UltraEdit kon/kan je in wordfile.txt je eigen 'taal' toevoegen met zelfverzonnen syntax highlighting.

[Bericht gewijzigd door ohm pi op (21%)]

Omdat ze het nog steeds niet leren ook niet na tig jaren.

Domheid is van alle tijden, en zal altijd bestaan.
Daar is niks aan te doen, met geen duizend wetten of normen of richtlijnen.

Op 12 oktober 2023 23:32:19 schreef Paulinha_B:
[...]
Domheid is van alle tijden, en zal altijd bestaan.
Daar is niks aan te doen, met geen duizend wetten of normen of richtlijnen.

Gewoon syntax error: achter de if moet een spatie staan bijvoorbeeld. 2 spaties: Syntax error. Geen spaties: Syntax error. TAB: Syntax error. Nou dat leert wel af.

Om effe terug te komen op die IDE's. Ik heb er ook een bloedhekel aan, waarom?
Omdat die krengen zo achterlijk groot zijn kwa memory gebruik dat je er bijna niks meer mee kunt. Ik heb regelmatig tig editors open staan en in meerdere workspaces files openen is vaak een drama in verschillende IDE's. Zo kan ik echt niet overweg met eclipse bijvoorbeeld, ik vind het een rampzalig ding.

VS Code gaat nog wel, maar die heeft de hebbelijkheid dat het stomme ding vanalles cached en soms zit je naar een file te kijken die niet klopt met wat je uitgechecked hebt in een archief. Geen idee waar dat nou vandaan komt.

Ik vind 4 spaties ook wel mooi, en ik denk dat dat bij een stemming ook wel eens de winnaar zou kunnen zijn... Maar als dat de enige mogelijkheid is in een taal, dan is de kans groot dat die taal niet veel gebruikt gaat worden (liberale democratie versus dictatuur van de meerderheid).

Hoeveel spaties er worden afgedwongen, hoe groot een tab is of hoeveel spaties een tab neerzet als die geen tab neerzet, zal bij zo'n taal dus instelbaar worden gemaakt. Kan handig zijn als je binnen een bedrijf een standaard wilt neerzetten, maar voegt verder weinig toe. Vooral ook omdat je in veel IDE's ook nu al heea kunt instellen.

Op 13 oktober 2023 18:09:28 schreef henri62:
Zo kan ik echt niet overweg met eclipse bijvoorbeeld, ik vind het een rampzalig ding.

Eclipse is een java gedrocht. Een onverzadigbaar monster dat nooit genoeg heeft aan de beschikbare resources van een computer.

Het lijkt me dat de meeste IDE's in java geschreven zijn, en inderdaad al wat java is dat vreet systemresources. In mijn job als sysadmin waren het systematisch de eigenaars van javaprojecten die kwamen jammeren dat hun project niet genoeg memory kreeg &c &c.

Het is ook typisch dat men in java 1 enkele grote doos maakt waarin zoveel mogelijk activiteiten en procedures samengevoegd zitten; veel beter is om - in de aloude unix-benadering - elke activiteit in een apart doosje te stoppen, en die doosjes met elkaar te laten communiceren via gedocumenteerde interfaces.

Een standaard is geen wet was het eerste wat me werd verteld in de cursus programmeren. Als je iets doet, doe het dan consequent hetzelfde.

Visual studio is de slechtste IDE waar ik ooit mee gewerkt heb. Ook heel onbetrouwbaar programmeren. Op een bepaald ogenblik kwam er een nieuwe framework uit en de tab volgorde van de tekstboxes was plots volledig omgekeerd. VB.net was meer plakken en slepen. Als je dan ging kijken hoeveel nutteloze code er stond was dat gigantisch.

De beste IDE's zijn wat mij betreft nog altijd van Jetbrains. IntelliJ voor Java en CLION voor C. Het probleem is dat CLION geen fouten tolereert die bijvoorbeeld nog wel door de c-compiler van de Arduino IDE geraken. 95% van de C libraries geven fouten. 1 keer de IDE goed instellen en de opmaak is altijd 100% OK. Met code cleanup haal je er zo alle niet gebruikte zaken uit.

Altijd graag in Java geprogrammeerd. Geen probleem met pointers. Met een deftige PC heb ik nog nooit problemen gehad met resources. Ooit eens geprobeerd hoeveel threads er probleemloos gelijktijdig draaiden. Was zowat 20 jaar geleden en dat waren er toch meer dan 100.

100? Subtiel!

Mijn beide werkstations hebben op dit ogenblik tussen de 6 en 700 processen (iets zwaarder dan een thread).

Als je als test 100 threads start... Dan is dat niet zo zwaar voor een computer. Het probleem met java is dat als het een tijdje draait het op de een of andere manier bergen met RAM gaat nodig hebben. Ik vermoed iets met fragmentatie van het geheugen. "Geen problemen met pointers" betekent dat het systeem aan "garbage collection" moet gaan doen, en dat kost als je veel en lang geheugen gebruikt uiteindelijk veel CPU en RAM.

Stel je hebt een programma dat 1 100 miljoen voxels simuleert waarbij 100 bytes per voxel aan data nodig zijn. Dan verwacht je 10G aan RAM nodig te hebben. Als dat door stomme inefficienties (maar makkelijker te programmeren) 20G wordt. Soit!

Maar een editor die een compiler en een debugger aan kan roepen... blijkt, na een dag of een week gebruik ook zoiets aan geheugen te slurpen. Is dat nodig? Had dat niet met 1% daarvan moeten kunnen?