[C++]OOPS Hoe houd je de code overzichtelijk?

[HawVer]

Voor school moeten we een applicatie maken. Dat moet een windows applicatie worden in C++ geschreven. Nou heb ik een constructor gemaakt. Hoe zorgen jullie ervoor om de code overzichtelijk te houden?

Bijvoorbeeld:
Ik heb een class met de naam Activiteit. Deze class is tegelijk de manager van de class TijdRegistratie. In die class werk ik met meerdere functies, bijvorbeeld:

code:

FindTijdRegistratie(tijdregistratie TijdRegistratie)

Ook in de class tijdregistratie komt "tijdregistratie" veel voor.
Bijvoorbeeld hier ziet het er al vrij onoverzichtelijk uit:

code:

void Activiteit::AddTijdRegistratie( TijdRegistratie a)
{
    TijdRegistraties.push_back(a);
    TijdRegistraties.at(iNumTijdRegistratie).SetIndex(iNumTijdRegistratie);
    iNumTijdRegistratie++;
}

TijdRegistraties is de naam van de vector.
iNumTijdRegistratie is de index.
Tijdregistratie is de class.

Mijn probleem is hoe zorg ik ervoor dat mijn code overzichtelijk blijft?

• :? Wat voor naam geef ik aan de parameters? Inmiddels komt tijdregistratie al zoveel in de code voor dat het redelijk onoverzichtelijk word. :? kan ik functies mischien beter andere namen geven?

[Nielsz]

Je kan natuurlijk de parameters uniek identificeren door een bv "prm_" voor te zetten.

[whoami]

Je zult moeten naming-conventions uitdenken en deze dan ook altijd consequent toepassen.

[Verwijderd]

Op woensdag 05 juni 2002 12:12 schreef Nielsz het volgende:
Je kan natuurlijk de parameters uniek identificeren door een bv "prm_" voor te zetten.

En zo zijn er nog 162.000 andere mogelijke 'oplossingen'.

[Verwijderd]

wat ik altijd belangrijk vind is inderdaad consequent zijn in de naamgeving. En daar valt bij iig onder geen nederlands en engels door elkaar gebruiken.. Ik ben een voorstander voor engels omdat dat veel compacter is.
Zo vind ik add_timereg duidelijker dan VoegtoeTijdRegistratie

[Soultaker]

Zelf hanteer ik altijd de (camel?) conventie om (onder andere) attributen en methoden met een kleine letter te beginnen en klassen met een hoofdletter. Dat scheelt al een stukje overzicht. Er zijn zoals gezegd ook nog wel andere manieren om dat te doen.

Verder is er een software metriek met de naam 'coupling' (waar ik zo snel geen Nederlands equivalent voor weet), wat in kwalitatieve zin overeenkomt met de mate waarin klassen met elkaar verweven zijn.

Bij het opstellen van een objectgeorienteerd ontwerp is het doorgaans verstandig om zo min mogelijk 'coupling' te hebben, aangezien hierdoor het aantal andere klassen waarmee een klasse te maken heeft beperkt wordt en je code (bijgevolg) overzichtelijker en (belangrijker) beter te onderhouden is.

Als je immers een 'highly coupled' klasse aanpast, zul je ook veel andere klassen langs moeten lopen om er zeker van te zijn dat het nieuwe gedrag van de klasse geen problemen oplevert. Als je hier bij het ontwerpen rekening mee houdt, kan dat voordelen op leveren die niet ten koste gaan van de efficientie of de samenhang.

Wanneer je model goed in elkaar steekt, maakt het niet zoveel meer uit welke naamgeving je nu precies toepast (hoewel ik je aan zou willen raden om jezelf een 'gevestigde' coding standard aan te leren).

Edit:
Ik zeg wel dat het 'niet meer zoveel uitmaakt', maar daarbij bedoel ik uiteraard dat het niet uitmaakt welke standaard je nu precies aanhangt. Zoals anderen al aangaven, is het wel heel belangrijk dat je consequent bent in je naamgeving (net als in de werking van je klassen en methoden, trouwens).

[Verwijderd]

Zo vind ik add_timereg duidelijker dan VoegtoeTijdRegistratie

Over het door elkaar gebruiken van engels en nederlands ben ik het helemaal met je eens, zeker als het gaat om beide talen in 1 functienaam .

[mening]
Waar ik echter allergisch voor ben zijn afkortingen en underscores.

Afkortingen ben ik tegen omdat iedereen een andere manier heeft om dingen af te korten. Ik heb gewerkt aan een wat groter project wat gebruikt moet worden onder AIX (Unix dus) en daarin werd gebruik gemaakt van signals. Iedereen heeft een ander idee van hoe je dat nou afkort, dus in dat ene project werd gebruik gemaakt van: 'sig' 'sign' 'sgn' 'sgnl' en 'signl' (w00t! 1 letter bespaard! ). Afkortingen... prima als je zonodig moet, maar maak er afspraken over
In het geval van jouw voorbeeld zou ik dan niet 'add_timereg' maar AddTimeRegistration gebruiken. Weet je meteen dat 'reg' niet om een register gaat of om een regio (tijdzone!) maar om een registratie.

Underscores vind ik gewoon lelijk en ze zijn vervelend om in te typen .
[/mening]

[drm]

Qlone:
Underscores vind ik gewoon lelijk en ze zijn vervelend om in te typen .

soulmate!

Behalve in macros, die ik altijd in hoofdletters doe, is het
^</mening>

[The End]

Op woensdag 05 juni 2002 14:09 schreef drm het volgende:

[..]

soulmate!

Behalve in macros, die ik altijd in hoofdletters doe, is het
^</mening>

LOL, dat doe ik ook altijd.

Ik maak altijd wel lange namen van variablen... Ik vind dat later veel duidelijker om terug te lezen. Natuurlijk wel alles in het engels. (De rest van de taal is ook engels, dus dat leest een stuk makkelijker)

[Verwijderd]

Zijn er werkelijk mensen die ageren tegen het gebruik van underscores in labels?

Sommige mensen zijn pas blij als ze zich over iets irrelevants druk kunnen maken. Ik vind persoonlijk het gebruik van de letter "e" in labels zeer afkeurenswaardig.

/me ligt slap.

[Korben]

Ik maak veel en graag gebruik van de m_pnotHungarian notatie Ik vind het gewoon erg handig, die scheiding tussen globale variabelen, member vars en lokale vars.

[farlane]

code:

bool zijn_underscores_cool ()
{
    return true;
}

[Verwijderd]

code:

char *underscores()
{
 return ('_'&1)?"suck":"rule?";
}

[.oisyn]

In C++ maak ik idd ook gebruik van de camel notatie, en in C gewoon kleine letters en underscores... Ik weet niet waarom, maar ik vind underscores en geen hoofdletters typisch C, terwijl het andere weer typisch C++ is (waarschijnlijk wegens OO redenen...)

dus in C:

code:

void namespace_functie_naam ()
{
    // waarin namespace aangeeft bij welke groep de functie hoort
}

int variabele_die_bestaat_uit_meerdere_woorden;
typedef struct structure_s
{
    ...
} structure_t;

en in C++:

code:

void namespace::functieNaam ()
{
}

int variabeleDieBestaatUitMeerdereWoorden;
typedef struct Structure_s
{
    ...
} Structure;

class BegintOokMetEenHoofdletter
{
};

en hungarian notation vind ik vies

[HawVer]

Op woensdag schreef Xenophage :
Ik maak veel en graag gebruik van de m_pnotHungarian notatie Ik vind het gewoon erg handig, die scheiding tussen globale variabelen, member vars en lokale vars.

En wanneer pas je dat dan allemaal toe? m_parameter bij een member var? Bij een lokale dan?

[Verwijderd]

Bij een lokale var laat je 't 'm_' deel weg.

m_bla voor member variabelen.
g_bla voor globale variabelen.
bla voor gewone variabelen.

[.oisyn]

Op woensdag 05 juni 2002 16:36 schreef Qlone het volgende:
Bij een lokale var laat je 't 'm_' deel weg.

m_bla voor member variabelen.
g_bla voor globale variabelen.
bla voor gewone variabelen.

en p_bla voor parameters

[Verwijderd]

Ik ben een echte voorstander van de alom gehate Hungarian notatie. Simpelweg omdat ik het duidelijker vind. Ik heb verder een a-b-s-o-l-u-t-e afkeer van gebruik van Nederlands in een voor de rest Engelse programmeertaal.

code:

do {
   // ene uiterste
   MijnLeukeProcedure(MijnVariabeleNummerEen, Mijnvariabelenummer2); 
   // andere uiterste
   functie(i,s,n*o,t,l+3,3*7);
} while( blijfloopen != true );

vind ik noobcode _{Opgepast! persoonlijke mening}

code:

do
{
  FunProcedure( nIntegerVar, fFloatVar, pszStringPointer );
} while( !bLoop );

[Soultaker]

Op woensdag 05 juni 2002 18:04 schreef SpHeaRe het volgende:
Ik heb verder een a-b-s-o-l-u-t-e afkeer van gebruik van Nederlands in een voor de rest Engelse programmeertaal.

code:

do {
   // ene uiterste
   MijnLeukeProcedure(MijnVariabeleNummerEen, Mijnvariabelenummer2); 
   // andere uiterste
   functie(i,s,n*o,t,l+3,3*7);
} while( blijfloopen != true );

Dus "MyFunnyProcedure" en "MyVariableNumberOne" waren wel goede namen geweest? Je illustreert inderdaad een slechte naamgeving, maar die heeft niets met taal te maken.

Los daarvan vind ik de constructie "while( blijfloopen != true )" juist ontzettend ranzig. Je illustreert gelijk al het probleem door de fout te maken dat (volledig tegen alle redelijke verwachting in) wanneer 'blijfloopen' true is, de lus juist wordt afgebroken!

Een break statement in de lus is veel duidelijker; de betekenis daarvan kan niet verkeerd geinterpreteerd worden. Daarbij hoef je met een break-statement er niet aan te denken je lusconditie bij het ingaan van je lus op een zekere waarde te zetten. Als je de controle bovenaan zet (in plaats van, zoals hier, onderaan), moet je deze conditie zelfs zowel boven als in je lus zetten om 't juiste resultaat te krijgen!

Tenslotte vind ik het vergelijken van boolean waarden met true of false een beetje zinloze code. 'if(b)' is net zo geldig als 'if(b==true)'.

Kortom; vergeleken met de stapel stijlfouten in je voorbeeldcode valt de relevantie van de (natuurlijke) taal waarin identifiers benoemd worden in het niet.

Edit: Snel je code editten, he. Je bent het dus blijkbaar niet helemaal met me oneens. Het zou wel duidelijker zijn als je in je voorbeeld code een enkel aspect aan het licht bracht.

[^Mo^]

voor inkomende parameters zet ik er altijd 'in' voor, voor uitgaande 'out' en in- en uitgaande 'io'

code:

void SomeFunction( int inNumber, MyClass &outObj, MyClass &ioObj);

Om maar iets te noemen...

[.oisyn]

Op woensdag 05 juni 2002 18:25 schreef _Mo_ het volgende:
voor inkomende parameters zet ik er altijd 'in' voor, voor uitgaande 'out' en in- en uitgaande 'io'

code:

void SomeFunction( int inNumber, MyClass &outObj, MyClass &ioObj);

Om maar iets te noemen...

ik vind het systeem wat ze voor de win32 platform sdk gebruiken wel handig:

code:

#define IN
#define OUT
#define INOUT

void Functie (OUT void * buffer, IN int blaat);

[Verwijderd]

Er zijn tig verschilende manieren om je code overzichtelijk te maken, waarvan iedereen zo zijn eigen voorkeur heeft.

Belangrijkste is dat ze consequent toegepast worden.

Naast naamgeving van je vars/functies, scheelt de "layout" ook een hele boel.

Waar ik persoonlijk een hekel aan heb, is code waarin de accolades op de zelfde regel gezet zijn als het if/else/while etc. statement.

Dus geen

code:

if (x == y) {
   ....
} else {
   ....
}

maar

code:

if (x == y)
{
   .....
}
else
{
   .....
}

Maar ieder zijn/haar voorkeur

[whoami]

Misschien heb je hier ook nog wat aan:
http://gathering.tweakers.net/forum/list_messages/392390/#netcoden

[Verwijderd]

Nu we het hier toch over hebben..
Naar mijn mening is het ook redelijk onzinnig om het inspring werk door de tab-toets te laten vergemakkelijken. Twee spaties vind ik meer dan genoeg om enig structuur te ontdekken, en je krijg niet zo'n nekkramp bij het lezen van je code.

[.oisyn]

mwa ik hou eigenlijk wel van veel wit in mijn code... dan lijkt het niet zo snel een zootje

dus: tabs = 4 en gebruik maken van "alinea's"
tabs = 2 vind ik toch wat irritant lezen

maar das mijn mening natuurlijk

[Verwijderd]

Op woensdag 05 juni 2002 18:21 schreef Soultaker het volgende:

[..]

Dus "MyFunnyProcedure" en "MyVariableNumberOne" waren wel goede namen geweest? Je illustreert inderdaad een slechte naamgeving, maar die heeft niets met taal te maken.

Los daarvan vind ik de constructie "while( blijfloopen != true )" juist ontzettend ranzig. Je illustreert gelijk al het probleem door de fout te maken dat (volledig tegen alle redelijke verwachting in) wanneer 'blijfloopen' true is, de lus juist wordt afgebroken!

Een break statement in de lus is veel duidelijker; de betekenis daarvan kan niet verkeerd geinterpreteerd worden. Daarbij hoef je met een break-statement er niet aan te denken je lusconditie bij het ingaan van je lus op een zekere waarde te zetten. Als je de controle bovenaan zet (in plaats van, zoals hier, onderaan), moet je deze conditie zelfs zowel boven als in je lus zetten om 't juiste resultaat te krijgen!

Tenslotte vind ik het vergelijken van boolean waarden met true of false een beetje zinloze code. 'if(b)' is net zo geldig als 'if(b==true)'.

Kortom; vergeleken met de stapel stijlfouten in je voorbeeldcode valt de relevantie van de (natuurlijke) taal waarin identifiers benoemd worden in het niet.

Edit: Snel je code editten, he. Je bent het dus blijkbaar niet helemaal met me oneens. Het zou wel duidelijker zijn als je in je voorbeeld code een enkel aspect aan het licht bracht.

Het eerste voorbeeld is inderdaad hoe het in mijn ogen niet moet, het tweede hoe ik het doe.

Dus "MyFunnyProcedure" en "MyVariableNumberOne" waren wel goede namen geweest? Je illustreert inderdaad een slechte naamgeving, maar die heeft niets met taal te maken.

Neen zeker niet. Een duidelijk onderscheid tussen variabelen en functies is handig. Vandaar dat een variabale best met een kleine letter begint en een functie met een grote (of omgekeerd, het is maar hoe je het wilt).


btw. het enige wat ik aan mijn code ge-edit heb is een verkeerd gespeld [ quote] tag...

[Verwijderd]

Paar dingen die ik doe :

- net als _Mo_ "inParam", "outParam" en "ioParam" gebruiken.
- lokale variable meestal "the" als prefix, bvb int theIndex
- klasse members met prefix 'm', bvb mSettings
- namen van klassen met hoofdletters, functies doorgaans met kleine letter
- eveneens engels gebruiken ipv nederlands
- accolades zoals Digital_Cow zegt, want die andere notatie kijk ik me scheel op
- vaak meerdere lijnen gebruiken : 1e lijn de 'results', dan functienaam en parameters, en voor constructors dan evtuele initializers etc, dus bvb (zo maar snel iets neergeschreven)

code:

char*
CreateAString( const int inLength, int* outLength )
{
  <implementatie>
}

en

MyClass::MyClass( const int inLength )
: mLength( inLength )
{
  <verdere implementatie>
}

- altijd (relatief) kleine functies schrijven, een functie langer dan 30 lijnen schrijf ik zelden; ik schrijf dus vaak 'convenience' calls
- functies scheiden van elkaar door een regel of 3 a 4 witte ruimte ertussen te laten; tevens alle functies enzo laten voorafgaan van doxygen commentaar etc
- 1 file per "klasse", de naam van de file is de naam van de klasse (wel, eigenlijk 2 files per klasse : 1 header file en 1 cpp file). Ik kan je verzekeren dat je zo al veel wint als je met projecten moet werken die honderden (soms bijzonder uitgebreide) klassen hebben...
- en dan een regel die ik "geef code ademruimte !" zou durven noemen. Na een '(' een spatie en voor een ')' ook een, if en else geval door extra witte regel scheiden, etc. Dus niet (wat jij doet)

code:

void Activiteit::AddTijdRegistratie(TijdRegistratie a)
{
    TijdRegistraties.push_back(a);
    TijdRegistraties.at(iNumTijdRegistratie).SetIndex(iNumTijdRegistratie);
    iNumTijdRegistratie++;
}

maar

code:

void
Activiteit::AddTijdRegistratie( TijdRegistratie a )
{
  TijdRegistraties.push_back( a );
  TijdRegistraties.at( iNumTijdRegistratie ).SetIndex( iNumTijdRegistratie );

  ++iNumTijdRegistratie;

  if ( iNumTijdRegistratie > 10 )
  {
    cout << "blablabla..." << endl;
  }

  else
  {
    cout << "blaatblaat..." << endl;
  }

  // do some math
  int theNumber = 5 * mNumber + iNumTijdRegistratie / 5;

- nog wel een paar dingen waar ik nu net even niet aan denk

[joho]

Goede OO code heeft wat mij betreft niet zoveel met coding conventies/layout te maken.

Er telt maar een ding; Geef alles een passende naam.
Denk OO, dus objecten. Een Kalender is een ding, een Afspraak is een ding, maar een TijdRegistratie is toch niks.

Je moet de code kunnen lezen alsof het 'normale' tekst is. Je implementatie is de meest gedetaileerde specificatie die je kunt schrijven.

Het datatype hoort ook niet echt thuis in de method name, dit zou gewoon de actie moeten zijn die je op het object uitvoert, dus 'voegToe' ipv 'voegToeAfspraak'.

En in de method parameters hoort het datatype ook niet thuis. De naam van de parameter moet de rol zijn die het meegegeven object vervult. Als je een Mens wilt meegeven, gebruik dan de rol die die Mens vervult (bijvoorbeeld vader, moeder, kind etc) als parameter naam.

Voetbalspeler::ontvang(Kaart kaart) {
if (kaart.kleur==ROOD) {
verlaatVeld();
}
if (kaart.kleur==GEEL) {
aantalGeleKaarten++;
pasGedragAan();
}
}

[Glimi]

Op woensdag 05 juni 2002 18:25 schreef _Mo_ het volgende:
voor inkomende parameters zet ik er altijd 'in' voor, voor uitgaande 'out' en in- en uitgaande 'io'

code:

void SomeFunction( int inNumber, MyClass &outObj, MyClass &ioObj);

Om maar iets te noemen...

Hehehehe Jij moet wel met CORBA gewerkt hebben

[HawVer]

Op woensdag schreef SpHeaRe:
Ik ben een echte voorstander van de alom gehate Hungarian notatie. Simpelweg omdat ik het duidelijker vind. Ik heb verder een a-b-s-o-l-u-t-e afkeer van gebruik van Nederlands in een voor de rest Engelse programmeertaal.

code:

do {
   // ene uiterste
   MijnLeukeProcedure(MijnVariabeleNummerEen, Mijnvariabelenummer2); 
   // andere uiterste
   functie(i,s,n*o,t,l+3,3*7);
} while( blijfloopen != true );

vind ik noobcode _{Opgepast! persoonlijke mening}

code:

do
{
  FunProcedure( nIntegerVar, fFloatVar, pszStringPointer );
} while( !bLoop );

Is mijn code n00b code?
Maar dat alles engels moet ben ik het niet mee eens. Ik vind de engelse code van jou er niet beter op worden. Bij dat moet ik ook het UML aanhouden. Als ik dan in mijn code veel engels gebruik word het UML er niet overzichtelijk van. Eigenlijk de verkeerde volgorde...
Op de opleiding worden de applicatie zo gemaakt dat het makkelijk moet zijn om het aanpassen door anderen.

Op woensdag schreef joho:
Goede OO code heeft wat mij betreft niet zoveel met coding conventies/layout te maken.

Er telt maar een ding; Geef alles een passende naam.
Denk OO, dus objecten. Een Kalender is een ding, een Afspraak is een ding, maar een TijdRegistratie is toch niks.

Je moet de code kunnen lezen alsof het 'normale' tekst is. Je implementatie is de meest gedetaileerde specificatie die je kunt schrijven.

Het datatype hoort ook niet echt thuis in de method name, dit zou gewoon de actie moeten zijn die je op het object uitvoert, dus 'voegToe' ipv 'voegToeAfspraak'.

En in de method parameters hoort het datatype ook niet thuis. De naam van de parameter moet de rol zijn die het meegegeven object vervult. Als je een Mens wilt meegeven, gebruik dan de rol die die Mens vervult (bijvoorbeeld vader, moeder, kind etc) als parameter naam.

Voetbalspeler::ontvang(Kaart kaart) {
if (kaart.kleur==ROOD) {
verlaatVeld();
}
if (kaart.kleur==GEEL) {
aantalGeleKaarten++;
pasGedragAan();
}
}

Maar ik vind dit ook eigenlijk weer het andere uiterste. Als je de code op deze manier in elkaar zet krijg je moeilijke functienamen. Bijvoorbeeld bij de vector zou je zulk een soort functie krijgen:

code:

Actviteit::ToevoegenTijdRegistratie(tijdregistratie t)

Persoonlijk vind ik nederlands moeilijk in de code te gebruiken. Maar voor een class naam houd ik liever wel nederlands aan. Voor de functie liever meer engels. Waardoor je dit krijgt:

code:

void Activiteit::AddTijdRegistratie

[drm]

mietje:
Zijn er werkelijk mensen die ageren tegen het gebruik van underscores in labels?

Ik heb er idd een aversie tegen. Waarom weet ik niet. Ik gebruik ze het liefst niet, maar soms maakt het idd e.e.a. wel wat duidelijker en dan zal ik 't niet nalaten ze wel te gebruiken.

Sommige mensen zijn pas blij als ze zich over iets irrelevants druk kunnen maken.

Vuile flamert

Ik vind persoonlijk het gebruik van de letter "e" in labels zeer afkeurenswaardig.

Ik ook.

/me ligt slap.

* drm kan zich herinneren dat hier al eens eerder een discussie over is geweest, en gaat er niet nog 1 aan.

UTFS

[HawVer]

UTFS

Heb je wel eens gehoord van RTFF?

[mbravenboer]

Ik werk vaak in een taal waar de - niet gereserveerd is voor de gebruikelijke aftrekking. Om de een of andere reden gebruik ik de - daar graag als scheidingsteken tussen woorden ipv CamelCase, maar heb ik wel een hekel aan underscores... .

Overigens zie je deze - ook vaak terug in de namen van XML elementen in bijna alle XML standaarden.

Kennelijk heeft een underscore toch iets visueel onaantrekkelijks .

[drm]

HawVer:
Heb je wel eens gehoord van RTFF?

mbravenboer:
Ik werk vaak in een taal waar de - niet gereserveerd is voor de gebruikelijke aftrekking. Om de een of andere reden gebruik ik de - daar graag als scheidingsteken tussen woorden ipv CamelCase, maar heb ik wel een hekel aan underscores... .

Overigens zie je deze - ook vaak terug in de namen van XML elementen in bijna alle XML standaarden.

Kennelijk heeft een underscore toch iets visueel onaantrekkelijks .

De dash vind ik inderdaad ook een fijne, en gebruik hem redelijk vaak in XML (wanneer ik XML gebruik, en dat is dan weer niet zo vaak ).

Dash gebruik ik ook veel in bestandsnamen, en ook daarin heb ik een hekel aan underscores.

Ik weet niet wat het is... 't is gewoon... lelijk ...

[Verwijderd]

er was ook een of ander voordeel om

code:

if( 1 == aValue )
{
}

te gebruiken in plaats van

code:

if( aValue == 1 )
{

}

hoe zat dat ook al weer... was iets met "stel dat aValue nog niet geinitialiseerd is dan..."

las dat ooit ergens en klonk erg nuttig dus gebruik het sindsdien maar weet niet echt meer waarom

[.oisyn]

dat is voor als je per ongeluk = ipv == tiept.

if (bla = 1) werkt namelijk prima: het is altijd true en bla wordt geassigned met 1

als je if (1 = bla) doet dan krijg je een compiletime error

[Verwijderd]

Op donderdag 06 juni 2002 13:13 schreef .oisyn het volgende:
dat is voor als je per ongeluk = ipv == tiept.

if (bla = 1) werkt namelijk prima: het is altijd true en bla wordt geassigned met 1

als je if (1 = bla) doet dan krijg je een compiletime error

oooohja dat was het.. zo hoef je je nooit suf te zoeken naar je bug..

[mbravenboer]

fladder: hoe zat dat ook al weer... was iets met "stel dat aValue nog niet geinitialiseerd is dan..."

las dat ooit ergens en klonk erg nuttig dus gebruik het sindsdien maar weet niet echt meer waarom

Je ziet ditzelfde terug in Java bij vergelijken:

code:

"hoi".equals(var)

zal false opleveren als var null is. Andersom zou er een NullPointerException zijn ontstaan als var null is. Vaak wil je het eerste gedrag, dus is het handig om het andersom te schrijven .

De == versus = is in feite vaak alleen een probleem als de variabele toevallig een boolean is (in Java althans). Het resultaat van een assignment aan een niet boolean variabele is immers ook geen boolean...

[.oisyn]

mbravenboer: stfu, 't is een c++ topic

[mbravenboer]

.oisyn: mbravenboer: stfu, 't is een c++ topic

Ik ben voor spreiding van programmeertalen over topics . Dat bevordert de integratie tussen P&W'ers en vermindert het aantal achterstand-topics .

[drm]

mbravenboer:
Ik ben voor spreiding van programmeertalen over topics . Dat bevordert de integratie tussen P&W'ers en vermindert het aantal achterstand-topics .

Nou, in PHP, he, daar ...

[Glimi]

Op donderdag 06 juni 2002 13:42 schreef drm het volgende:

Nou, in PHP, he, daar ...

[flame modus]
Hij had het over programmeertalen hoor ....
[/flame modus]

[The End]

Op donderdag 06 juni 2002 13:13 schreef .oisyn het volgende:
dat is voor als je per ongeluk = ipv == tiept.

if (bla = 1) werkt namelijk prima: het is altijd true en bla wordt geassigned met 1

als je if (1 = bla) doet dan krijg je een compiletime error

VC6 kan je zo instellen dat hij een warning geeft als je 'if(bla = 1)' hebt getypt.

[.oisyn]

Op donderdag 06 juni 2002 14:52 schreef The End het volgende:

[..]

VC6 kan je zo instellen dat hij een warning geeft als je 'if(bla = 1)' hebt getypt.

weet ik, ik gebruik die truuc ook verder niet
Maar aan die warning heb ik niet veel omdat ik m wel eens gebruik in een if of while ofzo

zo van:

code:

while (node = node->next)
{
    ...
}

niet zo handig als je dan allemaal warnings krijgt

[Verwijderd]

niet zo handig als je dan allemaal warnings krijgt

Die krijg je ook niet afaik. Hij geeft alleen de warning als je een assignment doet vanaf een contante waarde.

'if (bla = 1)' moet haast wel fout zijn namelijk; wie programmeert er nou een 'if' om iets wat altijd true is, en volgens die regel geeft ie ook warnings.

[.oisyn]

is dat zo?
oh dat zou idd wel beter zijn... even proberen zo
(maar ik zou toch zweren dat ik er eerst last van kreeg met mijn if-constructies die geen constanten gebruikten)

[The End]

Op donderdag 06 juni 2002 15:02 schreef .oisyn het volgende:
is dat zo?
oh dat zou idd wel beter zijn... even proberen zo
(maar ik zou toch zweren dat ik er eerst last van kreeg met mijn if-constructies die geen constanten gebruikten)

Ik gebruik c-files die gegenereerd zijn door een MIDL compiler. Als ik de warning level op 4 zet in mijn project, dan krijg ik zoveel warnings in die MIDL gegenereerde file, dat ik al niet eens meer let op het aantal warnings (en dan zijn ze dus ook niet nuttig meer)

[drm]

Ik kan me herinneren dat de Turbo C compiler ook zo'n warning had.

'Possible incorrect assignment' heette die. Die warning kwam ook alleen wanneer je if ( var = constante_waarde ) gebruikte, niet if ( var = ( evaluatie ) )

_{oops, stiekem toch een underscore gebruikt}

[Verwijderd]

Op donderdag 06 juni 2002 08:53 schreef HawVer het volgende:
Is mijn code n00b code?

Neen dat bedoelde ik niet.
Ik breng mijn tijd op school door tussen mensen die voor de eerste keer leren programmeren, en dan krijg je van die "creaties" met willekeurig hoofdletter gebruik en toestanden.

En eigenlijk als je erover nadenkt maakt het toch niet uit hoe iemand zijn code schrijft, zolang jij en de mensen die moeten instaan voor de maintainance er maar aan uit kunnen. Het belangrijkste is gewoon consistentie.

[drm]

SpHeaRe:
Het belangrijkste is gewoon consistentie.

Als ik alles met hoofdletters doe, word jij ook niet blij, dus da's ook niet helemaal waar

[Verwijderd]

Op donderdag 06 juni 2002 18:46 schreef drm het volgende:

[..]

Als ik alles met hoofdletters doe, word jij ook niet blij, dus da's ook niet helemaal waar

lol good point

Maar aan de andere kant, stel dat jij en enkele medewerkers de enige zijn die die code bekijken, en jullie tot die prachtige afspraak zijn gekomen, is er toch geen probleem ?

[beetje OT]
Overigens vind ik wel dat er bij cursussen programmeren op scholen e.d. veel te weinig aandacht aan (eender welke) codingstyle wordt besteed.

[Verwijderd]

Overigens vind ik wel dat er bij cursussen programmeren op scholen e.d. veel te weinig aandacht aan (eender welke) codingstyle wordt besteed.

Op de opleiding die ik gevolgd heb (informatica aan de HvU) hadden we ons maar te houden aan de door hun ontwikkelde coding style. Die was dusdanig lelijk dat ik het voor mezelf onhandig vond om me er aan te houden (vond mijn stijl beter ) en dat heb ik ook niet gedaan dus. Dat heeft me wat felle discussies opgeleverd met de docent programmeren, die 't uiteindelijk maar heeft opgegeven .

[.oisyn]

Qlone: lol
ik doe nu ook HvU (3e jaars), en hun codingstyle is idd erg lelijk... maar ze dwingen ons niet om hun style aan te houden
Wanneer zat jij er? (en noem eens wat docenten die die style gebruikten )

[drm]

SpHeaRe:
lol good point

Maar aan de andere kant, stel dat jij en enkele medewerkers de enige zijn die die code bekijken, en jullie tot die prachtige afspraak zijn gekomen, is er toch geen probleem ?

Da's waar. Maar als ik in zo'n team zat, waren we nooit tot die afspraak gekomen, naturally

[HawVer]

Op donderdag schreef SpHeaRe:
[beetje OT]
Overigens vind ik wel dat er bij cursussen programmeren op scholen e.d. veel te weinig aandacht aan (eender welke) codingstyle wordt besteed.

Daar heb je gelijk aan. Ik doe nu de HI opleiding. Het enigste wat we gehad hebben is functies met hoofdletters en variabelen met kleine letters. Verder word er geen aandacht aan besteed. Vandaar ook mijn topic.

drm:
_{RTFF was ook een grapje...}

[Verwijderd]

Op donderdag 06 juni 2002 23:05 schreef SpHeaRe het volgende:
Overigens vind ik wel dat er bij cursussen programmeren op scholen e.d. veel te weinig aandacht aan (eender welke) codingstyle wordt besteed.

Codingstyle is tot op zekere hoogte toch iets persoonlijks? Iets wat je zelf ontwikkelt? Ik vind dit p_pszBlaat variabelenamen werkelijk gruwelijk lelijk, maar andere vinden dat schijnbaar mooi. Om het maar niet over de linux kernel coding style te hebben (qua indenting), da's gewoon afgrijselijk...
Ik heb weer een andere codingstyle die anderen waarschijnlijk gruwelijk lelijk vinden maar waar ik me erg goed in kan vinden.

Dus op scholen aan codingstyle werken vind ik twijfelachtig, dat moet je zelf ontwikkelen.

[Korben]

Op woensdag 05 juni 2002 16:59 schreef .oisyn het volgende:

[..]

en p_bla voor parameters

Serieus? Hmm. Damn, dan moet ik een kleine 8000 regels code herschrijven. Not cool.

[Verwijderd]

Wanneer zat jij er? (en noem eens wat docenten die die style gebruikten)

Ik ben afgelopen februari afgestudeerd daar (en zo blij dat ik er weg ben ). Het 'enforcen' van de coding style werd vooral aangehangen door dhr Wen****. Op zich een goede docent, maar soms wat bekrompen als 't op regeltjes aankomt. Bijna alle practica aan het eind van de opleiding heb ik bij hem gevolgd (en in 1x gehaald )

[.oisyn]

woei, ik zit nu op dit moment in de les bij wensink
computer graphics... en ik vind het dus geen goede docent; hoewel hij het zelf op zich wel snapt, kan hij niet echt goed uitleggen

Maar ik heb nooit echt last gehad van zijn code conventies... ja C++ 2 jaar terug, met z'n speciale manier van commenten. Maar toen wist ik m er wel van te overtuigen dat mijn manier ook wel ok was

En Gerlofsma kan er ook wel wat van

[Verwijderd]

computer graphics... en ik vind het dus geen goede docent; hoewel hij het zelf op zich wel snapt, kan hij niet echt goed uitleggen

Mwah... vond ik wel meevallen. Computer graphics was sowieso een makkelijk vak met een erg makkelijk praktikum. Weet natuurlijk niet hoe 't nu gaat maar ik hoor dingen over 3d landschapjes, dus heel heftig lijkt 't nog steeds niet

Maar ik heb nooit echt last gehad van zijn code conventies... ja C++ 2 jaar terug, met z'n speciale manier van commenten.

Oh... last heb ik er niet van gehad . Het heeft me alleen wat gediscussieer gekost voor ie z'n standpunt liet gaan... Kennelijk is ie tegenwoordig minder fanatiek ermee dan...

En Gerlofsma kan er ook wel wat van

Argh... daar noem je er ook een . Ik heb GLM gehad als begeleider bij laatste stage (die krijg jij niet meer als 't goed is... een 2e stage) en tijdens m'n afstuderen. Als begeleider bij dat soort dingen is ie wel ok, maar met hem als praktikumdocent kreeg ik soms de neiging om dan toch maar een pistool te gaan regelen .