[Alg] Code layout: tabs of spaties

maandag 16 januari 2006 19:03

Paul Nieuwkamp schreef op maandag 16 januari 2006 @ 16:55:

Ik wil bij deze even ranten op tabs <> spaties en hardcoded coordinaten op afdrukken.

Ik mocht vandaag op mijn werk bij een aantal af te drukken lijsten met relatiegegevens het mobiele nummer erbij zetten... Naam, adres,telefoonnummer, fax, mobiele nummer etc..
Uiteraard staat dit bovenaan de pagina, en uiteraard mag dan alles eronder een regel opshuiven. Wat zeg ik, een simpele regel? Nee, 300 hardcoded coordinaten met de hand 50 ophogen. Of eigenlijk, 66 met 50, nog eens 66 met 100 en het laatste derde deel met 150px, want er moesten niet 1, maar 3 mobiele nummers bij
En ik krijg de tijd en toestemming niet om dat zo aan te passen dat er (minimaal) steeds een var gebruikt wordt die je om de regel met 50 ophoogt, even de mogelijk nettere manieren daargelaten.

Kom ik meteen bij tabs <> spaties... Vroeger, ooit, eens, 4 jaar geleden, had een werknemer zijn "tab == x spaties" in de IDE op 2 gezet, want wij springen met zijn allen 2 spaties in.
Nu, 4 jaar later, collega al 3.5 jaar weg, nooit iemand naar die code om hoeven kijken, mag ik het aanpassen (Die mobiele nummers). We zijn ondertussen al tig Windows installs en 2 computers verder, en tabs == x spaties staat vrolijk op de default van 8, want iedereen gebruikt spaties.

Wat een irritante klerezooi is nu die code van die collega. Als hij nu OVERAL tab gebruikt had.. Nee, zo'n beetje random tab of 2x spatie.
Ik heb eerst een kwartier 300 regels correct lopen inspringen (inclusief then terugzetten naar dezelfde regel als de bijbehorende if, de begin erachter wel naar een andere regel, hoofdletters (If, OR, AND) weer naar de coding standaard zoals we die gebruiken terug gezet etc.

Ben blij dat er nu niemand meer tabs gebruikt en de coding standaard goed is gecommuniceerd...

Waarom geen TABs ? Ik zou JUIST tab's gebruiken, omdat je veelal in een editor kunt aangeven hoe tabs moeten worden omgezet. (oftewel, hoe breed een tab is). Met spaties heb je dat dus niet, en ben je overgeleverd aan de hoeveelheid spaties die gekozen is. Ik heb nooit begrepen waarom mensen spaties gebruiken voor indents ipv tabs

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

cvs79

Verwijderd schreef op maandag 16 januari 2006 @ 18:58:
[...]

In VS 2005 Ctrl+K, Ctrl+D.
Zie je wel dat VS2005 een stuk productiever is geworden

Haha,

Als dat jou definitie van productiever is

maandag 16 januari 2006 19:20

Acties:

Paul

EfBe schreef op maandag 16 januari 2006 @ 18:58:
[...]

Waarom geen TABs ? Ik zou JUIST tab's gebruiken, omdat je veelal in een editor kunt aangeven hoe tabs moeten worden omgezet. (oftewel, hoe breed een tab is). Met spaties heb je dat dus niet, en ben je overgeleverd aan de hoeveelheid spaties die gekozen is. Ik heb nooit begrepen waarom mensen spaties gebruiken voor indents ipv tabs

Omdat je bij inspringen van slechts 2 posities al bijna automatisch spaties gebruikt. Tabs zijn voor het grove werk ze maar

Als je 4 of zelfs nog meer inspringt is het inderdaad gekkenwerk om dat met spaties te doen, maar _voor mij_ is 2x spatie 'natuurlijker' dan tab. Tab is ook "helemaal" naar links en naar boven, terwijl ik de rest zo ongeveer blind doe

Daarnaast is een tab default zo goed als overal 8. Stel je het in op (bijvoorbeeld) 2, gebruik je een andere editor (al dan niet programmeer-related), ros je op tab, mag je weer helemaal backspacen/shift-tabben/weet ik het

"Your life is yours alone. Rise up and live it." - Richard Rahl
Rhàshan - Aditu Sunlock

maandag 16 januari 2006 19:31

Acties:

Sendy

EfBe schreef op maandag 16 januari 2006 @ 18:58:
[...]

Waarom geen TABs ? Ik zou JUIST tab's gebruiken, omdat je veelal in een editor kunt aangeven hoe tabs moeten worden omgezet. (oftewel, hoe breed een tab is). Met spaties heb je dat dus niet, en ben je overgeleverd aan de hoeveelheid spaties die gekozen is. Ik heb nooit begrepen waarom mensen spaties gebruiken voor indents ipv tabs

Juist voor het tegengestelde argument. Als iedereen spaties gebruikt ziet de source er overal hetzelfde uit. Er is dus nooit verwarring over de indentatie.

edit:
Op mijn werk gebruiken we spaties, maar we doen dan ook assembler met een macrotaal. Thuis gebruik ik tabs die ik voor verschillende sources anders instel: HTML tabs van 2 spaties, Javascript, CSS en andere code meestal tabs van 8 spaties.

[ Voor 18% gewijzigd door Sendy op 16-01-2006 19:33 ]

maandag 16 januari 2006 19:38

Acties:

Verwijderd

Tabs zuigen, omdat de breedte ervan niet standaard vaststaat. Van spaties wel.

Verder krijg je van dat irritante gedrag dat als je ergens iets tussentypt, dat dan je regel niet verderschuift, omdat hij de tab nog aan het invullen is etc.

Identen doe je met spaties, niet met tabs.

maandag 16 januari 2006 19:53

Acties:

Rhapsody

In Metal We Trust

Verwijderd schreef op maandag 16 januari 2006 @ 19:38:
Tabs zuigen, omdat de breedte ervan niet standaard vaststaat. Van spaties wel.

Verder krijg je van dat irritante gedrag dat als je ergens iets tussentypt, dat dan je regel niet verderschuift, omdat hij de tab nog aan het invullen is etc.

Identen doe je met spaties, niet met tabs.

Ik ben het niet met je eens.
Met tabs is het voor iedereen prettig. Iedereen kan in zijn/haar favo editor instellen hoeveel spaties 1 tab is. De een gebruikt een indent van 3 spaties, de ander 4 etc etc.

En wat bedoel je met het verderschuiven van een regel

Ik heb er echt nooooooit problemen mee (werk met UltraEdit en Visual Studio. Visual Studio regelt het allemaal zelf)

En het argument dat iedereen een zelfde indent zou moeten gebruiken is iets van onmogelijk is natuurlijk. Dat is hetzeflde als zeggen dat iedereen engels zou moeten spreken

[ Voor 11% gewijzigd door Rhapsody op 16-01-2006 19:56 ]

🇪🇺 pro Europa! | Puinhoop Veroorzaken en Vertrekken (PVV)

maandag 16 januari 2006 19:57

Acties:

Verwijderd

De een gebruikt een indent van 3 spaties, de ander 4 etc etc.

Extreem vies, niets van dat eigengereide gedrag van devvers graag. In de stijlgids staat hoeveel spaties er gebruikt dienen te worden, en daar heeft iedereen zich aan te houden. Persoonlijke voorkeuren zijn irrelevant

En het argument dat iedereen een zelfde indent zou moeten gebruiken is iets van onmogelijk is natuurlijk.

Daar is anders niets natuurlijks aan? Zoiets heet een stijlgids

[ Voor 25% gewijzigd door Verwijderd op 16-01-2006 19:57 ]

maandag 16 januari 2006 19:57

Acties:

maandag 16 januari 2006 19:57

Fotograaf

tabs zijn irritant imo, omdat die toets ver weg zit, enkele spaties zijn dan sneller ingevoerd

maar gelukkig zijn er simpele commando's om die zooi om te zetten

Acties:

Rhapsody

In Metal We Trust

Verwijderd schreef op maandag 16 januari 2006 @ 19:57:
[...]

Extreem vies, niets van dat eigengereide gedrag van devvers graag. In de stijlgids staat hoeveel spaties er gebruikt dienen te worden, en daar heeft iedereen zich aan te houden. Persoonlijke voorkeuren zijn irrelevant

Ik denk dat iedereen een andere stijlgids hanteerd

Voordeel is gewoon dat als een ander tabs gebruikt jij niet te maken hebt met een andere indent dan dat je gewend bent

[ Voor 14% gewijzigd door Rhapsody op 16-01-2006 19:58 ]

🇪🇺 pro Europa! | Puinhoop Veroorzaken en Vertrekken (PVV)

maandag 16 januari 2006 20:00

Acties:

Verwijderd

Rhapsody schreef op maandag 16 januari 2006 @ 19:57:
Ik denk dat iedereen een andere stijlgids hanteerd

Ik denk het niet. Er is maar één stijlgids in gebruik binnen een bedrijf.

Voordeel is gewoon dat als een ander tabs gebruikt jij niet te maken hebt met een andere indent dan dat je gewend bent

Dat kan voorkomen als je overstapt van werkgever idd. Dan heb je dat binnen 2 dagen wel door hoe dat zit met die andere identatie hoor..

Een bedrijf wil niet dat hun coders code schijven zoals ze zelf gewend zijn. Die wil dat mensen code schrijven zodat iedereen binnen dat bedrijf er goed mee kan werken. Dat bereik je alleen dmv. een stijlgids en het volgen ervan.

[ Voor 19% gewijzigd door Verwijderd op 16-01-2006 20:01 ]

maandag 16 januari 2006 20:03

Acties:

Soultaker

Mijn (op uitgebreide ervaring gebasseerde

) voorkeur is ook voor spaties. Dat heeft ook met mijn geprefereerde formatting style te maken. Tabs gaan vaak stuk op dit soort constructies:

C:

void foobar( const char *args, int args_size,
             void (*callback)(int, void*), void *callback_arg,
             int flags = F_ALL ~ ( F_BAR | F_BAZ) )
{
    call_some_function( some_long_argument_name,
                        some_other_argument );
}

Als je hiervoor tabs gebruikt, gaat het mis. Merk op dat je in de eerste drie regels al geen tabs mag gebruiken en op de een na laatste juist eerst een tab, en dan spaties. In een editor die tabs niet zichtbaar maakt gaat het dan zo makkelijk stuk (dan staan er dus tabs i.p.v. spaties) waardoor het niet meer goed werkt als je de tab space anders zet.

Sowieso hanteer ik graag een bepaalde breedte waarna ik een regel afbreek; 80 kolommen voor shell scripts en vaak 100 kolommen voor C/C++/PHP code. Zoiets is alleen vol te houden als de tab space een beetje zinnig ingesteld staat.

Verder komt het vaak voor dat een bestand door iemand gewijzigd wordt, waarbij tabs vervangen worden door spaties. Het is praktisch onmogelijk om die dan weer terug te zetten (want, zoals in het voorbeeld hierboven, kun je niet zomaar alle leading spaces in tabs omzetten). Dubbel irritant is als dat gebeurt is met een verkeerde tab space, want dan staan er ook nog verkeerde hoeveelheden spaties in. Als je al met spaties werkte om te beginnen zal dat nooit gebeuren, en de eventuele tabs omzetten naar spaties is eenvoudig te doen.

[ Voor 21% gewijzigd door Soultaker op 16-01-2006 20:05 ]

maandag 16 januari 2006 20:07

Acties:

Super_ik

haklust!

code:

Chapter 1: Indentation

Tabs are 8 characters, and thus indentations are also 8 characters.
There are heretic movements that try to make indentations 4 (or even 2!)
characters deep, and that is akin to trying to define the value of PI to
be 3.

Rationale: The whole idea behind indentation is to clearly define where
a block of control starts and ends.  Especially when you've been looking
at your screen for 20 straight hours, you'll find it a lot easier to see
how the indentation works if you have large indentations.

Now, some people will claim that having 8-character indentations makes
the code move too far to the right, and makes it hard to read on a
80-character terminal screen.  The answer to that is that if you need
more than 3 levels of indentation, you're screwed anyway, and should fix
your program.

In short, 8-char indents make things easier to read, and have the added
benefit of warning you when you're nesting your functions too deep.
Heed that warning.

linus over tab gebruik en indenting. rede voor 8 spaties brede tab
zelfs na 24 uur programmeren, ogen half dicht, strak van de coffie kun je nog onderschijden waar je bent in een block

8<------------------------------------------------------------------------------------
Als ik zo door ga haal ik m'n dood niet. | ik hou van goeie muziek

maandag 16 januari 2006 20:27

Acties:

maandag 16 januari 2006 20:29

Fotograaf

The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.

right:

dus meer dan 3 levels is fout en mag dus eigenlijk niet voorkomen

code:

public class Blaat {
  public void doeMeuk(User u) {
    for(int i=0; i<u.aantalTanden(); i++){
      if (u.isTandAanwezig(i)){
        u.slaTandEruit(i);
      }
    }
  }
}

Acties:

Verwijderd

Ik zal linux eens mailen dat ie dat kerneltje van 'm moet fixxen, want daar zitten ook regelmatig meer dan 3 niveau's diep in

Zijn opmerking is natuurlijk een cheap shot. Ik kan ook zeggen dat als je al beeldschermvullende tabs nodig hebt om te zien in welk blok je zit, dat dan je code ook niet klopt.

maandag 16 januari 2006 21:33

Acties:

MTWZZ

One life, live it!

Erkens schreef op maandag 16 januari 2006 @ 20:27:
dus meer dan 3 levels is fout en mag dus eigenlijk niet voorkomen
code:
1
2
3
4
5
6
7
8
9
public class Blaat {
  public void doeMeuk(User u) {
    for(int i=0; i<u.aantalTanden(); i++){
      if (u.isTandAanwezig(i)){
        u.slaTandEruit(i);
      }
    }
  }
}

Tsja maar die uitspraak is dan ook gebaseerd op C en niet op Java (geloof ik)/C#

Nu met Land Rover Series 3 en Defender 90

maandag 16 januari 2006 21:34

Acties:

Verwijderd

MTWZZ schreef op maandag 16 januari 2006 @ 21:33:
Tsja maar die uitspraak is dan ook gebaseerd op C en niet op Java (geloof ik)/C#

Dat is dus totaal niet relevant, zelfs niet in de verte. De structuren erachter zijn voor alle talen grofweg gelijk.

maandag 16 januari 2006 22:23

Acties:

Verwijderd

Gelukkig worden steeds meer schermen in breedbeeld uitgevoegd en werken steeds meer programmeurs met 2 of 3 schermen: code fullscreen op je middelste (breedbeeld) scherm, toolboxjes en andere panes lekker op je andere scherm. Nooit meer gezeik over code die niet past.

Dat is dus totaal niet relevant, zelfs niet in de verte. De structuren erachter zijn voor alle talen grofweg gelijk.

Behalve dan dat bij C je de class scope niet hebt he!? Inkoppertje!

[ Voor 29% gewijzigd door Verwijderd op 16-01-2006 22:24 ]

maandag 16 januari 2006 22:26

Acties:

dinsdag 17 januari 2006 08:06

Fotograaf

MTWZZ schreef op maandag 16 januari 2006 @ 21:33:
[...]

Tsja maar die uitspraak is dan ook gebaseerd op C en niet op Java (geloof ik)/C#

ok, dan pak ik er toch een stukje c bij?

C:

unsigned long probe_irq_on(void)
{
// KNIP
         /*
          * Now filter out any obviously spurious interrupts
          */
         val = 0;
         for (i = 0; i < NR_IRQS; i++) {
                 irq_desc_t *desc = irq_desc + i;
                 unsigned int status;

                 spin_lock_irq(&desc->lock);
                 status = desc->status;

                 if (status & IRQ_AUTODETECT) {
                         /* It triggered already - consider it spurious. */
                         if (!(status & IRQ_WAITING)) {
                                 desc->status = status & ~IRQ_AUTODETECT;
                                 desc->handler->shutdown(i);
                         } else
                                 if (i < 32)
                                         val |= 1 << i;
                 }
                 spin_unlock_irq(&desc->lock);
         }
// KNIP
}

rechtstreeks uit de linux kernel source

Acties:

MTWZZ

One life, live it!

@Erkens: Ja mooi he

Ik snap hem ook wel hoor, het is meer een "guideline" dan echte regels. Op zich past deze uitspraak dan ook wel binnen de Linux kernel typen van uitspraken

Nu met Land Rover Series 3 en Defender 90

dinsdag 17 januari 2006 08:28

Acties:

Joghert

Erkens schreef op maandag 16 januari 2006 @ 22:26:
[...]

ok, dan pak ik er toch een stukje c bij?

C:

unsigned long probe_irq_on(void)
{
// KNIP
         /*
          * Now filter out any obviously spurious interrupts
          */
         val = 0;
         for (i = 0; i < NR_IRQS; i++) {
                 irq_desc_t *desc = irq_desc + i;
                 unsigned int status;

                 spin_lock_irq(&desc->lock);
                 status = desc->status;

                 if (status & IRQ_AUTODETECT) {
                         /* It triggered already - consider it spurious. */
                         if (!(status & IRQ_WAITING)) {
                                 desc->status = status & ~IRQ_AUTODETECT;
                                 desc->handler->shutdown(i);
                         } else
                                 if (i < 32)
                                         val |= 1 << i;
                 }
                 spin_unlock_irq(&desc->lock);
         }
// KNIP
}

rechtstreeks uit de linux kernel source

Dit geheel blijft netjes binnen de 80 tekens en is daardoor alsnog prima leesbaar in een console.
Dus geen probleem lijkt mij.

dinsdag 17 januari 2006 09:53

Acties:

Verwijderd

Joghert schreef op dinsdag 17 januari 2006 @ 08:28:
Dit geheel blijft netjes binnen de 80 tekens en is daardoor alsnog prima leesbaar in een console.
Dus geen probleem lijkt mij.

.. wat niet wegneemt dat het meer dan 3 niveaus diep is, wat volgens Linus betekende dat je code niet klopt...

dinsdag 17 januari 2006 09:57

Acties:

dinsdag 17 januari 2006 10:04

Soultaker schreef op maandag 16 januari 2006 @ 20:03:
Mijn (op uitgebreide ervaring gebasseerde ) voorkeur is ook voor spaties. Dat heeft ook met mijn geprefereerde formatting style te maken. Tabs gaan vaak stuk op dit soort constructies:
C:
1
2
3
4
5
6
7
void foobar( const char *args, int args_size,
             void (*callback)(int, void*), void *callback_arg,
             int flags = F_ALL ~ ( F_BAR | F_BAZ) )
{
    call_some_function( some_long_argument_name,
                        some_other_argument );
}
Als je hiervoor tabs gebruikt, gaat het mis. Merk op dat je in de eerste drie regels al geen tabs mag gebruiken en op de een na laatste juist eerst een tab, en dan spaties. In een editor die tabs niet zichtbaar maakt gaat het dan zo makkelijk stuk (dan staan er dus tabs i.p.v. spaties) waardoor het niet meer goed werkt als je de tab space anders zet.

Het zal wel teveel zijn weggezakt die hard-core C, maar ik zie niet echt in waarom ik geen tab mag gebruiken in de 1e drie regels, omdat de lexical analyzer van de gemiddelde C compiler echt tabs en spaces beide als whitespace ziet.

Sowieso hanteer ik graag een bepaalde breedte waarna ik een regel afbreek; 80 kolommen voor shell scripts en vaak 100 kolommen voor C/C++/PHP code. Zoiets is alleen vol te houden als de tab space een beetje zinnig ingesteld staat.

Ach, dat gefocus op 80 columns breed... het is 2006, mensen die nu nog op een WYSE terminal hun werk willen doen, moeten toch eens gaan nadenken.

Zelf gebruik ik op 1600x1200 lucida console 9pt (in vs.net 2005, in 2003 werkt de editor alleen met courier bugfree in C#) en breek een regel af wanneer deze van het scherm af loopt. Nooit echt problemen mee gehad.

Ik snap bv niet echt goed waarom men minder diep wil indenten dan 4 spaties (default in vs.net), want dat is op een gegeven moment niet meer leesbaar. Maar goed, dezelfde soort discussies kun je ook voeren of enkelregelige if blokken wel of niet in {} gevat moeten worden, je komt er toch niet uit.

Maar jij hamert dus 4 keer op de spacebar voor elke indent?

Verder komt het vaak voor dat een bestand door iemand gewijzigd wordt, waarbij tabs vervangen worden door spaties. Het is praktisch onmogelijk om die dan weer terug te zetten (want, zoals in het voorbeeld hierboven, kun je niet zomaar alle leading spaces in tabs omzetten). Dubbel irritant is als dat gebeurt is met een verkeerde tab space, want dan staan er ook nog verkeerde hoeveelheden spaties in. Als je al met spaties werkte om te beginnen zal dat nooit gebeuren, en de eventuele tabs omzetten naar spaties is eenvoudig te doen.

Het zou ook nooit gebeuren als iedereen gewoon met zn tengels van instellingen als "insert tab as spaces" zou afblijven, dan blijven nl. tabs gewoon staan.

Verwijderd schreef op dinsdag 17 januari 2006 @ 09:53:
[...]
.. wat niet wegneemt dat het meer dan 3 niveaus diep is, wat volgens Linus betekende dat je code niet klopt...

Tja, en dan is het zo he?

Net zulke kolder als "Als je routine meer dan 24 regels is dan moet je het opdelen want dan is je code niet goed". Goh, zou het toeval zijn dat dat getal toch wel erg overeen komt met het aantal regels dat vt100 terminals en aanverwante antieke zooi konden weergeven? het is 2006, veel ontwikkelaars zitten tegen 2 of zelfs meer schermen aan te kijken, als je dan loopt te emmeren dat de code niet op een terminal past dan ben je IMHO blijven hangen in het stenen tijdperk.

[ Voor 13% gewijzigd door EfBe op 17-01-2006 10:00 ]

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

Verwijderd

EfBe schreef op dinsdag 17 januari 2006 @ 09:57:
Ach, dat gefocus op 80 columns breed... het is 2006, mensen die nu nog op een WYSE terminal hun werk willen doen, moeten toch eens gaan nadenken.

Agreed.

Zelf gebruik ik op 1600x1200 lucida console 9pt (in vs.net 2005, in 2003 werkt de editor alleen met courier bugfree in C#) en breek een regel af wanneer deze van het scherm af loopt. Nooit echt problemen mee gehad.

Jij niet misschien, maar dit is wat mij betreft weer het andere uitsterste. Beeldvullend coden op 1600x1200 is imo niet goed bezig zijn. 80 kolommen is inderdaad niet zo heel erg gangbaar meer (alhoewel het wel prettig is als iemand zich daar aan gehouden heeft, als je op de console iets aan moet passen) maar 1600x1200 is net zo 'niet-gangbaar'. Daarmee maak je je code oneditbaar voor veel mensen met een laptop, bijvoorbeeld. Om heel eerlijk te zijn vind ik het een beetje egotripperij, jij bent niet de enige die jouw code moet kunnen gebruiken/lezen. Als je nou van 1024x768 was uitgegaan, dat was al een meer gangbare maat geweest.

Ik snap bv niet echt goed waarom men minder diep wil indenten dan 4 spaties (default in vs.net), want dat is op een gegeven moment niet meer leesbaar.

Ik vind het anders prima leesbaar?

Het zou ook nooit gebeuren als iedereen gewoon met zn tengels van instellingen als "insert tab as spaces" zou afblijven, dan blijven nl. tabs gewoon staan.

Tsja, alleen blijkt dat in de praktijk gewoon niet zo te werken. Dus zijn spaties een betere keuze.

dinsdag 17 januari 2006 10:35

Acties:

dinsdag 17 januari 2006 11:05

achter de duinen

Verwijderd schreef op dinsdag 17 januari 2006 @ 10:04:
Ik vind het anders prima leesbaar?

Om heel eerlijk te zijn vind ik het een beetje egotripperij, jij bent niet de enige die jouw code moet kunnen gebruiken/lezen.

Tegen het einde van de dag zie ik het verschil niet meer hoor tussen 2 en 4 spaties. Jij misschien wel, maar genoeg anderen niet.

Tsja, alleen blijkt dat in de praktijk gewoon niet zo te werken. Dus zijn spaties een betere keuze.

Want? Nooit last van gehad, eigenlijk

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.

Acties:

frickY

Ik heb ooit eens een HTML pagina van ruim 300kb terug gebracht naar 30kb, puur door het vervangen van de psaties met een tabje. 8 spaties zijn 8 bytes, waar 1 tabje er maar 1 is. Dat kan een hele berg schelen!

dinsdag 17 januari 2006 11:06

Acties:

Zoijar

Because he doesn't row...

Soultaker schreef op maandag 16 januari 2006 @ 20:03:
Mijn (op uitgebreide ervaring gebasseerde ) voorkeur is ook voor spaties. Dat heeft ook met mijn geprefereerde formatting style te maken. Tabs gaan vaak stuk op dit soort constructies:
C:
1
2
3
4
5
6
7
void foobar( const char *args, int args_size,
             void (*callback)(int, void*), void *callback_arg,
             int flags = F_ALL ~ ( F_BAR | F_BAZ) )
{
    call_some_function( some_long_argument_name,
                        some_other_argument );
}

Ik hou het toch op tabs... spaties vind ik erg irritant... maar een goede IDE kan met beiden omgaan.

C:

void foobar(
    const char *args,
    int args_size,
    void (*callback)(int, void*),
    void *callback_arg,
    int flags = 
        F_ALL ~ ( F_BAR | F_BAZ)
) {
    call_some_function(
        some_long_argument_name,
        some_other_argument
    );
}

dinsdag 17 januari 2006 11:07

Acties:

whoami

Topicstarter

frickY schreef op dinsdag 17 januari 2006 @ 11:05:
Ik heb ooit eens een HTML pagina van ruim 300kb terug gebracht naar 30kb, puur door het vervangen van de psaties met een tabje. 8 spaties zijn 8 bytes, waar 1 tabje er maar 1 is. Dat kan een hele berg schelen!

Mja.... daar maakt het dan wel uit, omdat je HTML pagina naar de client verstuurd wordt. Als het echter om 'gewone' code files gaat (C#, Java, Delphi, etc....) die gecompiled worden, heeft de grootte niet echt een belang.

https://fgheysels.github.io/

dinsdag 17 januari 2006 11:20

Acties:

Michali

Ik ben zelf ook sterk voor tabs. Het is gewoon de meest logische oplossing. 1 teken per indentatie niveau en je kunt zelf ook nog eens instellen hoe groot die visueel wordt afgebeeld. Daar kan helemaal geen verwarring om ontstaan lijkt me.

Waar ik verder erg tegen ben is het uitlijnen van parameters om naast andere parameters te komen staan. Beter vind ik om dan alle parameters gewoon de volgende regel te zetten, allemaal 1 extra stapje geindenteerd. Precies zoals Zoijar laat zien dus.

Niet alleen krijg je dan soms problemen met uitlijnen, daarnaast maakt het aanpassingen moeilijker, omdat je dan meer met je indentatie moet gaan zitten klooien. Als je de naam van je functie aanpast moet je alle parameters gaan zitten bijwerken. Dat geeft volgens mij best vaak de neiging om een refactoring maar gewoon te laten, terwijl een verbeterde functie naam best bruikbaar kan zijn.

[ Voor 3% gewijzigd door Michali op 17-01-2006 11:21 ]

Noushka's Magnificent Dream | Unity

dinsdag 17 januari 2006 12:10

Acties:

dinsdag 17 januari 2006 12:19

Verwijderd schreef op dinsdag 17 januari 2006 @ 10:04:
Jij niet misschien, maar dit is wat mij betreft weer het andere uitsterste. Beeldvullend coden op 1600x1200 is imo niet goed bezig zijn. 80 kolommen is inderdaad niet zo heel erg gangbaar meer (alhoewel het wel prettig is als iemand zich daar aan gehouden heeft, als je op de console iets aan moet passen) maar 1600x1200 is net zo 'niet-gangbaar'. Daarmee maak je je code oneditbaar voor veel mensen met een laptop, bijvoorbeeld. Om heel eerlijk te zijn vind ik het een beetje egotripperij, jij bent niet de enige die jouw code moet kunnen gebruiken/lezen. Als je nou van 1024x768 was uitgegaan, dat was al een meer gangbare maat geweest.

Nou, ik heb links de solution explorer dus het is niet helemaal 1600 pixels, en ik kom er eigenlijk nooit aan behalve bij method signatures. Ik hou van lange namen, want liever duidelijkheid dan giswerk.

Wat een breed scherm en dus meer meuk op 1 regel nuttig maakt is dat je meer regels code op je scherm kunt houden. Daarom is lucida console ook prettig want die is qua pixels minder hoog. Hoe meer regels code op je scherm hoe meer overzicht.

[4 spaties wide tab is minimum, minder is niet leesbaar]
Ik vind het anders prima leesbaar?

Ook na een paar uur naar code kijken? Zeker bij de wat complexere routines heb je toch wel eens dat het wenselijk is dat je weet bij welk start { een end } hoort en dat je dat meteen kunt zien. (ookal vertelt de IDE je dat, maar als de startregel net buiten beeld is zie je dat niet)

Maar even voor de goede orde: wie van de spatie-boys/girls tikt echt 4 spaties en wie tikt een tab die wordt omgezet in spaties?

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

chris

Ik werk zelf liever met tabs, maar heb niet echt een goede reden daarvoor. Ik weet wel dat een beetje editor (vim bijvoorbeeld) gewoon kan switchen tussen tabs en spaties, en met een commando kan converteren tussen tabs en spaties. Het maakt volgens mij ook niet zoveel uit, als iedereen maar consequent hetzelfde doet. Vooral handig bij versioning-systemen. Ik vind zelf 4 of 8 spaties per tab erg fijn.

dinsdag 17 januari 2006 12:21

Acties:

Peter

voor PHP gebruik ik altijd tabs, doodgewoon omdat ik dit netter en duidelijker vind staan.

dinsdag 17 januari 2006 12:25

Acties:

Juup

We moeten een Poll houden: Tabs of Spaties?
Het feit dat je kan duscussieren over HOEVEEL spaties dan betekent natuurlijk dat iedereen gewoon tabs zou moeten gebruiken

Ja en dan kun je dus in je editor instellen hoeveel dat 'ie moet inspringen per tab. oooohhhhh...

Een wappie is iemand die gevallen is voor de (jarenlange) Russische desinformatiecampagnes.
Wantrouwen en confirmation bias doen de rest.

dinsdag 17 januari 2006 12:46

Acties:

dinsdag 17 januari 2006 12:46

Even een zinloze discussie een trapje geven

De semantiek van je taal kan afhangen van de hoeveelheid indenting gedefinieerd op spaties. Wanneer je tabs gebruikt, dan schrijf je programma's waarvan het gedrag ongedefinieerd is. Dan ben je net een C++ programmeur

putStr $ map (x -> chr $ round $ 21/2 * x^3 - 92 * x^2 + 503/2 * x - 105) [1..4]

Acties:

Robtimus

me Robtimus no like you

EfBe schreef op dinsdag 17 januari 2006 @ 09:57:
Ach, dat gefocus op 80 columns breed... het is 2006, mensen die nu nog op een WYSE terminal hun werk willen doen, moeten toch eens gaan nadenken.

Ik hou me nog wel meestal aan die grens, vanwege 1 reden: printen.

Ik werk ook op 1280x1024, kan zoals ik textpad nu heb ingesteld 110 karakters per regel gebruiken zonder dat ik wordwrap aan moet zetten, maar als ik een keer code wil printen dan gaat de printer het alsnog wrappen zodat de layout er niet uit ziet.

More than meets the eye
There is no I in TEAM... but there is ME
system specs

dinsdag 17 januari 2006 12:57

Acties:

dinsdag 17 januari 2006 13:17

Moderator Devschuur®

Demotivational Speaker

Infinitive schreef op dinsdag 17 januari 2006 @ 12:46:
De semantiek van je taal kan afhangen van de hoeveelheid indenting gedefinieerd op spaties. Wanneer je tabs gebruikt, dan schrijf je programma's waarvan het gedrag ongedefinieerd is. Dan ben je net een C++ programmeur

Grappig dat juist die parsers een enkele "tab" als indenting zien, en dus schrijf je pas ongedefinieerd gedrag als je spaties gebruikt (want hoeveel levels aan indenting zijn dan 4 spaties?)

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

cavey

Ik laat m'n indenting door EMACS regelen... Waarbij ik de GNU coding style ingesteld heb als m'n default indenting scheme...

krijg je dingen als:

code:

if (.......... blaat)
  {
    int i; // teller
    ... meer statements;
  }

Werkt prima voor mij ^_^ En dat met een schermsize van 120x48 ofzo?

Owja, voor mensen die het verschil niet meer kunnen zien op het einde van de dag tussen 2 en 4 spaties, neem een fixed-width font, ipv proportioneel...

ps: voor degenen die het niet weten, emacs past een "slim" (kuch soms zit het aardig in de weg) algoritme toe tussen tabs en de rest opvullen met spaties... onhandig als je daarna met vi gaat editen, maar ach, andersom is het ook weer irritant. Als ik van kort hak werk in vim naar serieus hakwerk in emacs ga.. Gelukkig heb je daar M-X indent-region voor ^_^

[ Voor 29% gewijzigd door cavey op 17-01-2006 13:18 ]

dinsdag 17 januari 2006 13:30

Acties:

Bosmonster

*zucht*

komakeef schreef op dinsdag 17 januari 2006 @ 13:17:
code:
1
2
3
4
5
if (.......... blaat)
  {
    int i; // teller
    ... meer statements;
  }

Deze indenting krijg ik dus echt de kriebels van!

[ Voor 3% gewijzigd door Bosmonster op 17-01-2006 13:30 ]

dinsdag 17 januari 2006 13:38

Acties:

dinsdag 17 januari 2006 13:45

Fotograaf

komakeef schreef op dinsdag 17 januari 2006 @ 13:17:
ps: voor degenen die het niet weten, emacs past een "slim" (kuch soms zit het aardig in de weg) algoritme toe tussen tabs en de rest opvullen met spaties... onhandig als je daarna met vi gaat editen

tabs en spaties mixen

Als ik voor mezelf dev dan gebruik ik gewoon 2 spaties, vind ik persoonlijk het makkelijkst, meer indenting heb ik niet nodig. Max regel length hou ik het liefst op 120 tekens. Maar normaal gesproken haal je dat niet

Acties:

dinsdag 17 januari 2006 13:46

.oisyn schreef op dinsdag 17 januari 2006 @ 12:57:
Grappig dat juist die parsers een enkele "tab" als indenting zien, en dus schrijf je pas ongedefinieerd gedrag als je spaties gebruikt (want hoeveel levels aan indenting zijn dan 4 spaties?)

Vandaar dat ik "gedefinieerd door spaties" (zoals ik geval van Haskell) erbij heb gezet

putStr $ map (x -> chr $ round $ 21/2 * x^3 - 92 * x^2 + 503/2 * x - 105) [1..4]

Acties:

Verwijderd

De meeste editors die zelf indenting toepassen doen dat toch ook met tabs en niet met spaties? Waarom zou je dan zelf met spaties gaan rommelen.

Maar ook zonder automatische indenting van editors gebruik ik liever een tab hoor. Als je een indenting weghaalt is het gewoon 1x backspace, ipv het aantal spaties, etc.

Ik zie het voordeel van een spatie t.o.v. een tab, danwel het nadeel van het omgekeerde niet echt.

Paul Nieuwkamp schreef op maandag 16 januari 2006 @ 19:20:
[...]

Tab is ook "helemaal" naar links en naar boven, terwijl ik de rest zo ongeveer blind doe

Dan gebruik je zeker ook geen backspace, want die zit helemaal rechtsboven?

dinsdag 17 januari 2006 13:52

Acties:

dinsdag 17 januari 2006 14:06

Fotograaf

Verwijderd schreef op dinsdag 17 januari 2006 @ 13:46:
De meeste editors die zelf indenting toepassen doen dat toch ook met tabs en niet met spaties?

o?

Maar ook zonder automatische indenting van editors gebruik ik liever een tab hoor. Als je een indenting weghaalt is het gewoon 1x backspace, ipv het aantal spaties, etc.

een beetje editor doet hetzelfde met de spaties aan het begin van een regel, de editor weet immers hoeveel spaties je gebruikt

Ik zie het voordeel van een spatie t.o.v. een tab, danwel het nadeel van het omgekeerde niet echt.

groot nadeel van tabs is de inflexibiliteit mbt uitlijnen van argumenten van functies als deze meerdere regels bestrijken

Dan gebruik je zeker ook geen backspace, want die zit helemaal rechtsboven?

bij een backspace heb je een fout gemaakt en is het handig als je hand even weg is van de originele locatie.

Acties:

dinsdag 17 januari 2006 14:07

Moderator Devschuur®

Demotivational Speaker

en een tab is met je pink of ringvinger prima in te toetsen als je je linkerhand gewoon op z'n plek houdt.

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

http://compsoc.dur.ac.uk/whitespace/tutorial.php

Erkens schreef op dinsdag 17 januari 2006 @ 13:38:
[...]

tabs en spaties mixen

putStr $ map (x -> chr $ round $ 21/2 * x^3 - 92 * x^2 + 503/2 * x - 105) [1..4]

dinsdag 17 januari 2006 14:12

Acties:

Verwijderd

Erkens schreef op dinsdag 17 januari 2006 @ 13:52:
[...]

o?

Dat was een vraag, geen mededeling.

[...]

een beetje editor doet hetzelfde met de spaties aan het begin van een regel, de editor weet immers hoeveel spaties je gebruikt

Ok dan zal dit het antwoord op mijn vraag zijn.

[...]

groot nadeel van tabs is de inflexibiliteit mbt uitlijnen van argumenten van functies als deze meerdere regels bestrijken

Kun je dat dan niet oplossen d.m.v. een enter na een argument en zo alles netjes onder elkaar zetten?

[...]

bij een backspace heb je een fout gemaakt en is het handig als je hand even weg is van de originele locatie.

Mijn andere hand blijft anders nog steeds op de locatie. Of geldt je argument alleen voor als je aan de rechterkant van het toetsenbord een fout maakt?

Daarnaast haal ik niet mijn hele hand weg van de toetsen als ik op de tab druk. Alleen mijn ringvinger in principe. Verder pauzeer je ook korte tijd met doortikken als je op de spatie aan het tikken bent, dus maakt het ook weinig uit als je een fractie van een seconde pauzeert als je op de tab drukt. Zie echt geen verschil in dit opzicht.

dinsdag 17 januari 2006 14:28

Acties:

dinsdag 17 januari 2006 14:47

Fotograaf

Verwijderd schreef op dinsdag 17 januari 2006 @ 14:12:
Kun je dat dan niet oplossen d.m.v. een enter na een argument en zo alles netjes onder elkaar zetten?

ehm, ik zie niet wat je bedoeld.

Daarnaast haal ik niet mijn hele hand weg van de toetsen als ik op de tab druk. Alleen mijn ringvinger in principe.

mja, ik duw dan steeds op caps lock

Acties:

BasSpruit

Lekker Tabben!

Tabs lezen gaat imho echt stukken beter. Het levert duidelijke indenting op.

Al die raar geplaatste accolades (met C.... georienteerde talen) die mensen ook nog eens niet altijd plaatsen zijn ook irri. (Alles op dezelfde regel willen hebben)

Of ligt dit aan mij omdat ik een VBer ben?

dinsdag 17 januari 2006 14:48

Acties:

cavey

Erkens schreef op dinsdag 17 januari 2006 @ 14:28:
[...]

ehm, ik zie niet wat je bedoeld.

[...]

mja, ik duw dan steeds op caps lock

Mja, dat uitlijnen doet emacs dus automagisch..... met behulp van tabs en spaties

Daar komt het gemix vandaan. Verder doet Emacs dus alleen maar tabs neer zetten, maar voor de "special" cases zoals bijv. een hele riedel ala

code:

if ( statement
    || statement
    || statement
    || statement )

komen er wat spaties bij voor het extra uitlijnen... Maar goed, ik ga er maar vanuit dat je nooit met emacs hebt zitten coden

WAT EEN GENOT is het om midden in een regel op TAB te kunnen rammen, en de boel wordt uitgelijnd, ipv dat er een tab op je cursor locatie komt >_<

En wat is er mis met de GNU indenting style? Ik vind het zelf behoorlijk leesbaar werken. Je indent is nog steeds 4 spaties, maar je doet een half-way indent voor de curly braces. Niks mis mee dunkt mij? Zie je de "flow" van je code-indenting een stuk beter.

Maar goed, ieder zijn ding

Daarom bestaat dit topic ook waarschijnlijk HAHAHA.

owja, je kan verschillende indent styles "inladen" in emacs.. GNU, K&R en nog wat andere modi die ik vergeten ben...

[ Voor 7% gewijzigd door cavey op 17-01-2006 14:49 ]

dinsdag 17 januari 2006 14:50

Acties:

dinsdag 17 januari 2006 14:55

Erkens schreef op dinsdag 17 januari 2006 @ 14:28:
[...]
mja, ik duw dan steeds op caps lock

Dan pak je een schroevedraaier en haal je de caps lock uit je keyboard, tezamen met de INS toets. Of je pookt de capslock key om naar cntrl oid middels een programaatje. caps lock is imho sowieso een toets die allang gebanned had moeten zijn (tezamen met zn vriendje INS, ik bedoel, wie wil er nou in overtype mode iets intikken...)

Ik heb nog steeds niet gelezen hoe de spatie-ridders hun 4 spaties per indent intikken, kennelijk echt 4 keer op de spatie balk rammen...

komakeef schreef op dinsdag 17 januari 2006 @ 14:48:
komen er wat spaties bij voor het extra uitlijnen... Maar goed, ik ga er maar vanuit dat je nooit met emacs hebt zitten coden WAT EEN GENOT is het om midden in een regel op TAB te kunnen rammen, en de boel wordt uitgelijnd, ipv dat er een tab op je cursor locatie komt >_<

Genot en emacs in 1 zin... naja, ieder zn kicks

[ Voor 27% gewijzigd door EfBe op 17-01-2006 14:52 ]

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

dinsdag 17 januari 2006 15:20

achter de duinen

Indenting stijl is een religieuze discussie. Net als met editors. Daarom neem ik die emacs-zeloot boven me ook niet serieus

Emacs Makes A Computer Slow

Het enige wat geldt bij stijl is dat je consequent moet zijn.

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.

Acties:

dinsdag 17 januari 2006 15:25

Fotograaf

EfBe schreef op dinsdag 17 januari 2006 @ 14:50:
Dan pak je een schroevedraaier en haal je de caps lock uit je keyboard, tezamen met de INS toets. Of je pookt de capslock key om naar cntrl oid middels een programaatje. caps lock is imho sowieso een toets die allang gebanned had moeten zijn (tezamen met zn vriendje INS, ik bedoel, wie wil er nou in overtype mode iets intikken...)

insert gebruik ik nog redelijk vaak met vim. CAPS is ook handig op zijn tijd bij het invoeren van bergen met contstanten

Ik heb nog steeds niet gelezen hoe de spatie-ridders hun 4 spaties per indent intikken, kennelijk echt 4 keer op de spatie balk rammen...

2 spaties

Acties:

dinsdag 17 januari 2006 15:28

Moderator Devschuur®

Demotivational Speaker

EfBe schreef op dinsdag 17 januari 2006 @ 14:50:
(tezamen met zn vriendje INS, ik bedoel, wie wil er nou in overtype mode iets intikken...)

IK, maar goed, jij schijnt dat dus voor anderen te kunnen bepalen

. Maar serieus, ik gebruik overtype regelmatig, vooral als ik iets moet wijzigen in code waar een find&replace niet voldoet. Ik vind het idd vervelend dat als ik mijn hand naar de backspace beweeg ik af en toe op ins ram, maar het is onzin om ze er maar af te slopen. Net als capslock trouwens. Scrolllock is wdb een veel betere kandidaat om geschrapt te worden, maar die zit dan weer niet in de weg.

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

Verwijderd

kenneth schreef op dinsdag 17 januari 2006 @ 14:55:
Indenting stijl is een religieuze discussie.

En vanuit dat oogpunt ben ik voor optie 3: Stijl behoort niet toe aan broncode. Een editor behoort naar de ongeformateerde bron code weer te geven in de stijl waarmee de gebruiker zich prettig voelt.

dinsdag 17 januari 2006 16:10

Acties:

Verwijderd

Verwijderd schreef op dinsdag 17 januari 2006 @ 15:28:
[...]
En vanuit dat oogpunt ben ik voor optie 3: Stijl behoort niet toe aan broncode. Een editor behoort naar de ongeformateerde bron code weer te geven in de stijl waarmee de gebruiker zich prettig voelt.

Dan lijken tabs me de juiste keuze, aangezien spaties altijd in de vorm zijn waarin de originele schrijver het zet. Een volgende 'gebruiker' is dan verplicht in zijn stijl te lezen, terwijl je in editorinstellingen de tabindentgrootte kunt aanpassen.

[ Voor 5% gewijzigd door Verwijderd op 17-01-2006 16:11 ]

dinsdag 17 januari 2006 16:41

Acties:

Paul

EfBe schreef op dinsdag 17 januari 2006 @ 14:50:
Ik heb nog steeds niet gelezen hoe de spatie-ridders hun 4 spaties per indent intikken, kennelijk echt 4 keer op de spatie balk rammen...

2x, maar inderdaad

Bij 4 of hoger zal ik zelf ook eerder naar de tab grijpen.

Bij meerdere regels met dezelfde indent doet de IDE dat voor me, en terug indenten lukt met 1x backspace, de IDE weet / zoekt op waar de vorige indent zat.

"Your life is yours alone. Rise up and live it." - Richard Rahl
Rhàshan - Aditu Sunlock

dinsdag 17 januari 2006 16:46

Acties:

cavey

kenneth schreef op dinsdag 17 januari 2006 @ 14:55:
Indenting stijl is een religieuze discussie. Net als met editors. Daarom neem ik die emacs-zeloot boven me ook niet serieus

Emacs Makes A Computer Slow

Het enige wat geldt bij stijl is dat je consequent moet zijn.

Haha, ik code net zo goed in vim, notepad, scite of welke andere editor hoor

Maar thuis rammel ik bijna al m'n code in emacs, ach, het is niet meer of minder bloat dan dat je Microsoft Word gebruikt om een webpagina te maken

(Besides, ik kan nog een spelletje tetris doen, met gnus m'n mail lezen.. ownee, daar heb ik mutt voor, en nog wat andere nutteloze dingen met emacs

)

Emacs zorgt bij mij iig dat ik een consequente stijl aanhoud met m'n eigen code. Op m'n werk schik ik me naar de codingstijl van het bedrijf: indent van 2 spaties. Ram op tab, zorg ervoor dat je editor de tab omzet naar 2 spaties. Kind kan de was doen. Tja, wat verder ieder z'n voorkeur is @ work, maakt niet uit.. codingstijl = codingstijl.

(En ik zit nu te foeteren op een collega van me die dus consequent z'n eigen stijl aan wil houden >_< en niet eens gebruik heeft gemaakt van enkele templates voor sp's/functies/triggers en views die we hebben >_< )

dinsdag 17 januari 2006 17:02

Acties:

Dido

heforshe

EfBe schreef op dinsdag 17 januari 2006 @ 09:57:
Ach, dat gefocus op 80 columns breed... het is 2006, mensen die nu nog op een WYSE terminal hun werk willen doen, moeten toch eens gaan nadenken.
[...]
als je dan loopt te emmeren dat de code niet op een terminal past dan ben je IMHO blijven hangen in het stenen tijdperk.

Nou, dank je wel hoor

Wees blij dat jullie kunnen indenten!

code:

1011        SUBROUTINE NAME(TEXTLINES)                                         
1012        FETCH      FIELDS(#XGDFID) FROM_FILE(XGDF01) WITH_KEY(ERTS *BLANKS 
                        *BLANKS #OIENUM #BDTNUM #BDPNUM STD)                   
1013        IF_STATUS  IS(*OKAY)                                               
1014        SELECT     FIELDS(#SWDRT50) FROM_FILE(XGDF) WITH_KEY(#XGDFID)       
1015        CHANGE     FIELD(#SWDRT50A) TO(#SWDRT50)                             
1016        EXECUTE    SUBROUTINE(FILLIST)                                     
1017        ENDSELECT                                                          
1018        ENDIF                                                              
1019        ENDROUTINE

Wat betekent mijn avatar?

dinsdag 17 januari 2006 17:15

Acties:

Verwijderd

Verwijderd schreef op dinsdag 17 januari 2006 @ 16:10:
Dan lijken tabs me de juiste keuze, aangezien spaties altijd in de vorm zijn waarin de originele schrijver het zet. Een volgende 'gebruiker' is dan verplicht in zijn stijl te lezen, terwijl je in editorinstellingen de tabindentgrootte kunt aanpassen.

Tabs komen inderdaad dichter in de buurt maar zijn nog steeds onnodige informatie in broncode. Feitelijk zijn zowel spaties als tabs nutteloos (in hun vorm van betekenis). Het enige wat je eventueel wilt is een "seperation marker".
Of je editor daaar visueel een enter/tab/spatie/etc van maakt doet er dan niet toe.

dinsdag 17 januari 2006 20:49

Acties:

dinsdag 17 januari 2006 21:41

Dido schreef op dinsdag 17 januari 2006 @ 17:02:
[...]

Nou, dank je wel hoor

Wees blij dat jullie kunnen indenten!

code:

1011        SUBROUTINE NAME(TEXTLINES)                                         
1012        FETCH      FIELDS(#XGDFID) FROM_FILE(XGDF01) WITH_KEY(ERTS *BLANKS 
                        *BLANKS #OIENUM #BDTNUM #BDPNUM STD)                   
1013        IF_STATUS  IS(*OKAY)                                               
1014        SELECT     FIELDS(#SWDRT50) FROM_FILE(XGDF) WITH_KEY(#XGDFID)       
1015        CHANGE     FIELD(#SWDRT50A) TO(#SWDRT50)                             
1016        EXECUTE    SUBROUTINE(FILLIST)                                     
1017        ENDSELECT                                                          
1018        ENDIF                                                              
1019        ENDROUTINE

RPG? Dat kan ook in een groter terminal scherm, maar idd die ascii ibm handel *shiver*.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

CubicQ

Verwijderd schreef op dinsdag 17 januari 2006 @ 17:15:
[...]
Tabs komen inderdaad dichter in de buurt maar zijn nog steeds onnodige informatie in broncode. Feitelijk zijn zowel spaties als tabs nutteloos (in hun vorm van betekenis). Het enige wat je eventueel wilt is een "seperation marker".
Of je editor daaar visueel een enter/tab/spatie/etc van maakt doet er dan niet toe.

Aan de ene kant ben ik het wel met je eens (en is het technisch ook niet eens zo moeilijk te implementeren: code beautifier voor en achter je version control system hangen), maar aan de andere kant: wanneer je de opmaak door mensen laat doen dan kan je juist door tegen de richtlijnen in te gaan extra informatie geven, en dat kan best handig zijn.

Om op de oorspronkelijke vraag terug te komen: spaties of tabs. 't zal me echt een worst zijn, ik doe gewoon wat de rest in het project/team/bedrijf ook doet. Ik heb meestal eigenlijk wel belangrijkere zaken te doen dan gaan zeuren over het gebruik van een spatie/tab

't enige wat ik wel irritant vind is wanneer mensen 1 regel code aanpassen en dan via de IDE de code formatten en die file weer inchecken waardoor wanneer je difft een paar honderd regels aangepast zijn en je die 1e aangepaste regel niet meer ziet. Of code aanpassen, of opmaak aanpassen, maar beide tegelijk levert verveldende dingen op.

woensdag 18 januari 2006 10:47

Acties:

alienfruit

the alien you never expected

Wat maakt tabs of spaties nou uit, zolang het maar gemakkelijk op een A4tje past. Als je het wilt uitprinten zonder vage word wraps enzo.

woensdag 18 januari 2006 10:48

Acties:

woensdag 18 januari 2006 10:50

achter de duinen

alienfruit schreef op woensdag 18 januari 2006 @ 10:47:
Wat maakt tabs of spaties nou uit,

Er zijn al redenen aangedragen in deze draad?

zolang het maar gemakkelijk op een A4tje past. Als je het wilt uitprinten zonder vage word wraps enzo.

Dat doe jij dagelijks? Nu heb ik gister toevallig ook wat code moeten afdrukken, maar dat kan ook in Landscape, past het ook op een A4tje

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.

Acties:

Verwijderd

CubicQ schreef op dinsdag 17 januari 2006 @ 21:41:'t enige wat ik wel irritant vind is wanneer mensen 1 regel code aanpassen en dan via de IDE de code formatten en die file weer inchecken waardoor wanneer je difft een paar honderd regels aangepast zijn en je die 1e aangepaste regel niet meer ziet. Of code aanpassen, of opmaak aanpassen, maar beide tegelijk levert verveldende dingen op.

Dit is dus precies een van de redenen waarom ik opper voor een bron bestand zonder opmaak. Opmaak hoort nou eenmaal niet in een bron bestand, dat is iets voor het individu. Een compiler zal er niet meer of minder prettig om worden.

woensdag 18 januari 2006 11:13

Acties:

Confusion

Fallen from grace

Erkens schreef op maandag 16 januari 2006 @ 20:27:
dus meer dan 3 levels is fout en mag dus eigenlijk niet voorkomen

Zo min mogelijk en dit is wel een manier om het te ontmoedigen

.

Verder vind ik een sterke voorkeur voor tabs of spaties erg raar. Als je me code geeft die 2, 3, 4 of 8 spaties ingedeukt is, dan vind ik het allemaal prima. Als ik code met tabs moet bewerken, pas ik de tabinstelling aan naar mijn voorkeur en zet ik tabs. Als ik code met spaties moet bewerken, dan pas ik de tabinstelling aan om het gewenste aantal spaties te zetten. Als de code permanent omgezet mag worden is dat ook zo gepiept. In ieder geval gebruik ik zelf de tab toets om meerdere spaties tegelijk te zetten: in de files staan spatie karakters. Als mensen niet consistent zijn met de indeuking, dan is dat voor of na conversie zo en dat een probleem dat losstaat van voorkeuren.

Wie trösten wir uns, die Mörder aller Mörder?

woensdag 18 januari 2006 11:26

Acties:

woensdag 18 januari 2006 11:30

Verwijderd schreef op woensdag 18 januari 2006 @ 10:50:
[...]
Dit is dus precies een van de redenen waarom ik opper voor een bron bestand zonder opmaak. Opmaak hoort nou eenmaal niet in een bron bestand, dat is iets voor het individu. Een compiler zal er niet meer of minder prettig om worden.

http://www.cs.uu.nl/research/projects/proxima/

putStr $ map (x -> chr $ round $ 21/2 * x^3 - 92 * x^2 + 503/2 * x - 105) [1..4]

Acties:

bigbeng

Verwijderd schreef op woensdag 18 januari 2006 @ 10:50:
[...]
Dit is dus precies een van de redenen waarom ik opper voor een bron bestand zonder opmaak. Opmaak hoort nou eenmaal niet in een bron bestand, dat is iets voor het individu. Een compiler zal er niet meer of minder prettig om worden.

Leuk idee... dus alle IDE's moeten vanaf nu het bronbestand zonder opmaak opslaan? Want anders los je het probleem dat jij quote dus niet op. Plus als je dus met cvs een update doet en je moet vervolgens gaan kijken of de wijzigingen relevant zijn, dan moet je dus vervolgens ongeformatteerde code met elkaar gaan vergelijken. Da's lekker handig.

Een gestandaard stijlgids binnen je bedrijf hanteren lijkt mij een meer valide optie. 1x kiezen voor tabs of spaties (en hoeveel) en vanaf dan je eraan houden. De meeste mij bekende IDE's kun je daarop inrichten.

Oh ja, om even mee te ranten

:
Ik ben voor spaties. 4 om precies te zijn. En de hele wereld moet zich daaraan houden, anders moet ik continu die broncode aan zitten passen. En ik doe het hoor, dat is een belofte, geen dreigement.

Maar zonder dollen, ik ben echt voor spaties, omdat die zoals eerder genoemd zich altijd op dezelfde wijze gedragen.

woensdag 18 januari 2006 11:33

Acties:

Verwijderd

bigbeng schreef op woensdag 18 januari 2006 @ 11:30:
Leuk idee... dus alle IDE's moeten vanaf nu het bronbestand zonder opmaak opslaan? Want anders los je het probleem dat jij quote dus niet op. Plus als je dus met cvs een update doet en je moet vervolgens gaan kijken of de wijzigingen relevant zijn, dan moet je dus vervolgens ongeformatteerde code met elkaar gaan vergelijken. Da's lekker handig.

Jij laat het klinken alsof dat lastig is terwijl het een vrij simpel concept is. Het maakt het voor een merge-tool enkel eenvoudiger. Het filteren van "ignorable whitespace" is ook een fluitje van een cent.

woensdag 18 januari 2006 11:34

Acties:

bigbeng

Heb je wel eens met CVS gewerkt?

woensdag 18 januari 2006 11:38

Acties:

Verwijderd

bigbeng schreef op woensdag 18 januari 2006 @ 11:34:
Heb je wel eens met CVS gewerkt?

Dag en dagelijks.
Maar het fileteren etc vind ik niet het werk voor een cvs. Dat behoort toe aan de tool die het bestand bewerkt.

[ Voor 26% gewijzigd door Verwijderd op 18-01-2006 11:40 ]

woensdag 18 januari 2006 11:48

Acties:

woensdag 18 januari 2006 11:55

Moderator Devschuur®

Demotivational Speaker

bigbeng schreef op woensdag 18 januari 2006 @ 11:34:
Heb je wel eens met CVS gewerkt?

Noem het sourcecontrol, er bestaan zoveel meer (en betere!) pakketten dan CVS.

Maar de meeste sourcecontrol systemen werken op basis van tekst, wat onzin is omdat het gaat om de code. Als jij dus ergens een extra enter toevoegt dan is dat voor de compiler geen change, voor je sourcecontrol systeem wel. Het zou dus handiger zijn als de parsetree wordt gediff'd ipv de tekstfile. En dat je de file moet kunnen browsen tijdens het mergen (oid) is natuurlijk triviaal. Je krijgt nu de exacte tekst te zien omdat het vergelijken gewoon op basis van tekst gaat, dat wil natuurlijk niet zeggen dat je tekst blijft zien op het moment dat je sourcecontrol systeem de code echt parset om de changes te vinden.

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

bigbeng

.oisyn schreef op woensdag 18 januari 2006 @ 11:48:
[...]

Noem het sourcecontrol, er bestaan zoveel meer (en betere!) pakketten dan CVS.

Maar de meeste sourcecontrol systemen werken op basis van tekst, wat onzin is omdat het gaat om de code. Als jij dus ergens een extra enter toevoegt dan is dat voor de compiler geen change, voor je sourcecontrol systeem wel. Het zou dus handiger zijn als de parsetree wordt gediff'd ipv de tekstfile. En dat je de file moet kunnen browsen tijdens het mergen (oid) is natuurlijk triviaal. Je krijgt nu de exacte tekst te zien omdat het vergelijken gewoon op basis van tekst gaat, dat wil natuurlijk niet zeggen dat je tekst blijft zien op het moment dat je sourcecontrol systeem de code echt parset om de changes te vinden.

Goed punt, laten we het sourcecontrol noemen dan. Je zult dan dus of IDE of taalspecifieke sourcecontrol pakketten krijgen, of sourcecontrol moet taalspecifieke "treeparse" methodieken gaan hanteren. En hoewel dat zeker wel mogelijk is, vraag ik me af of het in algemene zin een haalbaar iets is. Ik kan me dus zeker wel vinden in dat theoretisch de opmaak van de sourcefile los zou kunnen en moeten staan van de source zelf.

woensdag 18 januari 2006 12:02

Acties:

woensdag 18 januari 2006 12:04

.oisyn schreef op woensdag 18 januari 2006 @ 11:48:
[...]
Noem het sourcecontrol, er bestaan zoveel meer (en betere!) pakketten dan CVS.

Maar de meeste sourcecontrol systemen werken op basis van tekst, wat onzin is omdat het gaat om de code. Als jij dus ergens een extra enter toevoegt dan is dat voor de compiler geen change, voor je sourcecontrol systeem wel. Het zou dus handiger zijn als de parsetree wordt gediff'd ipv de tekstfile. En dat je de file moet kunnen browsen tijdens het mergen (oid) is natuurlijk triviaal. Je krijgt nu de exacte tekst te zien omdat het vergelijken gewoon op basis van tekst gaat, dat wil natuurlijk niet zeggen dat je tekst blijft zien op het moment dat je sourcecontrol systeem de code echt parset om de changes te vinden.

Mee eens. verder zou ik het concept 'file' dan ook willen droppen, in OO talen, omdat je met classes bezig bent en code blocks en niet met files. Dus versioning op een class source is IMHO het ultieme, ipv geprut met files en texts

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

woensdag 18 januari 2006 12:16

Moderator Devschuur®

Demotivational Speaker

@bigbeng:

http://www.alienbrain.com/
Ze noemen het een asset manager, maar die doet dus ook aan source control, en is in staat om bijvoorbeeld max-files te diffen (een binaire diff is nogal zinloos). Ik geloof niet dat ze broncode parsen, maar dat systeem is dus al heel erg toegespitst op speciale files. Het is niet ondenkbaar dat er ook een codeparser in gehangen kan worden.

[ Voor 3% gewijzigd door .oisyn op 18-01-2006 12:25 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

Zoijar

Because he doesn't row...

EfBe schreef op woensdag 18 januari 2006 @ 12:02:
Mee eens. verder zou ik het concept 'file' dan ook willen droppen, in OO talen, omdat je met classes bezig bent en code blocks en niet met files. Dus versioning op een class source is IMHO het ultieme, ipv geprut met files en texts

Beetje smalltalk achtig, waar je code gewoon een grote XML file is die je inlaad in het smallalk runtime systeem.

(ie. dat ziet er dus zo uit:)

code:

<class>
<name>ArrivingState</name>
<environment>Smalltalk</environment>
<super>CustomerState</super>
<private>false</private>
<indexed-type>none</indexed-type>
<inst-vars></inst-vars>
<class-inst-vars></class-inst-vars>
<imports></imports>
<category>SupermarketSimulation</category>
</class>

<comment>
<class-id>ArrivingState</class-id>
<body>The state when a customer arrives
</body>
</comment>

<methods>
<class-id>ArrivingState</class-id> <category>events</category>

<body>tick
    "Count down delay, then progress to shopping state"

    "If the shop is too busy at any time during arrival, the customer leaves"
    "(Statistics singleton customersWaiting &gt; 5)"
    (CheckoutManager singleton shortest lineLength &gt; 4)
    ifTrue: [
        "Progress to finished state"
        FinishedState new of: theCustomer time: 0.
        Statistics singleton incTotalNotServed.
    ]
    ifFalse: [
        delay := delay - 1.
        delay &lt;= 0 ifTrue: [
            "Progress to shopping state, and determine how long we will shop randomly"      
            ShoppingState new of: theCustomer time: ((Statistics singleton random * 7 + 1) rounded).
        ].
    ].</body>
</methods>

<methods>
<class-id>ArrivingState</class-id> <category>display</category>

<body>printOn: aStream
    "Print the state on the stream"
    aStream nextPutAll: 'arriving'.
    aStream cr.</body>
</methods>
<new-page/>

[ Voor 62% gewijzigd door Zoijar op 18-01-2006 12:22 ]

woensdag 18 januari 2006 13:19

Acties:

Confusion

Fallen from grace

Verwijderd schreef op woensdag 18 januari 2006 @ 10:50:
Dit is dus precies een van de redenen waarom ik opper voor een bron bestand zonder opmaak. Opmaak hoort nou eenmaal niet in een bron bestand, dat is iets voor het individu. Een compiler zal er niet meer of minder prettig om worden.

Volgens mij is het verre van triviaal om IDE's zover te krijgen om code vanuit een ongeformatteerd bronbestand goed in te deuken. Het aantal 'bijzondere' situaties is nogal groot; situaties waarin goede oplossingen te menselijk zijn.

As an aside: misschien zou de compiler er meer of minder prettig om moeten worden: enter Python

.

Wie trösten wir uns, die Mörder aller Mörder?

zaterdag 29 juli 2006 13:13

Acties:

Verwijderd

Wanneer je voor indentation tabs gebruikt, voor alignment spaties en bij wrapping/formatting uitgaat van een tab van 8 kolommen ziet je code er onder alle omstandigheden goed uit en kan elke gebruiker zijn of haar tabstop zetten om elke gewenste waarde.

zaterdag 29 juli 2006 13:20

Acties:

NMe

Quia Ego Sic Dico.

Een tab van 8 kolommen in code?

Dan zit je wel heel snel buiten het scherm te werken hoor.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

zaterdag 29 juli 2006 13:26

Acties:

Verwijderd

-NMe- schreef op zaterdag 29 juli 2006 @ 13:20:
Een tab van 8 kolommen in code? Dan zit je wel heel snel buiten het scherm te werken hoor.

Niet wanneer je jouw editor zo instelt dat tabs als vier worden weergegeven, maar je voor lijnwrapping een tab van acht gebruikt. Iemand die een tab van acht gebruikt zal dan namelijk geen last hebben van afbrekende lijnen omdat jij als maker een kleinere tabstop gebruikte. Iets wat in de praktijk veel voorkomt.

zaterdag 29 juli 2006 14:26

Acties:

Verwijderd

Ik weet dat ik reageer op een bericht van dik een half jaar oud, maar...

EfBe schreef op dinsdag 17 januari 2006 @ 09:57:
Zelf gebruik ik op 1600x1200 lucida console 9pt (in vs.net 2005, in 2003 werkt de editor alleen met courier bugfree in C#)

Courier is een draak (op m'n scherm wil ik geen schreef wanneer ik programmeer), Lucida Console is al een stuk prettiger, maar ik gebruik al jaren Raize Font van Ray Konopka. Ray heeft dat font ooit ontworpen omdat Courier 't niet goed doet op presentaties met een beamer. En presentaties zijn z'n grootste bron van inkomsten: hij is en was een guru op Delphi gebied, en begint dat nu ook te worden op .NET/C# gebied (hij heeft een tijdje bij Falafel van Lino Tadros gewerkt als co-CEO, maar dat is nu blijkbaar weer over).

Anyway, Raize Font gebruik ik in al m'n ontwikkelomgevingen (Delphi 2, 5, 6, 8, 2006, VS 2003, 2005, UltraEdit voor de overige dingen), en ik ben nog geen prettiger font tegengekomen om in te programmeren.

zaterdag 29 juli 2006 19:24

Acties:

The - DDD

Een argument mis in nog in deze hele discussie.

Byte size van bestanden.

Het kan per 100 regels al snel 400 bytes schelen als je tabs ipv. spaties gebruikt. Nu denk je misschien, wat maken mij die 400 bytes uit? Inderdaad, voor een file waar een compiler overheen gaat niet. Maar iets wat vanaf een webserver geserveerd wordt en in de output komt??

Stel je hebt een file van 1024 regels op zich niet zo gek per file bestand. Dat is een nodeloze overhead van 4096 bytes. 4 KiB per bestand dus. Neem redelijk vaak bezochte site met 131.072 hits per dag op die ene file. Dat is 512 MiB per dag. Oftewel 182,5 GiB per jaar op die ene file.

Ik wil niet veel zegen, maar ik vind dat een goede reden om wel stil te staan bij de gevolgen van overmatig spatie gebruik. Uiteraard kun je een tooltje draaien om overbodige whitespace te strippen voordat je in productie gaat. Kijk maar is naar de bron van Tweakers.net of van deze pagina.

Moet je ook is nagaan hoeveel data verkeer op internet nodeloze whitespace is.

zaterdag 29 juli 2006 19:34

Acties:

NMe

Quia Ego Sic Dico.

The - DDD: dat heeft te maken met de layout van HTML; de serverside code layout en het aantal spaties/tabs daarin is totaal onbelangrijk omdat dat toch niet verstuurd wordt. HTML kun je tijdens het devven altijd netjes uitlijnen, en voor het uploaden desnoods middels een macro de uitlijning weghalen. Devven zonder uitlijning is in elk geval goed onmogelijk.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

zaterdag 29 juli 2006 19:38

Acties: