[Alg] Programmeerstijl*

[Michali]

Ik heb een voorkeur voor een hele 'luchtige' stijl van programmeren. Veel spaties en enters. Na het afsluiten van een block bijvoorbeeld heb ik altijd een lege regel (behalve bij een if-else constructie).

Ik heb verder niet zo veel problemen met meerdere dingen op een regel, als die maar allen te hetzelfde statement behoren dus niet met ; oid. ertussen en dan er nog wat achter aan zetten. Sommige mensen proberen zo'n statement op te splitsen in meerder losse acties, waarvoor dan wel meer lokale variabelen nodig zijn. Ik vind niet dat dit de code duidelijker maakt.

(maar het moet natuurlijk niet te gek worden, als er bijvoorbeeld meer dan 3-4 functie aanroepen in een statement komt, dan ga ik ook wel overwegen om het anders te doen)

[Verwijderd]

Hier op het werk zitten we na te denken over een tool waarvan ik de naam even ontschoten (iets met een J). Hiermee kun je code formatten in een afgesproken codestyle. Op die manier kan iedereen zijn eigen code style blijven gebruiken. Zodra een stuk source wordt uitgechecked (uit cvs oid) kan de stijl worden aangepast aan de programmeur die er dan mee werkt, en bij het inchecken wordt het weer omgezet naar de algemene codestyle.

Ik heb echter geen ID of het een beetje fatsoenlijk werkt . Op dit moment zijn er alleen nog vage plannen..

edit: Naam is trouwens jacobe.

Of misschien zou het Zend team hiermee aan de gang kunnen gaan, dat zou nm. wel een mooie optie zijn voor de nieuwe Zend Studio...

[ Voor 62% gewijzigd door Verwijderd op 06-01-2004 12:13 ]

[.oisyn]

Verwijderd schreef op 06 januari 2004 @ 09:35:
Je zou zeggen, dat scheelt toch niets maar denk eens aan projecten waar je ,op mijn manier, meer dan 200.000 regels code hebt (en die zijn er genoeg).
De verschillen worden dan toch behoorlijk groot.

ik houd me even van den domme en ga een rekensommetje doen. Overigens vind ik een project met 200.000 regels heel erg groot, ik vraag me af hoeveel daarvan in de werkelijkheid voorkomen

Goed, ik pak even jouw voorbeeld.
De korte versie was 696 bytes, en de lange versie 736. Dat is een verschil van 40 bytes, en aangezien je het 10x deed betekent dat 4 bytes per complete if-else-statement van 5 regels

Goed, die 5 regels expanderen we naar 200.000, dus dat wordt 40.000 keer zoveel. 40.000 * 4 bytes = 160.000 bytes.

OMFG!!! 160k op 200.000 regels code!! Dat is toch wel een hele single sided, single density 5.25" floppy!!! Stel je voor dat je die net te kort komt, echt te erg gewoon!!!!!!!!111


En dan heb ik het commentaar nog niet eens meegenomen, dit is gewoon 200.000 regels aan if-else-statements. Het wordt dus sowieso een stuk minder omdat je code niet alleen uit accolades bestaat, maar ook gewoon uit statements die je gewoon recht onder elkaar zet. Neem daarbij dat iets van 50-80% van de grootte van je source uit comments bestaat (comments zijn volledige tekst, en nemen dus vaak veel meer ruimte in dan je code zelf). Het is dus 3x niks

[Delphi32]

.oisyn schreef op 06 januari 2004 @ 13:41:
Overigens vind ik een project met 200.000 regels heel erg groot, ik vraag me af hoeveel daarvan in de werkelijkheid voorkomen

Los van de juistheid van je opmerkingen over de onzin van die paar bytes: projecten van 200.000 regels en groter zijn toch echt dagelijks werk voor me hoor. Ik heb een stuk of 5 projecten tegelijk lopen die allemaal 200.000+ zijn; eentje zelfs met 1,235 miljoen regels (vorige week nog geteld).

[Rataplan]

Paar overwegingen:

* als ik HTML schrijf (dus niet: PHP) ben ik nog steeds erg zuinig met newlines, tabs, etcetera. Elke byte is er dan 1 die verzonden moet worden, en verzenden kost geld. Als ik sommige HTML-sources bekijk, waar honderden regels onder elkaar tientallen tabs achter elkaar staan in documenten die duizenden keren per dag worden verzonden... Dat scheelt al snel megabytes. Niet doen dus. Wat dat betreft ben ik blij dat ik 20 jaar geleden heb leren programmeren, efficient gebruik van code is mij gelukkig nog niet volstrekt vreemd

* Accolades altijd onder elkaar (zie bijv. hieronder) en daar koop je, als serieuze programmeur, dus idd. minimaal een 19" bij die je dan ook op 1600x1200 instelt. Om de if in een else-if zet je trouwens ook accolades. Alleen single statements kunnen eventueel zonder; maar zelfs dan zet ik ze er voor de overzichtelijkheid vaak ff bij; altijd, bijvoorbeeld, als ik ook accolades bij het als-true-statement gebruik.

* de 'klassieke' manieren van identifiers schrijven (bijvoorbeeld eenVariabele vs. EenFunctie) levert mij hoofdbrekens op in OO-environments. Voorbeeld:

C#:

class Something
{
    private int _locaaltje;

    public int PubliekeProperty
    {
        get { return _locaaltje; }
        set { _locaaltje = value; }
    }
}

...is die property nou een functie? Ik vind (op basis van gevoel) van niet, in feite is 'ie het wel, maar geef je dat wel of geen begin-hoofdletter? En hoe doe je dat met events? Is dat een functie of een variabele? Of geen van beide?

Kortom, mijn hoofdlettergebruik is doorgaans volstrekt niet consistent Die underscore gebruik ik trouwens ook vaker niet dan wel.

* Ik las laatst dan in C het als standaard geldt om géén tabs te gebruiken, maar alles met spaties te layouten. Dat vind ik nou echt ruimteverspilling Ook hier: koop maar een groter beeldscherm, leer je editor eens hoe breed een tab moet zijn en hou op met zeuren

[ Voor 10% gewijzigd door Rataplan op 06-01-2004 14:26 ]

[.oisyn]

Delphi32 schreef op 06 januari 2004 @ 14:21:
[...]

Los van de juistheid van je opmerkingen over de onzin van die paar bytes: projecten van 200.000 regels en groter zijn toch echt dagelijks werk voor me hoor. Ik heb een stuk of 5 projecten tegelijk lopen die allemaal 200.000+ zijn; eentje zelfs met 1,235 miljoen regels (vorige week nog geteld).

ah ok, dan heb ik me daarin vergist
Ik heb zelf ook niet zo'n ervaring met die supergrote projecten, vandaar

[riezebosch]

.oisyn schreef op 05 januari 2004 @ 21:56:
... bestaandsrecht ...

als je een modbreak doe, doe 'm dan iig foutloos

[drm]

riezebosch:
als je een modbreak doe, doe 'm dan iig foutloos

Als je dan een reply doet, voeg dan in ieder geval iets toe aan het topic

[Infinitive]

* als ik HTML schrijf (dus niet: PHP) ben ik nog steeds erg zuinig met newlines, tabs, etcetera. Elke byte is er dan 1 die verzonden moet worden, en verzenden kost geld. ... documenten die duizenden keren per dag worden verzonden... Dat scheelt al snel megabytes.

Daar ben ik het niet mee eens. Je moet dit soort dingen relatief zien. Vergeleken met de hoeveelheid data, stelt dat helemaal niets voor. Het wordt pas interessant als je tientallen procenten bandbreedte kunt gaan besparen. Die paar bytes van jouw vallen in het niet bij een aantal plaatjes, bijv. Bovendien verlies je zo wie zo al een heleboel ruimte door de voor mensen leesbare HTML-tags. En is er per default geen sprake van compressie.

* Ik las laatst dan in C het als standaard geldt om géén tabs te gebruiken, maar alles met spaties te layouten. Dat vind ik nou echt ruimteverspilling Ook hier: koop maar een groter beeldscherm, leer je editor eens hoe breed een tab moet zijn en hou op met zeuren

[/quote]

Er zijn programmeertalen die afhankelijk van layout zijn. Het gebruik van tabs kan in deze gevallen tot vreemde situaties leiden.

[Sybr_E-N]

Rataplan schreef op 06 januari 2004 @ 14:23:
Paar overwegingen:

* Accolades altijd onder elkaar (zie bijv. hieronder) en daar koop je, als serieuze programmeur, dus idd. minimaal een 19" bij die je dan ook op 1600x1200 instelt.

Is dat niet een erg kromme gedachte? Dus als jouw compiler niet fatsoenlijk optimaliseerd koop jij een sneller pc om op die manier als nog een goed resultaat te behalen?

[drm]

Sybr_E-N:
Is dat niet een erg kromme gedachte? Dus als jouw compiler niet fatsoenlijk optimaliseerd koop jij een sneller pc om op die manier als nog een goed resultaat te behalen?

volgens mij lees jij niet helemaal goed

[Verwijderd]

Ik praat even over Java, daar programmeer ik het meest mee en daar is opmaak voor mij ook het belangrijkst.

Ik zet de accolade er het liefst achter en niet onder. Ik vind er achter namelijk overzichtelijker. Ik zie direct als er een inspringing is dat daar een groep statements komen van één of andere methode.
Zet ik de accolade eronder, zie ik door al die witregels de tabs niet meer en loop ik veel langer te zoeken. Wellicht dat andere juist niet zo letten op tabs, maar juist op accolades, dan kan ik me voorstellen dat je hem er onder zet.

Verder vind ik het nogal knullig staan als de if maar één statement bevat en dat die toch tussen accolades is gezet. Met accolades geef je immers aan dat je if-statement meerdere statements gaat bevatten. Is dat er maar eentje, hoef je ook geen accolades te typen.
Je krijgt dan ook stiekem een beetje het vermoede dat de programmeur niet weet dat je dan geen accolades hoeft te typen. Wellicht dus een amateurist.

Je ziet dan ook al ontstaan dat je dus meer tabgeoriënteerd moet gaan kijken en niet accoladegeoriënteerd. Wat dat betreft is het misschien juist beter om de accolade er achter te zetten en niet er onder.

Tot slot ben ik het ook wel eens met wat ik hier eerder las. Een regel hoort eigenlijk ook iets te zijn. Een accolade op een losse regel is niets, die hoort ergens bij. Dus erachter en niet eronder.

Op school verschilt het per leraar en de boeken zijn niet consequenter.

[Rataplan]

drm schreef op 06 januari 2004 @ 19:23:
volgens mij lees jij niet helemaal goed

Zo volstrekt krom en uit z'n verband gerukt als het er staat: ik ben bang dat 'ie de vergelijking serieus bedoelt

Ik pas (in dit geval) namelijk inderdaad mijn hardware aan mijn gedrag aan. Dit in tegenstelling tot Sybr_e-n, die net zo lief op een 12cm zwartwit-buisje naar LOTR kijkt.

Neem ik dan aan

edit:
En wat Nelske hieronder schrijft wou ik ook net tikken, behalve dan dat ik ook nog wil weten wat een amateurist is

[ Voor 14% gewijzigd door Rataplan op 06-01-2004 19:48 ]

[Verwijderd]

Verwijderd schreef op 06 januari 2004 @ 19:39:
Verder vind ik het nogal knullig staan als de if maar één statement bevat en dat die toch tussen accolades is gezet. Met accolades geef je immers aan dat je if-statement meerdere statements gaat bevatten. Is dat er maar eentje, hoef je ook geen accolades te typen.
Je krijgt dan ook stiekem een beetje het vermoede dat de programmeur niet weet dat je dan geen accolades hoeft te typen. Wellicht dus een amateurist.

De redenen om het juist wel te doen al gelezen in deze topic

Andersom vind ik eerder amateuristisch te noemen, omdat het minder consistent is; de kans op fouten groter is en de overzichtelijkheid er niet beter op wordt.

[drm]

edit:
/me sloom

The_Tzar:
Je krijgt dan ook stiekem een beetje het vermoede dat de programmeur niet weet dat je dan geen accolades hoeft te typen. Wellicht dus een amateurist.

Daar ben ik het dus helemaal niet mee eens. Dat ik het niet doe wil nog niet zeggen dat ik niet weet dat het ook zonder kan. Je bent inconsequent bezig als je niet altijd en overal accollades zet. Hoe minder "behalve"s en "tenzij"s er in een codestijl zitten, hoe beter imho.

[ Voor 3% gewijzigd door drm op 06-01-2004 19:46 ]

[whoami]

Verwijderd schreef op 06 januari 2004 @ 19:39:

Verder vind ik het nogal knullig staan als de if maar één statement bevat en dat die toch tussen accolades is gezet. Met accolades geef je immers aan dat je if-statement meerdere statements gaat bevatten. Is dat er maar eentje, hoef je ook geen accolades te typen.
Je krijgt dan ook stiekem een beetje het vermoede dat de programmeur niet weet dat je dan geen accolades hoeft te typen. Wellicht dus een amateurist.

Ik heb hier al redenen aangegeven om die accolades juist wel altijd te zetten.
Trouwens, als iemand een andere programmeur als 'amateurist' inschat omwille van een deel van z'n coding - style, dan zegt dat imho toch veel over die programmeur.

[Verwijderd]

drm schreef op 06 januari 2004 @ 19:45:

edit:
/me sloom

[...]
Daar ben ik het dus helemaal niet mee eens. Dat ik het niet doe wil nog niet zeggen dat ik niet weet dat het ook zonder kan. Je bent inconsequent bezig als je niet altijd en overal accollades zet. Hoe minder "behalve"s en "tenzij"s er in een codestijl zitten, hoe beter imho.

En dat is inderdaad ook een goed argument en ik persoonlijk zou je ook niet zo snel veroordelen hoor , maar ik wilde het wel even als argument aandragen, omdat er wel degelijk mensen zijn die het onprofessioneel vinden.
Een docent Java (één van de) vindt het bijvoorbeel echt achterlijk, geef je met je accolades aan dat je een groep statements gaat krijgen en dan zet je er maar één neer? Hij vindt het achterlijk en alles behalve professioneel overkomen. Dus ja, het zal je potentiële opdrachtgever maar zijn, terwijl als je het niet doet je hoog uit krijgt te horen dat ze liever hebben dat je consequenter blijft. Ze kunnen je iig niet een gebrek aan kennis verwijten.

edit:
Sorry als ik jullie eerdere argumenten niet heb gelezen, ik had het wel doorgelezen, maar de helft niet echt opgenomen, omdat ik tegerlijkertijd een oplossing bedacht voor iets anders

[ Voor 10% gewijzigd door Verwijderd op 06-01-2004 19:52 ]

[Verwijderd]

Ook nog iets waarbij je veel verschillende meningen ziet: inspringen met tabs of spaties? Zelf gebruik ik altijd liever tabs, maar in sommige coding guides zweren ze toch weer bij het zetten van drie spaties. Zijn er hier ook nog mensen die liever spaties gebruiken en daar een reden voor hebben?

[Verwijderd]

Verwijderd schreef op 06 januari 2004 @ 19:52:
Ook nog iets waarbij je veel verschillende meningen ziet: inspringen met tabs of spaties? Zelf gebruik ik altijd liever tabs, maar in sommige coding guides zweren ze toch weer bij het zetten van drie spaties. Zijn er hier ook nog mensen die liever spaties gebruiken en daar een reden voor hebben?

Bij mij op school lijken ze er in ieder geval unaniem over eens dat de tab op 2 spaties ingesteld moet worden en elk programma die dat default niet heeft moeten we onmiddelijk (de één is wat makkelijker dan de ander) instellen op 2 spaties. Mij persoonlijk lijkt 3 veel overzichtelijker, maarja, als zij 2 willen krijgen ze 2

[Rataplan]

Verwijderd schreef op 06 januari 2004 @ 19:52:
Ook nog iets waarbij je veel verschillende meningen ziet: inspringen met tabs of spaties? Zelf gebruik ik altijd liever tabs, maar in sommige coding guides zweren ze toch weer bij het zetten van drie spaties. Zijn er hier ook nog mensen die liever spaties gebruiken en daar een reden voor hebben?

Bij voorkeur tabs, zoals ik eerder schreef, als het moet een aantal spaties, dat om één of andere reden altijd even is. Drie? Brrr

edit:

@whoami: in mijn ervaring is het juist exact tegengesteld. Alles wat door docenten als waar wordt geponeerd is flauwekul of zal dat dra zijn. Zo werd mij in 1986 het woord 'flodderschijf' nog door de strot geramd als enige aan de RUL toegestane aanduiding voor 5¹/₄ schijfjes. Well, we all know how long they lasted

[ Voor 25% gewijzigd door Rataplan op 06-01-2004 20:02 ]

[whoami]

Verwijderd schreef op 06 januari 2004 @ 19:51:
[...]

En dat is inderdaad ook een goed argument en ik persoonlijk zou je ook niet zo snel veroordelen hoor , maar ik wilde het wel even als argument aandragen, omdat er wel degelijk mensen zijn die het onprofessioneel vinden.
Een docent Java (één van de) vindt het bijvoorbeel echt achterlijk, geef je met je accolades aan dat je een groep statements gaat krijgen en dan zet je er maar één neer? Hij vindt het achterlijk en alles behalve professioneel overkomen. Dus ja, het zal je potentiële opdrachtgever maar zijn, terwijl als je het niet doet je hoog uit krijgt te horen dat ze liever hebben dat je consequenter blijft. Ze kunnen je iig niet een gebrek aan kennis verwijten.

Nouja, het is niet omdat hij docent is, dat zijn wil dan wet is, of zijn mening de enige juiste is.

[Verwijderd]

Verwijderd schreef op 06 januari 2004 @ 19:51:
maar ik wilde het wel even als argument aandragen, omdat er wel degelijk mensen zijn die het onprofessioneel vinden.

Zoals whoami al zegt, zegt dat meer over de persoon die dat beoordeelt dan over de persoon van wie de code is. Als je uit een dergelijk klein stijl element een indruk opbouwt over de programmeur dan ben je verkeerd bezig.

Een docent Java (één van de) vindt het bijvoorbeel echt achterlijk, geef je met je accolades aan dat je een groep statements gaat krijgen en dan zet je er maar één neer? Hij vindt het achterlijk en alles behalve professioneel overkomen.

Gehehe Ik denk dat je voor de gein eens deze topic moet printen of hem deze url geven Kijken wat de argumenten zijn om het achterwege te laten, buiten het argument dat je het achterwege kan laten in dergelijke gevallen.

Dus ja, het zal je potentiële opdrachtgever maar zijn, terwijl als je het niet doet je hoog uit krijgt te horen dat ze liever hebben dat je consequenter blijft. Ze kunnen je iig niet een gebrek aan kennis verwijten.

En jij denkt serieus dat een opdrachtgever over dergelijke kleine stijl dingen gaat vallen? Die kijken echt wel naar het grotere geheel hoor
Daarnaast geldt in dat geval ook bovenstaande verhaal weer.

Verder heb je voldoende argumenten mocht men er wel over vallen. Argumenten om het wel te doen die i.m.o. beduidend sterker zijn dan eventuele argumenten om het niet te doen.

[drm]

Rataplan:
Bij voorkeur tabs, zoals ik eerder schreef, als het moet een aantal spaties, dat om één of andere reden altijd even is. Drie? Brrr

Spaties. 3 spaties.
Waarom spaties? Omdat als ik toevallig even iets in notepad ofzo open ik ook gewoon goede layout wil krijgen en niet opeens alles versprongen is omdat de tabinstelling anders is (geldt overigens voor meer programma's dan alleen maar notepad)

Waarom 3? Geen idee eigenlijk. 4 vind ik ook wel gaan, 2 vind ik echt te weinig.

[.oisyn]

Verwijderd schreef op 06 januari 2004 @ 19:39:
Verder vind ik het nogal knullig staan als de if maar één statement bevat en dat die toch tussen accolades is gezet. Met accolades geef je immers aan dat je if-statement meerdere statements gaat bevatten. Is dat er maar eentje, hoef je ook geen accolades te typen.
Je krijgt dan ook stiekem een beetje het vermoede dat de programmeur niet weet dat je dan geen accolades hoeft te typen. Wellicht dus een amateurist.

bliep

C++:

#include <iostream>

int main (int argc, char ** argv)
{
    if (argc > 2)
        std::cout << "U heeft argumenten opgegeven" << std::endl;
        std::cout << "Beginnend met deze: " << argv[1] << std::endl;
}

Codestyle heeft niet alleen met leesbaarheid te maken, maar ook met het voorkomen van fouten. Bovenstaande code interpreteer je als zijnde 2 statements in het if-block. Toch wordt het niet zo geparsed. Nou gebruik ik ook geen accolades als ik ze niet nodig heb, maar er is wel wat voor te zeggen om het altijd te doen. Consistentie is al genoemd, de 2e reden is omdat je er makkelijker een regel bij kunt zetten als dat nodig is.

Een ander, minder helder voorbeeld, maar toch funest voor je programma:

C++:

void functie (int a, int b)
{
    if (a)
        if (b)
            std::cout << "a en b zijn true" << std::endl;
    else
        std::cout << "a is false" << std::endl;
}

ook hier, het expliciet gebruik van accolades voorkomt fouten


En argumenten om een accolade erachter of juist op de volgende regel te zetten zijn imho stuk voor stuk lulkoek. Het is puur en alleen een kwestie van persoonlijke voorkeur. Ik houd zelf van veel witregels, en ik deel mijn code in in alinea's. En met een resolutie als 1600x1200 kan ik me dat ook wel veroorloven, het ziet er gewoon veel helderder uit. Maar goed, dat is dus puur hoe ik erover denk, weinig keiharde feiten

[Verwijderd]

drm schreef op 06 januari 2004 @ 20:02:
[...]
Spaties. 3 spaties.
Waarom spaties? Omdat als ik toevallig even iets in notepad ofzo open ik ook gewoon goede layout wil krijgen en niet opeens alles versprongen is omdat de tabinstelling anders is (geldt overigens voor meer programma's dan alleen maar notepad)

Yupz, ik (wij) gebruik(en) ook 3 spaties. Zeker als ik onder Linux werk is het altijd weer heerlijk om te zien, hoe andere mensen spaties en tabs door elkaar gemikt hebben om vervolgens alles te laten verspringen. Nu is dat erg makkelijk op te lossen door een retab (tabs worden omgezet in spaties), maar toch is het iets iritants wat je bij het gebruik van spaties gewoon simpelweg niet hebt. Dat ziet er bij iedereen, ongeacht OS of editor precies hetzelfde uit.

[Infinitive]

Gebruik een editor editor die de source-code parsed en automatisch de source-code aanbied d.m.v. een pretty printer met jouw layout-voorkeuren en bovendien aanpassingen in deze view doorvertaald naar de voorkeuren van de oorspronkelijke source-code. Als zo'n editor bestaat tenminste (waarom zou dat niet kunnen?).

[whoami]

.oisyn schreef op 06 januari 2004 @ 20:05:
[...]

Consistentie is al genoemd, de 2e reden is omdat je er makkelijker een regel bij kunt zetten als dat nodig is.

Die 2de reden was ook al genoemd hoor.

ook hier, het expliciet gebruik van accolades voorkomt fouten

Ook al genoemd.

Sorry for this interruption, please continue.

[.oisyn]

whoami schreef op 06 januari 2004 @ 20:09:
Die 2de reden was ook al genoemd hoor.

waar dan?

Ook al genoemd.

waar dan?

[ Voor 3% gewijzigd door .oisyn op 06-01-2004 20:14 ]

[Mayco]

ikzelf programeer op deze manier:

php:

code:

if ($var=="mayco") {
  DoeIets($var);
  echo "ok";
} else {
  DoeIetsAnders($var);
  echo "niet ok";
}

zo vind ik het het beste leesbaar, omdat je duidelijk het verschil tussen de 2 codeblokken ziet, het is compact, maar toch mooi leesbaar. (vind het altijd wat lastig als je je muiswiel moet zotdraaien om een klein stukje code op te zoeken)

delphi:

code:

if var='mayco' then
begin
  DoeIets(var);
  writeln('ok');
end
else
begin
  DoeIetsAnders(var);
  writeln('niet ok');
end;

het valt me eigenlijk nu pas op dat ik in delphi helemaal anders code, maar toch blijft de leesbaarheid belangrijk.

wat ik ALTIJD doe is begin/end/{/}-s weglaten als er maar 1 statement is.

waar ik mij het meest op erger op code van een ander is dat er vaak van stijl veranderd word.

[Verwijderd]

Rataplan schreef op 06 januari 2004 @ 14:23:
Paar overwegingen:

* als ik HTML schrijf (dus niet: PHP) ben ik nog steeds erg zuinig met newlines, tabs, etcetera. Elke byte is er dan 1 die verzonden moet worden, en verzenden kost geld. Als ik sommige HTML-sources bekijk, waar honderden regels onder elkaar tientallen tabs achter elkaar staan in documenten die duizenden keren per dag worden verzonden... Dat scheelt al snel megabytes. Niet doen dus. Wat dat betreft ben ik blij dat ik 20 jaar geleden heb leren programmeren, efficient gebruik van code is mij gelukkig nog niet volstrekt vreemd

Je kunt natuurlijk ook gewoon voor je iets publiceert het door een filter heen haalt die alle overbodige layout er uit haalt. Dan heb je zelf het voordeel dat je alles handig gelayout staat en op de website alles mooi compact is.

[faabman]

Rataplan schreef op 06 januari 2004 @ 14:23:
Paar overwegingen:

* als ik HTML schrijf (dus niet: PHP) ben ik nog steeds erg zuinig met newlines, tabs, etcetera. Elke byte is er dan 1 die verzonden moet worden, en verzenden kost geld. Als ik sommige HTML-sources bekijk, waar honderden regels onder elkaar tientallen tabs achter elkaar staan in documenten die duizenden keren per dag worden verzonden... Dat scheelt al snel megabytes. Niet doen dus. Wat dat betreft ben ik blij dat ik 20 jaar geleden heb leren programmeren, efficient gebruik van code is mij gelukkig nog niet volstrekt vreemd

verzenden kost geld , ja daar zit wat in, maar, wat zijn de kosten van het onderhouden van jou onleesbare HTML ??? En daarnaast, de kosten van het dataverkeer zijn tegenwoordig nihil, eerder in dit topic kwam ook al iets naar voren over het besparen op opslagruimte, lijkt me dat jou stelling op hetzelfde neerkomt. We leven in een land waarin loonkosten de grootste kostenpost zijn en dus durf ik de stelling wel aan dat alle overige kosten m.b.t. het onderwerp van dit topic verwaarloosbaar zijn

[Rataplan]

FvKnijff schreef op 06 januari 2004 @ 21:20:
[...]


verzenden kost geld , ja daar zit wat in, maar, wat zijn de kosten van het onderhouden van jou onleesbare HTML ???

Hoho, de enige onleesbare html die ik heb besproken is die met die idiote hoeveelheden tabs erin! Mijn HTML is volgens mij nog best netjes

Het gaat hier niet alleen om loonkosten, los van het feit dat het meeste wat ik doe vrijwilligerswerk is. Ik schrijf nog steeds geen HTML voor breedbandgebruikers, ik schrijf HTML voor het internet. Ik heb met de kerst een paar dagen met een modem moeten werken (moeders ) en het is verschrikkelijk hoe weinig er nog met die krengen rekening wordt gehouden. Trouwens, WML is hetzelfde verhaal: vooralsnog kost elke byte die jij overbodig laat staan elke keer dat die pagina wordt opgevraagd mensen tijd - en dus geld. En vele kleine beetjes maken vanzelf een dikke Ferrari

Bovendien kan je met je servertje meer mensen sneller achter elkaar bedienen.

[ Voor 7% gewijzigd door Rataplan op 06-01-2004 21:37 ]

[crisp]

Rataplan schreef op 06 januari 2004 @ 21:36:
[...]

[knip]

wel eens gehoord van http-compressie? dan maken die paar enters en tabjes ook niet veel meer uit hoor. Hier op GoT hadden we vroeger de optie om de topiclijsten mbv javascript te laten genereren, maar uiteindelijk is gebleken dat met http-compressie de volledige sourcecode nagenoeg net zo groot was als de javascript versie.

Ik hou wel degelijk rekening met de grootte van de source in de templates (vergeleken met 3 maanden terug is die al zo'n 25% kleiner door meer gebruik te maken van CSS), maar ik ga niet meer op een paar bytes bezuinigen.

Nu moet ik wel zeggen dat de templates netjes geindent zijn mbv tabs en enters, maar dat de templateparser die er allemaal uitstripped.

Qua programmeren neig ik zelf sterk naar performance, en er zijn dus een aantal 'standaard' dingen die ik steevast anders doe. Zo gebruik ik bijvoorbeeld bijna nooit een for-constructie maar meestal een while of do-while. Zeker als volgorde niet uitmaakt doe ik het vaak zo:

JavaScript:

var i = 1000;
do {
  // code
} while (--i);

[ Voor 20% gewijzigd door crisp op 06-01-2004 21:49 ]

[Verwijderd]

Wat ik me nu afvraag is hoe jullie variabelen die bestaan uit meerdere woorden (hoort ook bij programmeerstijl) opschrijven.

Bijvoorbeeld zoals ik het doe:
int dit_is_een_lange_integer_variabele = -1;

Terwijl er ook mensen zijn die het volgende doen:
int ditIsEenLangeIntegerVariabele = -1;

Ikzelf vind de underscores beter leesbaar, en je verwart het ook niet met funtienamen. Ik kan het zo irritant vinden als iemand dat in semi Breezah stijl opschrijft _nofi.

[ Voor 7% gewijzigd door Verwijderd op 06-01-2004 21:54 ]

[whoami]

Verwijderd schreef op 06 januari 2004 @ 21:53:
Ikzelf vind de underscores beter leesbaar, en je verwart het ook niet met funtienamen. Ik kan het zo irritant vinden als iemand dat in semi Breezah stijl opschrijft _nofi.

Ik gebruik de Pascal-Casing stijl. Deze dus:

code:

DitIsMijnVariabeleNaam

voor Public members/Properties. Gewoon om consistent te blijven met het framework (.NET) dat ik gebruik.

Parameters van functies en variablen, daarvoor gebruik ik CamelCasing:

code:

public void MyFunction( int myParameter)
{
      string                   myString;
}

Het staat slordig vind ik, als je begint met stijlen te mixen.
Als je een framework gebruikt, dat ook _ gebruikt in z'n variabele namen, dan kan je dat ook het beste doen.

[ Voor 12% gewijzigd door whoami op 06-01-2004 22:02 ]

[pjonk]

Ik vind het zelf irritant als mensen oneindig lange functies maken waarin veel te veel lokale variabelen gebruikt worden en de code bijna niet normaal te debuggen is. Ik stel altijd de regel je kan maar niet vaak genoeg code opsplitsen.

Qua coding style hoe ik er wel van als mensen de operators netjes scheiden door een spatie af en toe een lege regel etc. Als men code gaat proppen krijg ik pijn aan m'n ogen.

[Rataplan]

crisp schreef op 06 januari 2004 @ 21:45:
wel eens gehoord van http-compressie? dan maken die paar enters en tabjes ook niet veel meer uit hoor. Hier op GoT hadden we vroeger de optie om de topiclijsten mbv javascript te laten genereren, maar uiteindelijk is gebleken dat met http-compressie de volledige sourcecode nagenoeg net zo groot was als de javascript versie.

Wel eens van gehoord, ja Nuttige informatie, thanks!

Nu moet ik wel zeggen dat de templates netjes geindent zijn mbv tabs en enters, maar dat de templateparser die er allemaal uitstripped.

Dat doe ik dus zelf al

Qua programmeren neig ik zelf sterk naar performance

Amen! En de layout die mij daarbij het beste helpt wordt dus gebruikt

[RayNbow]

Verwijderd schreef op 06 januari 2004 @ 21:53:
Wat ik me nu afvraag is hoe jullie variabelen die bestaan uit meerdere woorden (hoort ook bij programmeerstijl) opschrijven.

Bijvoorbeeld zoals ik het doe:
int dit_is_een_lange_integer_variabele = -1;

Ik gebruik alleen underscores in constanten zoals MAX_AANTAL en alleen als ik vind dat het nodig is.

Terwijl er ook mensen zijn die het volgende doen:
int ditIsEenLangeIntegerVariabele = -1;

Ik gebruik deze stijl voor functienamen en variabelen in Java. Ik probeer echter zo kort mogelijke namen te gebruiken. _{(Deze stijl heb ik uit een Java boek overgenomen)}

whoami schreef op 06 januari 2004 @ 22:01:
[...]


Ik gebruik de Pascal-Casing stijl. Deze dus:

code:

DitIsMijnVariabeleNaam

Die stijl voor variabele namen gebruik ik meestal in VB. Voor control namen in VB prefix ik ze altijd met "chk", "cmd", "lst", etc. In ASP/VBS prefix ik variabelen die Strings of Objecten zijn met "str" en "obj".

Zoals je ziet verschilt mijn coding stijl qua naamgeving per taal, maar dat komt voornamelijk door het gebruik van hoofdletters in de verschillende talen zelf.

[Delphi32]

RayNbow schreef op 06 januari 2004 @ 22:33:
Ik gebruik alleen underscores in constanten zoals MAX_AANTAL en alleen als ik vind dat het nodig is.

Dit principe (consts in uppercase) hebben we hier op het werk helaas ook. Tot in het absurde toe: True en False zijn eigenlijk constanten dus moeten in UPPERCASE, same voor enumeraties. Ik heb daar toch wat bezwaren tegen.
Voor enumeraties geldt dat daar zeer fraaie en in mijn ogen zeer leesbare standaarden zijn (in Delphi iig):

Delphi:

type TImportantEnumeration = (ieFirst, ieSecond, ieOpera, ..);

Voor constanten geldt het volgende: wat ik vandaag als constante definieer zou ik morgen wel eens als function willen implementeren. Waarom dan met uppercase een onderscheid gaan maken tussen de twee manieren om die waarde MaxAantal te verkrijgen? Je trekt een implementatie-aspect (de waarde van Max aantal dus) binnen in je design (nl dát er een max aantal is). Wat mij betreft schrijf ik dus MaxAantal en niet MAX_AANTAL. (dat hier Engels en NL door elkaar gebruikt wordt is weer een discussie apart).

Die stijl voor variabele namen gebruik ik meestal in VB. Voor control namen in VB prefix ik ze altijd met "chk", "cmd", "lst", etc. In ASP/VBS prefix ik variabelen die Strings of Objecten zijn met "str" en "obj".

Alhoewel ik voor controls vaak stiekum wel een dergelijk Hungarian schema gebruik (heb ooit voor een MS VB certificaat nog die afko's uit mn kop moeten leren) stap ik daar net zo gemakkelijk van af. Controls die in code toch niet gebruikt worden (labels bv, maar ook buttons als je er een ActionList aan hangt (Delphi/BC, C#?)) worden niet gerenamed, controls die maar 1x op je form terecht komen zelden, en voor de overige bekijk ik het per stuk. Ik vind persoonlijk ResourceGrid (een verwijzing naar een grid waarin resources getoond worden) makkelijker leesbaarder dan grdResources.
En waarom zou je alleen strings of objecten prefixen? Doe ze geen van allen, of allemaal, zou ik zeggen. En ik kies toch voor het laatste. Met de huidige generatie tools (code insight/code completion ed) is het type van een variabele zo gemakkelijk te zien dat ik die duffe afkortingen graag weglaat

[riezebosch]

drm schreef op 06 januari 2004 @ 19:09:
Als je dan een reply doet, voeg dan in ieder geval iets toe aan het topic

Ok drm, maar vond dat alle pro's en con's al wel gezegd waren. Maar bedacht met net toch nog wat (vanuit bed): ikzelf geef voorkeur aan ook acolade-openen op volgende regel, omdat zo openen en sluiten op zelfde hoogte staan. En het argument van The_Tzar dat regel iets moet zijn en daarom de acolade-openen erachter moet en niet eronder gaat ook niet op voor acolade-sluiten. Dan zou je die er ook achter moeten zetten...

[.oisyn]

crisp schreef op 06 januari 2004 @ 21:45:
Qua programmeren neig ik zelf sterk naar performance, en er zijn dus een aantal 'standaard' dingen die ik steevast anders doe. Zo gebruik ik bijvoorbeeld bijna nooit een for-constructie maar meestal een while of do-while. Zeker als volgorde niet uitmaakt doe ik het vaak zo:

JavaScript:

var i = 1000;
do {
  // code
} while (--i);

mja, het is maar wat je leuk vind. Ik vind het mierenneukerij, en een for-lusje leest imho duidelijker dan wat je daar doet. Dat een for de conditie checkt al voor de eerste iteratie kun je op de kop toe nemen, bovendien wordt dat vaak weggeoptimaliseerd door de compiler (puur omdat het een aanname kan doen over de variabele die je zojuist geinitialiseerd hebt). Het is natuurlijk wat anders als de conditie bestaat uit een functie-aanroep die wat ingewikkelde shit doorneemt, maar de vraag is of een "simpel" for-lusje dan sowieso wel voldoet (dan moet je idd gaan kijken of een loopje minstens 1 keer doorlopen moet worden, en aan de hand daarvan voor een for/while of een do kiezen).

Bijkomend voordeel van een for-lus is overigens dat je increment-semantics ook gewoon werken bij een continue, wat bij een while/do lus niet het geval is

[RayNbow]

Delphi32 schreef op 07 januari 2004 @ 00:23:
[...]

Alhoewel ik voor controls vaak stiekum wel een dergelijk Hungarian schema gebruik (heb ooit voor een MS VB certificaat nog die afko's uit mn kop moeten leren) stap ik daar net zo gemakkelijk van af. Controls die in code toch niet gebruikt worden (labels bv, maar ook buttons als je er een ActionList aan hangt (Delphi/BC, C#?)) worden niet gerenamed, controls die maar 1x op je form terecht komen zelden, en voor de overige bekijk ik het per stuk. Ik vind persoonlijk ResourceGrid (een verwijzing naar een grid waarin resources getoond worden) makkelijker leesbaarder dan grdResources.
En waarom zou je alleen strings of objecten prefixen? Doe ze geen van allen, of allemaal, zou ik zeggen. En ik kies toch voor het laatste. Met de huidige generatie tools (code insight/code completion ed) is het type van een variabele zo gemakkelijk te zien dat ik die duffe afkortingen graag weglaat

Controls die ik niet in de code gebruik geef ik ook geen eigen naam. Over het prefixen in ASP/VBS, dat komt omdat ik voornamelijk alleen de variabelenamen strSQL, objConn, objCmd, en objRS gebruik

[Janoz]

Delphi32 schreef op 07 januari 2004 @ 00:23:
Voor constanten geldt het volgende: wat ik vandaag als constante definieer zou ik morgen wel eens als function willen implementeren. Waarom dan met uppercase een onderscheid gaan maken tussen de twee manieren om die waarde MaxAantal te verkrijgen?

Omdat het nu nog een constante is en pas morgen een functie. Voor het wijzigen gebruik je een refactor tool. Het lijkt me een beetje onzinnig om van standaarden af te wijken omdat je misschien ooit nog wel eens iets gaat veranderen.

Je zult het toch allemaal weer bij langs moeten aangezien een functie aanroep haakjes erachter heeft. Verder is een constante vaak static terwijl dat bij een functie/methode niet zo is.

Je trekt een implementatie-aspect (de waarde van Max aantal dus) binnen in je design (nl dát er een max aantal is).

Toch zijn dat 2 verschillende dingen. De tweede is het feit dat het aantal een bovengrens heeft terwijl het eerste aangeeft op welke waarde deze bovengrens licht.

Wat mij betreft schrijf ik dus MaxAantal en niet MAX_AANTAL. (dat hier Engels en NL door elkaar gebruikt wordt is weer een discussie apart).


[...]

Alhoewel ik voor controls vaak stiekum wel een dergelijk Hungarian schema gebruik (heb ooit voor een MS VB certificaat nog die afko's uit mn kop moeten leren) stap ik daar net zo gemakkelijk van af. Controls die in code toch niet gebruikt worden (labels bv, maar ook buttons als je er een ActionList aan hangt (Delphi/BC, C#?)) worden niet gerenamed, controls die maar 1x op je form terecht komen zelden, en voor de overige bekijk ik het per stuk. Ik vind persoonlijk ResourceGrid (een verwijzing naar een grid waarin resources getoond worden) makkelijker leesbaarder dan grdResources.
En waarom zou je alleen strings of objecten prefixen? Doe ze geen van allen, of allemaal, zou ik zeggen. En ik kies toch voor het laatste. Met de huidige generatie tools (code insight/code completion ed) is het type van een variabele zo gemakkelijk te zien dat ik die duffe afkortingen graag weglaat

mbt hungarian style: Ik heb het zelf nooit wat gevonden. Het achterhalen van het type laat ik wel door de IDE gebeuren. Daarvoor ga ik mijn variabele namen niet 'misbruiken'. Imho zegt het al heel wat dat MS (de grote hungarian aanhanger) zelf met .NET hier vanaf stapt. Ikzelf hou gewoon de naamgeving zoals gebruikt in Java aan.

mbt NL/EN: Is wel ff leuk om dat aan te snijden . Ikzelf probeer alles gewoon in het engels te doen. getEigenschap vind ik een stuk lelijker dan getProperty. Met commentaar wisselt het nog wel eens. Leidraad daar is dat ik duidelijk wil overbrengen wat ik bedoel. Als me dat zo snel niet in het engels lukt zet ik het in het nederlands erneer. Ook veel 'tijdelijk commentaar' doe ik in het nederlands (TODO en FIXME en blauwdruk van een methode ed). Later verwijder ik dit over vertaal het alsnog om de werking te verduidelijken.

[curry684]

Verwijderd schreef op 06 januari 2004 @ 19:52:
Ook nog iets waarbij je veel verschillende meningen ziet: inspringen met tabs of spaties? Zelf gebruik ik altijd liever tabs, maar in sommige coding guides zweren ze toch weer bij het zetten van drie spaties. Zijn er hier ook nog mensen die liever spaties gebruiken en daar een reden voor hebben?

Tabs zijn evil: zet jij maar eens een van je CPP's even online en surf er met een webbrowser heen

Altijd de functie 'Replace tabs with spaces' aanzetten, zit in iedere IDE (en staat in Borland en VS.net default aan geloof ik, VS6 niet).

Ik gebruik zelf verder ook gewoon 2 spaties insprong, maar dat is volgens mij redelijk taalafhankelijk: een taal als C/C++ waar je nogal vaak nested loops bij uit de kast trekt vind ik de overzichtelijkheid lineair afnemen met het aantal spaties per indent. Voor een hogere scripttaal maakt het mij persoonlijk minder uit en vind ik 3 of 4 ook acceptabel.

[Engineer]

.

[ Voor 99% gewijzigd door Engineer op 13-10-2018 11:01 ]

[WildernessChild]

Het verbaast mij dat in deze 6 pagina's de GNU coding style er nog niet tussen staat... zie hier
Ik ben er wel blij om, want deze stijl is echt een ramp

C:

if (x < foo (y, z))
  haha = bar[4] + 5;
else
  {
    while (z)
      {
        haha += foo (z, z);
        z--;
      }
    return ++x + bar ();
  }

Degene die dit bedacht heeft, en dan met name de inspringing, moeten ze opknopen imho
Verder zijn er natuurlijk nog wat dingetjes die ik zelf anders zou doen (spatie na if, while en functie-aanroep, increment in return statement, accolades op nieuwe regel), maar vooral de indent vind ik smerig.

[.oisyn]

curry684 schreef op 07 januari 2004 @ 09:55:
[...]

Tabs zijn evil: zet jij maar eens een van je CPP's even online en surf er met een webbrowser heen

cpp's zijn er niet voor gemaakt om geopend te worden door webbrowsers
(ik gebruik zelf standaard altijd tabs)

Doet Visual Studio eigenlijk ook stapjes van [tabgrootte] als je aan het begin van een ingesprongen regel staat, en de drukt op backspace? Of haalt ie er dan maar slechts 1 spatie af

Ik gok dat VS hier wel rekening mee houdt, maar er zijn editors die dat dus niet doen, en dan zijn spaties echt mega-irritant Maar ik snap je argument om geen tabs te gebruiken, ben het er op zich zelfs wel een beetje mee eens, maar ik blijf toch lekker gewoon tabs gebruiken

[whoami]

.oisyn schreef op 07 januari 2004 @ 20:35:
[...]
Doet Visual Studio eigenlijk ook stapjes van [tabgrootte] als je aan het begin van een ingesprongen regel staat, en de drukt op backspace? Of haalt ie er dan maar slechts 1 spatie af

Als je ingesteld hebt dat je tabs spaces moeten worden, en je doet backspace, dan haalt ie er maar 1 spatie vanaf, en dat is irritant ja.

[Verwijderd]

WildernessChild schreef op 07 januari 2004 @ 20:31:
Het verbaast mij dat in deze 6 pagina's de GNU coding style er nog niet tussen staat... zie hier
Ik ben er wel blij om, want deze stijl is echt een ramp

C:

if (x < foo (y, z))
  haha = bar[4] + 5;
else
  {
    while (z)
      {
        haha += foo (z, z);
        z--;
      }
    return ++x + bar ();
  }

Degene die dit bedacht heeft, en dan met name de inspringing, moeten ze opknopen imho

Deze style is wel even wennen maar sinds ik meewerk aan open source project waar deze style gebruikt heb ik het meeste onbewust toch overgenomen.
Alleen de spatie in de functie aanroepen vind ik zinloos.

Ik denk dat deze style onstaan in een tijd waarin nog niet iedereen syntax highlighting had in hun editor en volgens mij is dit de een van de best leesbare styles als er geen highlighting is.

Verder is de manier van indenten en braces plaatsen niet zo belangrijk als het maar consequent gebeurt. Maar ik kan me wel ergeren aan te lange regels die niet netjes worden afgebroken.

[hobbit_be]

zo dit is dus het use spaces or tabs topic

toch wel ridiculous in een tijd waardat neurale netten stock checks doen, quasi alles met een chipje draait en dan zijn de programmeurs er nog niet in geslaagt een ietwat deftig code 'beautifier' te gebruiken

NOOIT gesnapt

voor 'PHP' gebruik ik PHPEdit. Druk ik op CRTL+F dan formateerd ie lekker het hele bestand naar het format dat ik liefts heb. Kom het van iemand anders geen probleem. Zat ook in JBuilder trouwens. Van Visual STudio weet ik het niet, maar als het er niet inzit - schandalig.

Mijn opinie: ieder zijn stijl waar ie het minste fouten in maakt. (ken mensen die een witte lijn tussen elke regel code proppen). En gewoon deftige editors gebruiken.

En dan is er vast nog hoe noem ik mijn variablen topic

[drm]

En dan is er vast nog hoe noem ik mijn variablen topic

Dat wordt toch alweer een stukje lastiger met je PHPEdit beautifier

[Infinitive]

En gewoon deftige editors gebruiken.

Editors zijn naar mijn mening nog niet geavanceerd genoeg. Vooral voor layout zouden er meer voorkeuren instelbaar moeten zijn die bovendien afhankelijk moeten zijn van de context.

Bijvoorbeeld het hierboven genoemde tabs/backspace probleem. De backspace wordt zowel gebruikt als manier om een niveautje omhoog te gaan wat nesting betreft, en als manier om bijvoorbeeld een stukje code netjes te positioneren. Wanneer je met je cursor in een expressie staat, dan zou je misschien wel willen dat de backspace maar één teken verwijdert. Wanneer je echter op block/statement niveau bezig bent dan wil juist dat de backspace je nesting diepte verlaagt.

Ik betwijfel echter hoever een editor hierin kan gaan. Stel dat je je complete voorkeuren kan definiteren. Zou je dan een editor kunnen maken waarbij je zelf geen expliciete layout meer aangeeft maar dat de editor dit automatisch in jouw style plaatst. Het lijkt me dat je dan een heleboel verschillende voorkeuren hebt. En dat je zelfs met 1000 opties er waarschijnlijk nog achter komt dat je sommige dingen toch nog even met wat spaties en tabs zou willen positioneren omdat het er dan net wat beter uitziet.

[ Voor 27% gewijzigd door Infinitive op 07-01-2004 22:32 ]

[Verwijderd]

Infinitive schreef op 07 januari 2004 @ 22:30:
Bijvoorbeeld het hierboven genoemde tabs/backspace probleem. De backspace wordt zowel gebruikt als manier om een niveautje omhoog te gaan wat nesting betreft, en als manier om bijvoorbeeld een stukje code netjes te positioneren. Wanneer je met je cursor in een expressie staat, dan zou je misschien wel willen dat de backspace maar één teken verwijdert. Wanneer je echter op block/statement niveau bezig bent dan wil juist dat de backspace je nesting diepte verlaagt.

Vim haalt hier toch echt een complete "tab" weg (die dus uit spaties bestaat) op het moment dat ik ergens via de tab toets spaties ingevoegd heb. Bij alle andere gevallen haalt hij maar 1 karakter weg

[drm]

Editors zijn naar mijn mening nog niet geavanceerd genoeg. Vooral voor layout zouden er meer voorkeuren instelbaar moeten zijn die bovendien afhankelijk moeten zijn van de context.

Je zou voor de gein eens naar IDEA moeten kijken. Dat is een IDE waarvan ik zeg: Die mag er wezen. Als er voor elke taal zo'n IDE zou zijn zou ik in m'n handjes wrijven.

Het is dus mogelijk, er wordt echter veel te weinig aandacht aan besteed... Hoeveel programmaatjes zijn er niet met syntax highlighting? En hoeveel met codesweepers? Wat zou de verhouding ongeveer zijn? 50:1 ofzo

De backspace wordt zowel gebruikt als manier om een niveautje omhoog te gaan wat nesting betreft, en als manier om bijvoorbeeld een stukje code netjes te positioneren.

Dit vind ik dus echt heel vreemd. Waarom zou een backspace in vredesnaam een compleet niveau hoger moeten zijn? Als je met spaces werkt is een backspace gewoon één space back.

Voor unindent (wat jij bedoelt) gewoon shift+tab of ctrl+u. Backspace moet alleen maar doen waar het voor gemaakt is; het karakter voor de cursor weghalen. Als dat dan een tab-character is; sja dan doe je een unindent, maar ik werk niet met tab-characters dus daar heb ik geen last van

[.oisyn]

wat doet een codesweeper precies?

[drm]

.oisyn:
wat doet een codesweeper precies?

codesweeper == beautifier