[alg] waarom i als in i++

[SWINX]

Ik en een kennis van me vroegen ons af waarom er i wordt gebruikt voor i++ en waarom niet bijvoorbeeld a++

Is hier een standaard rede voor?

[Super_ik]

is uit de tijd dat variabelen nog maar 1 letter hadden, de i van integer, meestal in loopjes, in de search (k zou nie wete waarop te zoeken) staat er ook vannalles over

[lordsnow]

i van index, waarschijnlijk, of van increase?

[TrailBlazer]

weet eigenlijk niet denk dat veel het hebben aangeleerd ik gebruik zelf vaak van alles en nog wat vanaf de i inderdaad voor dit soort dingen

[XTerm]

Is vooral een gewoontekestie.
In een for(){} ga ik *altijd* een variable genaamd c gebruiken.
Puur een gewoonte zonder betekenis

[MisterData]

Ik gebruik altijd een andere letter Meestal a eigenlijk....

[zeroxcool]

Ik dacht ook dat het van integer kwam...

[Alarmnummer]

moet je even zoeken naar : hungarian style.

[qless]

tsja het is traditie immidels en staat ook in alle voorbeelden en programmeer handleidingen.

[Tuinhark]

Ik gebruik de i ook al sinds ik met QBasic bezig was (8 jaar terug ofzo).
Net zoals foo en bar in "alle" programmeer voorbeeldjes.

[Soultaker]

Ik gebruik al zolang ik me kan herinneren 'n' (van numeral ofzo, verzin wat leuks) omdat ik vroeger ooit eens in Pascal begonnen ben en ik daar een boek van had, dat met 'n' in lusjes werkte. Tegenwoordig ben ik daar erg blij mee, want nu kan ik 'i' voor iterators gebruiken.

Verder maakt het natuurlijk geen reet uit.

_{Volgens mij is 't ook een Pascal trekje dat ik by default ++i schrijf in plaats van i++, in verband met de inc() functie in Pascal.}

[Nielsz]

Soultaker schreef op 01 november 2002 @ 16:28:
_{Volgens mij is 't ook een Pascal trekje dat ik by default ++i schrijf in plaats van i++, in verband met de inc() functie in Pascal.}

En dat maakt natuurlijk ook geen reet uit

[thomaske]

Nielsz schreef op 01 november 2002 @ 16:33:
[...]

En dat maakt natuurlijk ook geen reet uit

ligt eraan in welke context:

j = i++

is volgens mij anders dan:

j = ++i

[Verwijderd]

Volgens mij is het de i van iterator. Vroeger in GW-Basic gebruikte ik n, dan ging NEXT n iets gemakkelijker

[Orphix]

Nielsz schreef op 01 november 2002 @ 16:33:
En dat maakt natuurlijk ook geen reet uit

nouja het maakt (in ++C dan) wel een klein beetje uit (i++ geeft i terug voor de optelling, ++i erna).

Verder gebruik ik zelf ook altijd i, maar ik moet altijd aan 'i'terator denken. Nu ik erover nadenk is de meest logische dat het van index komt. Integer of ivm hungarian style lijkt me onwaarschijnlijk.

offtopic:
lekker vrijdag topic weer

[Verwijderd]

Als je met complexe getallen werkt is het gebruik van i/j niet super handig, als in verwarrend

[markvt]

lordsnow schreef op 01 november 2002 @ 16:20:
i van index, waarschijnlijk, of van increase?

denk aan increment

[David]

ZeRoXcOoL schreef op 01 november 2002 @ 16:24:
Ik dacht ook dat het van integer kwam...

Yep, dat geloof ik ook.

[Nielsz]

Stelletje n00bs (orphix & Tomaske) Dat was sarcastisch hoor

[MSalters]

markvt schreef op 01 november 2002 @ 16:41:
[...]
denk aan increment

En in i-- dan?
i Is gewoon de canonieke loopvariabele, dat komt denk ik uit de wiskunde:
bvb x_i(i=1,2,3)

[tomato]

Hmz, het is een beetje lastig hier iets over op te zoeken, maar ik denk toch echt meer aan 'iterator'.

[Verwijderd]

Ik gebruik altijd nLus

n voor numeriek (hongaars) en Lus omdat het een lus betreft..

[Alarmnummer]

Alarmnummer schreef op 01 november 2002 @ 16:25:
moet je even zoeken naar : hungarian style.

[CyeZ]

Het verhaal zoals ik het ken is dat de naam 'i' voor counter variabelen afkomstig is uit een oude programmeertaal waarbij de types van variabelen waren bepaald door de variabele naam. i,j,etc... waren integers alles daarvoor floating points oid. Hierdoor was het dus logisch om i als counter te gebruiken aangezien dit de eerste integer was.
In hoeverre dit verhaal klopt weet ik niet, 'i' is een lastige term om op te googlen.

[curry684]

Ben ik nu de enige die doorheeft dat tegenwoordige compilers niet echt meer beperkt worden door geheugenruimte voor variabelenamen? Kom op, C en C++ identificeren 256 significante karakters voor een identifier... ik ben dan ook een jaar of 5 geleden opgehouden met korte variabelenamen en typ nu gewoon netjes:

C++:

for(int l_Index = 0; l_Index != 10; l_Index++)
  DoSomeFunctionWithALongClearDescription(m_MyHugeArrayOfBollocks[l_Index]);

Gelukkig doen er nog weinig programmeerboeken mee aan de 'how to obfuscate your code' hype met 1-letterige identifiers....

[Nielsz]

En de underscore_in_een_variabele_naam valt niet onder de Bollocks?

[curry684]

Nielsz schreef op 01 november 2002 @ 17:17:
En de underscore_in_een_variabele_naam valt niet onder de Bollocks?

Alleen om scope en naam te scheiden:

code:

l_LocalVariable
m_MemberVariable
p_Parameter
c_Constant
g_Global
t_Type
e_Enumerate

[Verwijderd]

Waarom kort je de l dan wel af? l_Index vind ik niets duidelijker dan i.

[Dido]

Hoe zat dat ook alwaar in Fortran?

Daar waren variabelen die begonnen met i,j,k (dacht ik) impliciet gedefinieerd als [b]i[/i]nteger. Dus was i de eerste en simpelste integer om te gebruiken voor loops.

(Hoewel je ook expliciet kon definieren, en geen hond die dat verwacht. Zo bijna een keer gezakt voor een tentamen: "Ja, maar je gebruikt een variabele die begint met een b als iterator! dat kan niet!" - Welles!)

[Crazy D]

curry684 schreef op 01 november 2002 @ 17:15:

C++:

for(int l_Index = 0; l_Index != 10; l_Index++)
  DoSomeFunctionWithALongClearDescription(m_MyHugeArrayOfBollocks[l_Index]);

Omdat i minder typewerk is dan l_Index?
Iig gebruik ik het alleen voor loops, en alleen als er geen onduidelijkheid bestaat (een i, j en k maken het weer niet zo heel duidelijk en in dat geval zou het bv iIndex worden).

[curry684]

Verwijderd schreef op 01 november 2002 @ 17:19:
Waarom kort je de l dan wel af? l_Index vind ik niets duidelijker dan i.

Omdat de l voor de underscore altijd hetzelfde betekent in deze naming convention met als specificatie dat het een 'Index' is, terwijl de naam 'i' kan staan voor integer, iterator, index, Ierland, iris, inburgering, invalide, Irak en ga zo maar door.

[edit]
Ter verduidelijking een uitdaging:

C++:

int            g_Index;
const int   c_Index = 684;
class Index
{
public:
  int ExchangeIndex(int p_Index)
  {
  int l_Index = m_Index;
  m_Index = p_Index;
  return l_Index;
  }
  
private:
  int        m_Index;
};

En dan nu dit stukje aub. herschrijven zonder scope prefixes... probeer het daarna eens met Hungarian

[ Voor 0% gewijzigd door curry684 op 01-11-2002 17:28 . Reden: uitbreiding ]

[curry684]

Crazy_D schreef op 01 november 2002 @ 17:24:
Omdat i minder typewerk is dan l_Index?

Toon mij een programmeur die serieus in resultaten beperkt wordt door z'n typsnelheid en niet z'n denksnelheid en ik ben onder de indruk

[Verwijderd]

curry684 schreef op 01 november 2002 @ 17:24:
[...]

Omdat de l voor de underscore altijd hetzelfde betekent in deze naming convention met als specificatie dat het een 'Index' is, terwijl de naam 'i' kan staan voor integer, iterator, index, Ierland, iris, inburgering, invalide, Irak en ga zo maar door.

En als ik nu in mijn naming convention definieer dat éénletterige variabelen altijd iterators in for loops zijn? Dan is het mij in ieder geval duidelijk.

[Verwijderd]

index
integer
increment
iterator

Meer dan genoeg redenen om i te gebruiken (ook al word ik op school verplicht iTeller te gebruiken ).

Het verschil tussen prefix en postfix increment/decrement is in C++ (en wellicht ook C) precies één temporary (die overigens wellicht vaak kan worden weggeoptimaliseerd). De postfix increment/decrement kan dan ook vaak simpel m.b.v. de prefix increment/decrement als volgt geimplementeerd worden:

C++:

T T::operator++ (int) // int parameter => postfix
{
  T r (*this);
  operator++();
  return r;
}

[PommeFritz]

Een stelregel die leesbare code bevordert is: hoe kleiner de scope van een variabele, hoe korter de naam. (het omgekeerde is trouwens belangrijker: hoe groter de scope, hoe groter - en dus duidelijker - de naam!)
Omdat loop variabelen meestal een heeel kleine scope hebben (1-10 regels code) is er nix op tegen om ze zo kort mogelijke naam te geven.
Volgens mij komt i trouwens vanaf index of iterator.

[Verwijderd]

curry684 schreef op 01 november 2002 @ 17:15:
Ben ik nu de enige die doorheeft dat tegenwoordige compilers niet echt meer beperkt worden door geheugenruimte voor variabelenamen? Kom op, C en C++ identificeren 256 significante karakters voor een identifier... ik ben dan ook een jaar of 5 geleden opgehouden met korte variabelenamen en typ nu gewoon netjes

Ik denk dat vrijwel niemand namen als i gebruikt omdat die sneller zouden compileren. Ikzelf gebruik i in loopjes simpelweg omdat ik het leesbaarder vindt dan bijvoorbeeld l_Index. Overigens gebruik ik dit soort namen alleen in (private) class implementaties waar het gebruik ervan duidelijk te overzien is, in een class interface gebruik ik langere namen (maar nog steeds zeker geen hongaarse of andere prefix toestanden).

[Alarmnummer]

Prefix bij variablen is echt super handig. Ik gebruik '_' voor member variablen, 's_' voor statische variablen en zonder prefix is het een lokale variable. Eigelijk zou ik ook nog een 'f_' ofzo moeten introduceren voor argumenten van een functie, en dan zijn variablen zonder prefix echt lokale variablen (die niet in de header staan dus).

Je hebt gewoon extra informatie ter beschikking, en je zult veel mindersnel een stomme fout maken:

vb (java)

int i;
void set(int i){
...i=i;
}

dit soort stomme fouten krijg je niet meer zo snel.

[Glimi]

Alarmnummer schreef op 01 november 2002 @ 17:42:
Prefix bij variablen is echt super handig. Ik gebruik '_' voor member variablen,

Die gebruik ik ook, vooral omdat ik eigenlijk te lui ben om vaak this te typen

's_' voor statische variablen en zonder prefix is het een lokale variable.

public static final int s_MY_CONSTANT;
*brrrrr*

(...)
Je hebt gewoon extra informatie ter beschikking, en je zult veel mindersnel een stomme fout maken:

vb (java)

int i;
void set(int i){
...i=i;
}

dit soort stomme fouten krijg je niet meer zo snel.

Die krijgen we allang niet meer als we onze variabelen encapsuleren

Java:

public class Blaat {

   private int _i;

   Blaat( int i ) {
      
      setI( i );
   }

   private void setI( int i ) {
      // check if i is valid
      //
      _i = i;
   }

   public void getI( ){

      returnI;
   }
}

Natuurlijk gebruik ik geen i voor klassevariabele naam normaalgesproken.

[MSalters]

curry684 schreef op 01 november 2002 @ 17:24:
[...]
Ter verduidelijking een uitdaging:

C++:

int            g_Index;
const int   c_Index = 684;
class Index
{
public:
  int ExchangeIndex(int p_Index)
  {
  int l_Index = m_Index;
  m_Index = p_Index;
  return l_Index;
  }
  
private:
  int        m_Index;
};

En dan nu dit stukje aub. herschrijven zonder scope prefixes... probeer het daarna eens met Hungarian

Aangenomen

C++:

int            MostRecentlyUpdatedFooInBar;
const int   LastFooInBar = 684;

class Index
{
public:
  void swap(Index& rhs)
  {
    std::swap( rhs.WrappedIndex, this->WrappedIndex );
  }
private:
  int        WrappedIndex;
};

[hk] Mag ik een poll maken wat we duidelijker vinden? [/hk]

[Alarmnummer]

Glimi schreef op 01 november 2002 @ 19:40:
public static final int s_MY_CONSTANT;
*brrrrr*

Bij constants gebruik ik ze niet, daar schrijf ik de naam gewoon met hoofdletters.

Die krijgen we allang niet meer als we onze variabelen encapsuleren

Het was ook een fragment van een stukje code. Je kan namelijk helemaal geen variablen declaren buiten een class. Dus dan moet dit wel binnen een class zijn

[Annie]

En ik maar denken dat i van idiootKorteNaamVoorEenLoopVariabele komt

[Verwijderd]

Volgens mij is het gebruik nog van voordat er ueberhaupt computers bestonden... laat staan programmeertalen. Het wordt namelijk standaard in de wiskunde gebruikt voor vectoren x_i bijvoorbeeld (i als subscript van de vector x).

[Soultaker]

Verwijderd schreef op 01 november 2002 @ 20:04:
Volgens mij is het gebruik nog van voordat er ueberhaupt computers bestonden... laat staan programmeertalen. Het wordt namelijk standaard in de wiskunde gebruikt voor vectoren x_i bijvoorbeeld (i als subscript van de vector x).

Daar zeg je zo wat! Maar daar wordt net zo vaak (bijvoorbeeld) k of n gebruikt, in combinatie met sommatie- en produkttekens, bijvoorbeeld.

[Glimi]

Alarmnummer schreef op 01 november 2002 @ 19:59:
Het was ook een fragment van een stukje code. Je kan namelijk helemaal geen variablen declaren buiten een class. Dus dan moet dit wel binnen een class zijn

Maar je maakt geen gebruik van get/setters. Dat bedoelde ik ook met het encapsuleren van variabelen.
Dus ook binnen de classe i benaderen met getI() en setI(). Dan wordt uw code dus:

Java:

int i;
void set(int i){
   setI(i);
}

[tomato]

Glimi schreef op 01 november 2002 @ 19:40:
Die krijgen we allang niet meer als we onze variabelen encapsuleren

Java:

public class Blaat {

   private int _i;

   Blaat( int i ) {
      
      setI( i );
   }

   private void setI( int i ) {
      // check if i is valid
      //
      _i = i;
   }

   public void getI( ){

      returnI;
   }
}

Euh.... dan heb je toch nog precies hetzelfde issue in de method setI()

[windancer]

Klopt, in Fortran waren variablen die begonnen met i t/m n standaard van type int terwijl de anderen standaard real waren. Vandaar het grapje "God is real unless specifically declared otherwise".

CyeZ schreef op 01 november 2002 @ 16:59:
Het verhaal zoals ik het ken is dat de naam 'i' voor counter variabelen afkomstig is uit een oude programmeertaal waarbij de types van variabelen waren bepaald door de variabele naam. i,j,etc... waren integers alles daarvoor floating points oid. Hierdoor was het dus logisch om i als counter te gebruiken aangezien dit de eerste integer was.
In hoeverre dit verhaal klopt weet ik niet, 'i' is een lastige term om op te googlen.

[Sjaaky]

Waar komen foo en bar eigenlijk vandaan?

[Glimi]

tomato schreef op 01 november 2002 @ 22:16:
Euh.... dan heb je toch nog precies hetzelfde issue in de method setI()

* Glimi kijkt nog eens goed
Je hebt inderdaad gelijk!

[tomato]

Sjaaky schreef op 01 november 2002 @ 23:32:
Waar komen foo en bar eigenlijk vandaan?

Daar kun je dan weer wel gemakkelijk op zoeken...

[Glimi]

Sjaaky schreef op 01 november 2002 @ 23:32:
Waar komen foo en bar eigenlijk vandaan?

Foobar stond voor "Fucked Up Beyond All Recognition". Ik dacht dat te maken had met Vietnam, waarbij iedereen die niet meer te herkennen was na een granaat inslag fubar genoemd werdt, zo'n beetje de john doe van tegenwoordig

[TheOneLLama]

Zoals ik het geleerd heb komt i van iterator, maar ik heb het gevoel dat het gewoon op meerdere plaatsen.

Iemand een idee waarom in BASIC altijd k gebruikt werd? Wat ik nog steeds wel eens doe moet ik bekennen.. ik heb er wel eens iets over gelezen maar kan het me niet meer echt herinneren

Sjaaky schreef op 01 november 2002 @ 23:32:
Waar komen foo en bar eigenlijk vandaan?

http://www.tuxedo.org/~esr/jargon/html/entry/foo.html

[80000]

Door John_Smith - Friday 01 November 2002 20:04

Volgens mij is het gebruik nog van voordat er ueberhaupt computers bestonden... laat staan programmeertalen. Het wordt namelijk standaard in de wiskunde gebruikt voor vectoren x_i bijvoorbeeld (i als subscript van de vector x).

Mee eens, v(i) als index i van vector v of x_i als index i van x of
v(x_i) als, nou ja ga maar na.

Door Soultaker - Friday 01 November 2002 20:11

Daar zeg je zo wat! Maar daar wordt net zo vaak (bijvoorbeeld) k of n gebruikt, in combinatie met sommatie- en produkttekens, bijvoorbeeld.

Meestal wordt in de wiskunde n genomen als het totaal voor index i. m voor het totaal van de tweede sommatie met index j en p voor het totaal van de derde sommatie met index k. Dus:

code:

for(i=0;i<=n;i++) 
{ 
    for(j=0;j<=m;j++) 
    {
         for(k=0;k<=p;k++) 
         {
         }
    }
}

Aangezien je veel algoritmen kort en bondig in wiskundige notatie kan opschrijven, is voor de implementatie van het algoritme in een programmeertaal dit waarschijnlijk letterlijk overgenomen.

[Verwijderd]

Toch denk ik dat het vrij archaisch is om nog zo te werken, afgezien van het feit dat het fouten in de hand werkt..

voorbeeld, 3 arrays, apparaat, onderdeel en subonderdeel. Die wil je itereren.. met i,j,k krijg je dan bv:

code:

oApparaat[i].oOnderdeel[j].oSubonderdeel[k]

(nu is dit nog vrij leesbaar, maar de onleesbare voordelen zijn er talloze, maak er bv. eens een uitgerekte lus van waarbij per object nog acties uitgehaald worden)

Dan is:

code:

oApparaat[nApparaatLus].oOnderdeel[nOnderdeelLus].oSubOnderdeel[nSubOnderdeelLus]

al een stuk leesbaarder en minder foutgevoelig.

Beide leveren overigens na compilatie dezelfde code op, dus daarvoor hoef je het niet te doen. Daarnaast kan iemand die midden in zo'n routine begint met lezen gelijk bevatten wat er gebeurd.

[Alarmnummer]

noem hem dan in ieder geval nog index, ipv lus. Ik vind dat namelijk net zo`n slappe benaming als 'loper'.

[Verwijderd]

Alsof dat wat uitmaakt.. wat is er mis met lus? Het is toch een for-next LUS?

Het gaat er om dat de lezer eenvoudig inzicht krijgt in wat er gebeurd.. en dat is met termen als 'lus' of 'loper' wel zo en met gewauwel als 'i,j,k' niet zo.

//edit
sterker nog, index is gewoon domweg fout. De term 'lus' geeft aan dat het een waarde is afkomstig uit een for-next lus, oftewel dat je aan het itereren bent. Zeg je 'index' dan suggereer je dat je een waarde gevonden hebt en alleen die waarde wilt gebruiken.. als ik alleen de regel:

code:

oOnderdeel[nOnderdeelLus]

zie staan dan weet ik gelijk dat het hier om een loop gaat, geen twijfel over mogelijk. Zie ik daarentegen:

code:

oOnderdeel[nOnderdeelIndex]

staan dan weet ik dat niet.

Ik kan dit het best uitleggen met een TStringlist van Delphi:

gebruik lus:

code:

for nLus:=0 to oMijnStringlist.count-1 do
  oMijnStringlist[nLus].Add(<iets>);

gebruik index:

code:

nIndex:=oMijnStringList.IndexOff(<iets>);
ShowMessage(oMijnStringlist[nIndex]);

Index suggereert 1 waarde, niet een veranderende waarde.

[Soultaker]

Verwijderd schreef op 02 november 2002 @ 14:36:
Beide leveren overigens na compilatie dezelfde code op, dus daarvoor hoef je het niet te doen. Daarnaast kan iemand die midden in zo'n routine begint met lezen gelijk bevatten wat er gebeurd.

Yeah right! Ik ga me daar zeker identifiers als nSubOnderdeelLus gebruiken! Dan zit ik twee keer zo lang te tikken en naar mijn bescheiden mening is korte, bondige code aanzienlijk duidelijk dan paginalange code, met duidelijk identifiers maar zonder overzichtelijke structuur.

Het is ook niet voor niets dat in de wiskunde vrijwel uitsluitend enkele letters als identifiers worden gebruikt. De uitleg van hoe het werkt staat los van de formele definitie beschreven.

Ik ben het met je eens dat als je een schermenlang algoritme schrijft, je dat beter niet met a,b,c, i,j,k, x,y,z, kan doen, maar de vraag is of je dan niet beter wat commentaar kan toevoegen of je algoritme opsplitsen in verschillende functies. Als ik echter de verschillende waarden uit een array wil printen gebruik ik gewoon "i"; er is niemand die dat verkeerd kan interpreteren.

[Verwijderd]

Yeah right! Ik ga me daar zeker identifiers als nSubOnderdeelLus gebruiken! Dan zit ik twee keer zo lang te tikken

Ik heb het dan ook iets overtrokken om duidelijk te maken wat ik bedoel.
Toch ben ik het ook op dat punt niet helemaal met je eens. In feite zeg je hier gewoon 'ik ben te lui om het goed te doen'. Als je zo gaat redeneren kun je zaken als functioneel ontwerp, technisch ontwerp e.d. ook de deur uit doen; is alleen een hoop typewerk wat voor de code zelf geen functie heeft... (wederom, iets overtrokken, nofi)

Dan zit ik twee keer zo lang te tikken en naar mijn bescheiden mening is korte, bondige code aanzienlijk duidelijk dan paginalange code, met duidelijk identifiers maar zonder overzichtelijke structuur.

Hier koppel je twee zaken aan elkaar om tot een punt te komen, volgens mij is die koppeling niet goed. In mijn ogen is korte, bondige code MET duidelijke identifiers gewoon het beste...

Het is ook niet voor niets dat in de wiskunde vrijwel uitsluitend enkele letters als identifiers worden gebruikt.

Wiskunde != programmeren. Er zitten wel overeenkomsten tussen, echter de verschillen geven je in dit opzicht ongelijk. In de wiskunde gaat het vaak om handgeschreven werk, waarbij de oplossingsroute besloten ligt in de te gebruiken formules. Daarnaast is het niet zo (of iig. veel minder) dat de 'formules' in kwestie onderhouden moeten worden en bijgewerkt als er functionaliteit veranderd. Wiskunde is veel statischer. Wiskundige formules worden opgesteld teneinde een soort van 'absolute, logische waarheid' te definieren. Daarnaast is het bij de wiskunde zo dat er veel meer mensen zijn die een bep. formule gewoon gebruiken, en dat het aantal mensen dat die formule zou gaan wijzigen een stuk kleiner is.

Bij code is dat heel anders. Code wordt gebruikt om een dynamisch proces te beschrijven. Code wordt aangepast aan een proces niet om een 'absolute waarheid' te definieren, maar om het betreffende proces te omvatten. Bij code is het ook zo dat de verhouding 'toepassenden' en 'muterenden' voor een regel code heel anders ligt; het zijn geen wetten oid. Bij code is het veel meer van belang dat men het onderliggende proces eenvoudig kan doorzien door het lezen van de code, ivm. onderhoudbaarheid.

Ik ben het met je eens dat als je een schermenlang algoritme schrijft, je dat beter niet met a,b,c, i,j,k, x,y,z, kan doen, maar de vraag is of je dan niet beter wat commentaar kan toevoegen of je algoritme opsplitsen in verschillende functies.

Hier gebeurd hetzelfde als bij je eerste argument. Of schermenlange algoritmes goed zijn of niet, is een heel andere discussie (waarin ik het overigens met je eens bent.. ellenlange algoritmes zijn zelden goed en behoren uitgesplitst te worden imho).

Als ik echter de verschillende waarden uit een array wil printen gebruik ik gewoon "i"; er is niemand die dat verkeerd kan interpreteren.

Ook dit ben ik met je eens. Het ging me dan ook niet over een eenvoudige for-next lus, maar juist zodra je gaat werken met situaties met geneste lussen e.d. is het m.i. beter wat extra typewerk te doen om een beter beschrijvende iterator te gebruiken. In het (overtrokken) voorbeeld van mij zou ik bv. nALus, nOLus en nSOLus kunnen gebruiken.

[johnwoo]

Glimi schreef op 02 november 2002 @ 00:00:
[...]

Foobar stond voor "Fucked Up Beyond All Recognition". Ik dacht dat te maken had met Vietnam, waarbij iedereen die niet meer te herkennen was na een granaat inslag fubar genoemd werdt, zo'n beetje de john doe van tegenwoordig

offtopic:
Fubar stamt uit WOII, niet Vietnam. En volgens mij hoeft het ook niet per se over een persoon te gaan; de situatie waarin je als soldaat verkeerde kon ook fubar zijn...

Persoonlijk gebruik ik meestal r voor indexen in een loop; komt omdat ik begonnen ben met Basic, en daar was r nu eenmaal gebruikelijk Maar tegenwoordig gebruik ik ook steeds vaker index.

[MSalters]

Soultaker schreef op 02 november 2002 @ 15:54:
[...]


Yeah right! Ik ga me daar zeker identifiers als nSubOnderdeelLus gebruiken! Dan zit ik twee keer zo lang te tikken en naar mijn bescheiden mening is korte, bondige code aanzienlijk duidelijk dan paginalange code, met duidelijk identifiers maar zonder overzichtelijke structuur.

Ik ben het met je eens dat als je een schermenlang algoritme schrijft, je dat beter niet met a,b,c, i,j,k, x,y,z, kan doen, maar de vraag is of je dan niet beter wat commentaar kan toevoegen of je algoritme opsplitsen in verschillende functies. Als ik echter de verschillende waarden uit een array wil printen gebruik ik gewoon "i"; er is niemand die dat verkeerd kan interpreteren.

Sterker nog, ik gebruik i met opzet om aan te geven dat het een lokale index is, met geen bijzondere semantische betekenis (anders dan de loop index). Variabelen die gerbuikt worden in een scope die het scherm overstijgt krijgen wel langere namen; dan zie je aan de grootte van de naam dus de grootte van de scope.

En aangezien mijn functies de neiging hebben om op een scherm te passen zijn de meeste loopindices van mij i ( of j, als'k weer met MSVC6 loop te klooien. ).
Hoeveel twijgfel is er over de scope van i in for (int i ... ) ... ?

[curry684]

Soultaker schreef op 02 november 2002 @ 15:54:
Yeah right! Ik ga me daar zeker identifiers als nSubOnderdeelLus gebruiken! Dan zit ik twee keer zo lang te tikken en naar mijn bescheiden mening is korte, bondige code aanzienlijk duidelijk dan paginalange code, met duidelijk identifiers maar zonder overzichtelijke structuur.

Ik citeer mezelf: Toon mij een programmeur die serieus in resultaten beperkt wordt door z'n typsnelheid en niet z'n denksnelheid en ik ben onder de indruk

Ik typ 320 tekens per minuut sustained zonder fouten, en kan over het algemeen een stuk sneller typen dan ik kan programmeren (of het moet echt dom klopwerk zijn ). Ik raak dus netto echt geen tijd kwijt aan die lange identifiers die het programma zoooooooo veeeeeeeeeeeeeeel duidelijker te lezen maken.

[Soultaker]

curry684 schreef op 02 november 2002 @ 21:28:
Ik citeer mezelf: Toon mij een programmeur die serieus in resultaten beperkt wordt door z'n typsnelheid en niet z'n denksnelheid en ik ben onder de indruk

Ik typ 320 tekens per minuut sustained zonder fouten, en kan over het algemeen een stuk sneller typen dan ik kan programmeren (of het moet echt dom klopwerk zijn ). Ik raak dus netto echt geen tijd kwijt aan die lange identifiers die het programma zoooooooo veeeeeeeeeeeeeeel duidelijker te lezen maken.

Typen is vervelend en leid af van de feitelijke implementatie. Als je aan 't typen bent, ben je niet aan 't denken. Hoe minder je typt, hoe meer je aan 't nadenken bent over het probleem in kwestie. Als ik het idee heb dat ik code in zit te typen die 3 keer zo kort had gekund, dan is de lol er voor mij snel af.

Ik kan me trouwens wel redelijk vinden in hezik's genuanceerde versie van zijn betoog.

[Alarmnummer]

Over het algemeen gebruik ik meestal k,l,i voor indexen, maar als ik 2 of meer lussen in elkaar krijg, dan ga ik wel over op een persoonIndex of iets in die geest, omdat ik ander iedere keer moet opzoeken wat het nog maar was.

[Relix]

Ik denk ook dat i van index komt. En waar ik dan weer anders ben dan de anderen, ik gebruik geen j of k, maar ii, iii en iiii. Ja oké, het is wat verwarrend in van die complexe loops en zo, maar ik ben het nu eenmaal gewoon .

Een reden waarom i te gebruiken ipv een langere naam? Als ik wil experimenteren en vlug een loop moet afhebben (slordig, maar werkend) met 1 of 2 lijntjes code, dan is het makkelijker gewoon i te gebruiken ipv eerst nog eens een naampie te verzinnen terwijl het na het compilen/executen toch gewoon verwijdert wordt... eigen mening natuurlijk

[curry684]

Even een stukje code uit mijn grote hoed om het nut te demonstreren van scope-prefixes en duidelijke variabelenamen. Deze niet kinderachtig kleine functie kun je hierdoor volgens mij probleemloos lezen en begrijpen zonder class-definitie of documentatie erbij:

C++:

// ------------------------------------------------------------------------
// Connect: Creates a connection to a server
// ------------------------------------------------------------------------

MBegin(void CClientSocket::Connect(const BString &p_Host, t_UInt2 p_Port,
                                   t_Bool p_Datagram))
  HOSTENT*          l_HostEntity;
  SOCKADDR_IN       l_Address;
  BAsciiString      l_Host        = p_Host;
  t_Handle          l_Socket      = m_Socket;
  t_UInt4           l_IpAddress;
  t_UInt4           l_Size;

  // Check whether we are already connected
  if(m_Connected)
    throw ESockAlreadyConnected(L"CClientSocket::Connect");

  // Buffer properties for reconnect and info
  m_RemoteHost      = p_Host;
  m_RemotePort      = p_Port;
  m_Datagram        = p_Datagram;

  // Create a socket if required
  if(l_Socket == c_InvalidSocket)
    {
    l_Socket    = (t_Handle)socket(AF_INET, p_Datagram ? SOCK_DGRAM : SOCK_STREAM, 0);
    if(l_Socket == c_InvalidSocket)
      throw ESockInvalidSocket(L"CClientSocket::Connect");  
    }

  // Translate the given address, determine type first and prepare struct
  memset(&(l_Address), 0, sizeof(l_Address));
  l_Address.sin_port    = htons(p_Port);
  l_IpAddress           = inet_addr(l_Host);
  if(l_IpAddress == INADDR_NONE)
    {
    // Use DNS resolving to get the host
    l_HostEntity      = gethostbyname(l_Host);
    if(!l_HostEntity)
      throw ESockUnknownHost(L"CClientSocket::Connect", p_Host);
    memcpy(&(l_Address.sin_addr), l_HostEntity->h_addr, l_HostEntity->h_length);
    l_Address.sin_family      = l_HostEntity->h_addrtype;
    }
  else
    {
    // Connect straight away
    l_Address.sin_addr.S_un.S_addr  = l_IpAddress;
    l_Address.sin_family            = AF_INET;
    }

  // Do the actual connect
  if(connect((SOCKET)l_Socket, (sockaddr*)&l_Address, sizeof(l_Address)))
    throw ESockConnectionFailed(L"CClientSocket::Connect", p_Host);

  // Set properties
  m_Connected   = True;
  m_Socket      = l_Socket;

  // Get local address
  l_Size        = sizeof(SOCKADDR_IN);
  if(getsockname((SOCKET)l_Socket, (sockaddr*)m_LocalAddress, (int*)&l_Size))
    throw ESocketException(L"CClientSocket::Connect");
MEnd

// ------------------------------------------------------------------------

Let vooral op het stukje waar 3 parameters toegewezen worden aan 3 membervariabelen. Door de scopeprefixes hadden ze desnoods alle drie dezelfde naam kunnen hebben.

ps. om die 'vreemde' casts tussen SOCKET en t_Handle te verklaren moet je even weten dat de class-definitie platformindependent is en dit toevallig de Win32 WinSock implementatie is. De header files hiervoor zijn zonder preprocessor statements volledig portable.

[ Voor 2% gewijzigd door curry684 op 17-12-2002 00:04 . Reden: voor de highlighter :) ]

[Verwijderd]

curry684 schreef op 02 november 2002 @ 21:28:
Ik citeer mezelf: Toon mij een programmeur die serieus in resultaten beperkt wordt door z'n typsnelheid en niet z'n denksnelheid en ik ben onder de indruk

Het is gewoon irritant om te moeten typen.

Daarnaast is het een feit dat in C++ specifiek niet na te gaan is waar een variabele vandaan komt, terwijl dat in een taal als C veel simpeler na te gaan is, omdat je weinig scopes hebt. De meeste talen hebben dit soort obfuscatie van variabele namen helemaal niet nodig.

Toon mij aan waarom voor een codelezer/-schrijver m_index, s_index, p_index, i_index etc. duidelijker is dan elke variabele z'n eigen naam geven die dus aangeeft wat die variabele nou eigenlijk echt doet? Zal wel aan mij liggen, maar als je variabelen gaat onderscheiden puur en alleen door hun scope, dan ben je gewoon enorm fout bezig. Dat op zich mag dus geen argument zijn. Het enige argument is dan nog dat het de scope aangeeft naast de functie van e variabele op zich, en dat is dus een C++ probleem wat niet in alle talen aanwezig is...

[80000]

Door hezik - Saturday 02 November 2002 14:36

Het gaat er om dat de lezer eenvoudig inzicht krijgt in wat er gebeurd.. en dat is met termen als 'lus' of 'loper' wel zo en met gewauwel als 'i,j,k' niet zo.

//edit
sterker nog, index is gewoon domweg fout. De term 'lus' geeft aan dat het een waarde is afkomstig uit een for-next lus, oftewel dat je aan het itereren bent.

Je verwart de bewerking (itereren) met wat de definitie is hoe je een waarde referereert in een vector, array.

Uit de dikke van Dale:

in·dex (de ~ (m.))

1 inhoudsopgave
2 'index librorum prohibitorum', lijst van door de roomse curie verboden boeken
3 toegevoegd cijfertje of lettertje dat een grootheid in een bepaalde categorie rangschikt
4 verhoudingscijfer


Als je dit opschrijft:

Door hezik - Saturday 02 November 2002 14:53:

code:

oOnderdeel[nOnderdeelLus]

dan is volgens mij definitie 3 van index van toepassing.
Met oOonderdeel de grootheid, array, vector.
nOnderdeelLus de index.

Naast iteraties zijn er heus wel momenten in de code waarbij je alleen naar de waarde van een array referereert. Ik zou voor eenduidigheid op beide verschillende momenten ze als nOnderdeelIndex noemen en niet bij een iteratie de "index" nOnderdeelIterator/nOnderdeelLus noemen en even later nOnderdeelIndex bij een referentie.

[AaroN]

int i;
float f;
double d;

triviale, tijdelijke variabelen zoals nodig in counters etc. worden gewoon afgekort, scheelt weer wat typewerk ipv index etc. (een float zou dan bijv float_index worden of fIndex). Door de eerste letter van het type aan te nemen is ook nog te zien wat het type is. Duidelijk en simpel

[Verwijderd]

dan is volgens mij definitie 3 van index van toepassing.
Met oOonderdeel de grootheid, array, vector.
nOnderdeelLus de index.

Dat is in feite wat ik bedoel met mijn verklaring met .indexoff en de for-next loop. Als je de waarde enkelvoudig gebruikt (om 1 waarde op te halen), vind ik dat het 'index'-zijn waar is, volgens jouw definitie.

Echter, gebruik je een for-next loop dan is het imo belangrijker op dat punt duidelijk te maken dat het een itererende waarde betreft, dat prevaleert dan boven het 'index-zijn'. Door 'm op deze manier te beschrijven ZIE je dat het een itererende waarde is, naast dat het de index is.

Maar goed, ik ben het wel met je eens dat dat misschien een persoonlijke zienswijze is.

[muba]

Come on! Dit staat in vrijwel elk boek/tutorail/etc over programmeren met lusjes... Heeft te maken met een vd eerste progtalen. Er waren maar een paar variablen beschikbaar en i was de eerste... En daarom zijn dus i, j en k de vars die in (geneste) lussen gebruikt worden.