Goede code opmaak

Pagina: 1 2 Laatste
Acties:
  • 422 views sinds 30-01-2008
  • Reageer

  • AK47
  • Registratie: Juli 2001
  • Laatst online: 04-05-2024
Naar aanleiding van een topic waarin ik toch wel wat opmerkingen kreeg over mijn code opmaak. Hoe moet ik dit wel goed doen?
* AK47 kan dit keer ook weer niets vinden via de search :(

  • razor-x
  • Registratie: Februari 2001
  • Laatst online: 05-06 07:37
ik snap er nix van!

  • Nielsz
  • Registratie: Maart 2001
  • Niet online
In de P&W faq staat een heel mooi stukkie van D2k over mooie code opmaak

  • AK47
  • Registratie: Juli 2001
  • Laatst online: 04-05-2024
Op dinsdag 25 december 2001 10:56 schreef razor-x het volgende:
ik snap er nix van!
Ik wil gewoon wat tips bij het maken van een goede, begrijpbare & duidelijke code.

Verwijderd

zo iets als
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
<?
function bla() {
   global $zietermooiuit;

   if ($test == "bla") {
      echo "bladedievbla";
   }else{
      // doe iets :P
   }

}
?>

dit ziet er mooi uit ;)

--edit ik gebruik als 'tabs' 4 spacings...

  • AK47
  • Registratie: Juli 2001
  • Laatst online: 04-05-2024
Op dinsdag 25 december 2001 10:57 schreef Nielsz het volgende:
In de P&W faq staat een heel mooi stukkie van D2k over mooie code opmaak
ah, thanx

  • AK47
  • Registratie: Juli 2001
  • Laatst online: 04-05-2024
Op dinsdag 25 december 2001 10:57 schreef Xtentic het volgende:
zo iets als
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
<?
function bla() {
   global $zietermooiuit;

   if ($test == "bla") {
      echo "bladedievbla";
   }else{
      // doe iets :P
   }

}
?>

dit ziet er mooi uit ;)

--edit ik gebruik als 'tabs' 4 spacings...
Oh, zo deed ik het anders ook altijd al...

  • Nielsz
  • Registratie: Maart 2001
  • Niet online
Echt mooi is dat niet hoor :D

  • XTerm
  • Registratie: Juli 2001
  • Laatst online: 10-06-2025
Kijk ook eens in de linux kernel documentatie, daar staat een interessante file over hoe de code er moet uitzien die je naar het kernel hacker team stuurt. Een of andere ANSI standaard...
Zag er ook netjes uit

  • eamelink
  • Registratie: Juni 2001
  • Niet online

eamelink

Droptikkels

Kijk hier maar eens naar, dit is wel een aardige standaard:

http://pear.php.net/manual/standards.php

Verwijderd

Op dinsdag 25 december 2001 11:02 schreef Nielsz het volgende:
Echt mooi is dat niet hoor :D
Hmmz... dan verschillen de meningen dus ;) :P maar nee ik vind het zo erg mooi :)..

8-)

  • Johannes
  • Registratie: Juni 2000
  • Laatst online: 14-09 23:09
Volgens mij lag het niet zozeer aan de opmaak van je code, maar vooral aan de naamgeving van je variabelen. Het ging toch om dit topic: [topic=359819]

Daarbij was niet echt duidelijk wat er nou eigenlijk in een variable zat. Eigenlijk moet je bij het zien van de naam van de variabele meteen kunnen weten wat voor data erin zit. Dus geen vars zoals i_1, i_2 etc.

Uit volle borst op weg naar nergens / Zonder reden zonder doel
Met m'n zeden en m'n zonden / En mijn angstig voorgevoel
Laat mij mijn kont tegen de krib / Laat mij dit goddeloze lied
Hef jij je handen maar ten hemel / Maar red mij niet


  • AK47
  • Registratie: Juli 2001
  • Laatst online: 04-05-2024
Thanx, d00ds, ik ben al knap wat wijzer geworden :)

Verwijderd

/me 82 tm heeft het gefixt :P

Dit topic is weer gemaakt op zeer vage wijze :)

  • Engineer
  • Registratie: Juni 2001
  • Laatst online: 04-05 00:03

Engineer

Software

.

[ Voor 100% gewijzigd door Engineer op 14-10-2018 09:18 ]


Verwijderd

Op dinsdag 25 december 2001 16:09 schreef hdd het volgende:
Goede code opmaak:
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
<?
function gablaten($iets)
{
     if($iets=="dat")
     {
          return "Dit";
     }
     else
     {
          return "Dat";
     }
}
?>

That's the way :)
ik zet altijd bij if, for structures, functions etc, de eerste accolade op diezelfde regel, en gebruik drie spaties, dus
PHP:
1
2
3
4
5
6
7
8
9
10
11
<?
function gablaten($iets)
{
     if($iets=="dat") {
        return "Dit";
     }
     else {
        return "Dat";
     }
}
?>

Verwijderd

Zie faq inderdaad.
[PHP, C, C++, JAVA, etc] Nette code
Veel topics in /14 gaan over code die errors geeft danwel niet werkt.
[topic=327241/1/25]
(Derde post!)

  • flat
  • Registratie: Mei 2000
  • Niet online
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
<?
function gablaten( $iets )
  {
    if( $iets == "dat" )
    {
      return "Dit" ;
    }
    else
    {
      return "Dat" ;
    }
  }
?>

zo doe ik 't
maar 2 spaties, en ook bij haakjes en ;'s een spatie

"Happiness is a way of travel, not a destination."
--Roy Goodman


  • Mithrandir
  • Registratie: Januari 2001
  • Laatst online: 14-09 20:56
Op dinsdag 25 december 2001 18:57 schreef Jppr het volgende:

[..]

ik zet altijd bij if, for structures, functions etc, de eerste accolade op diezelfde regel, en gebruik drie spaties, dus
PHP:
1
2
3
4
5
6
7
8
9
10
11
<?
function gablaten($iets)
{
     if($iets=="dat") {
        return "Dit";
     }
     else {
        return "Dat";
     }
}
?>
Sorry man, maar dat vind ik dus echt _NIET_ te lezen. De manier die je had gequote is veel duidelijker. Komt omdat je de 'diepte' erin veeel beter ziet.

Verbouwing


  • Johannes
  • Registratie: Juni 2000
  • Laatst online: 14-09 23:09
Op dinsdag 25 december 2001 19:39 schreef DinoRaptor het volgende:

[..]

Sorry man, maar dat vind ik dus echt _NIET_ te lezen. De manier die je had gequote is veel duidelijker. Komt omdat je de 'diepte' erin veeel beter ziet.
Ik gebruik juist wel weer deze manier, ik vind dat er veel en veel te veel whitespace komt te staan bij de gequote manier. Dan vind ik twee spaties weer veels te weinig, ik gebruik altijd tabs en een tabstop van 4. Maar ik denk dat we hier wel eeuwig over door kunnen gaan aangezien iedereen weer wat anders gebruikt.

Uit volle borst op weg naar nergens / Zonder reden zonder doel
Met m'n zeden en m'n zonden / En mijn angstig voorgevoel
Laat mij mijn kont tegen de krib / Laat mij dit goddeloze lied
Hef jij je handen maar ten hemel / Maar red mij niet


  • chris
  • Registratie: September 2001
  • Laatst online: 11-03-2022
Hmz, ik zie dat de meningen nogal verschillen. Ik vind het persoonlijk het fijnst om 2 spaties als indention te gebruiken (lees: tabstop=2spaties). Ook vindt ik het mooier als je een { gebruikt om die op dezelfde regel te zetten, vb:
code:
1
2
3
function blaat(){
  do_something();
}

en tussen elke functie een lege regel, tussen belangrijke delen van de code 2 lege regels. Maar je kan niet spreken over een echte standaard, iedereen code toch zoals ie zelf 't fijnst vind of zoals z'n baas dat wil :p

  • chem
  • Registratie: Oktober 2000
  • Laatst online: 27-08 13:53

chem

Reist de wereld rond

kijk hier maar:

http://pear.php.net/manual/standards.php

dat is hoe het ECHT hoort. En 2 of 3 spaties ipv 4 is heel ranzig. Zelf heb ik het liever in tabs, scheelt je een hoop ge-cursor-rechts, maar goed.

Verder is het gebruiken van duidelijke variabelen etc. wel nodig. Ranzige code met $i_1, $i_2 etc. is lelijk en onduidelijk...

Klaar voor een nieuwe uitdaging.


  • Osiris
  • Registratie: Januari 2000
  • Niet online
Op dinsdag 25 december 2001 20:49 schreef chem het volgende:
kijk hier maar:

http://pear.php.net/manual/standards.php

dat is hoe het ECHT hoort. En 2 of 3 spaties ipv 4 is heel ranzig. Zelf heb ik het liever in tabs, scheelt je een hoop ge-cursor-rechts, maar goed.

Verder is het gebruiken van duidelijke variabelen etc. wel nodig. Ranzige code met $i_1, $i_2 etc. is lelijk en onduidelijk...
Woops, ik gebruik ook altijd $i_1 enzo... Anders mot ik zoveel typen, als ik al die variabelen moet uitschrijven. :z ( $plaatje_een is zo lang :z :z :z )

  • Engineer
  • Registratie: Juni 2001
  • Laatst online: 04-05 00:03

Engineer

Software

.

[ Voor 98% gewijzigd door Engineer op 14-10-2018 09:16 ]


Verwijderd

Op dinsdag 25 december 2001 20:49 schreef chem het volgende:
kijk hier maar:

http://pear.php.net/manual/standards.php

dat is hoe het ECHT hoort. En 2 of 3 spaties ipv 4 is heel ranzig. Zelf heb ik het liever in tabs, scheelt je een hoop ge-cursor-rechts, maar goed.

Verder is het gebruiken van duidelijke variabelen etc. wel nodig. Ranzige code met $i_1, $i_2 etc. is lelijk en onduidelijk...
ja, tuurlijk, ik gebruik ook standaard tabs, maar op GoT bvb, dan zet ik drie spaties, want tabben lukt niet

  • chem
  • Registratie: Oktober 2000
  • Laatst online: 27-08 13:53

chem

Reist de wereld rond

Op dinsdag 25 december 2001 20:52 schreef Osiris_NL het volgende:

[..]

Woops, ik gebruik ook altijd $i_1 enzo... Anders mot ik zoveel typen, als ik al die variabelen moet uitschrijven. :z ( $plaatje_een is zo lang :z :z :z )
doe dan $image[1]...
Op dinsdag 25 december 2001 21:09 schreef hdd het volgende:
Die standaard van php is ook maar verzonnen door mensen.

Aangezien ik het er verrekte lelijk eruit vind zien gebruik ik gewoon mijn manier(die ook meer mensen gebruiken).
en dat is?

iig vind ik brakke code veelal code waarbij er niet nagedacht is over leesbaarheid op een later moment...

Klaar voor een nieuwe uitdaging.


  • Engineer
  • Registratie: Juni 2001
  • Laatst online: 04-05 00:03

Engineer

Software

.

[ Voor 100% gewijzigd door Engineer op 14-10-2018 09:16 ]


  • AK47
  • Registratie: Juli 2001
  • Laatst online: 04-05-2024
Op dinsdag 25 december 2001 11:14 schreef Taradino het volgende:
Volgens mij lag het niet zozeer aan de opmaak van je code, maar vooral aan de naamgeving van je variabelen. Het ging toch om dit topic: [topic=359819]

Daarbij was niet echt duidelijk wat er nou eigenlijk in een variable zat. Eigenlijk moet je bij het zien van de naam van de variabele meteen kunnen weten wat voor data erin zit. Dus geen vars zoals i_1, i_2 etc.
Daar ging ik dus de fout in |:(.
Maar verder moet ik dan altijd variable namen verzinnen, waar ik vaak niet zoveel zin heb, dus maak ik er iets van $i of $var van. Meestal wel zo simpel, maar niet zo simpel als anderen iets met je code wil doen.
* AK47 heeft al weer wat geleerd :)

  • razor-x
  • Registratie: Februari 2001
  • Laatst online: 05-06 07:37
[brak?] :?

Verwijderd

je moet er gewoon voor zorgen dat je alles netjes en overzichtelijk houd

en natuurlijk hoe jij het het makkelijkste vind

Verwijderd

Jemig, wat een gezeik, iedereen heeft toch zijn eigen code opmaak? Als je maar consequent bent. |:(

  • chem
  • Registratie: Oktober 2000
  • Laatst online: 27-08 13:53

chem

Reist de wereld rond

brak?

Klaar voor een nieuwe uitdaging.


Verwijderd

Op dinsdag 25 december 2001 22:33 schreef chem het volgende:
brak?
Nu niet meer, ik heb het gefixt :P

Verwijderd

zal ik hem ook maar open doen, is wel zo leuk ;)

  • AK47
  • Registratie: Juli 2001
  • Laatst online: 04-05-2024
Thanx Sinterklaas 82 tm!

  • elnino
  • Registratie: Augustus 2001
  • Laatst online: 03-09 05:13
Ik ben het persoonlijk niet echt helemaal eens met die PEAR coding-standaard, vooral over:
code:
1
2
3
4
5
6
7
8
// Bron: http://pear.php.net/manual/standards.control.php
if ((condition1) || (condition2)) {
    action1;
} elseif ((condition3) && (condition4)) {
    action2;
} else {
    defaultaction;
}

Ik programmeer zelf altijd zo:
code:
1
2
3
4
5
6
7
8
9
10
11
12
if ((condition1) || (condition2)) 
{
    action1;
} 
elseif ((condition3) && (condition4)) 
{
    action2;
} 
else 
{
    defaultaction;
}

Op die manier komen 'de diepte' en de compounds (het stuk tussen de allocades) het beste naar voren. Deze laatste manier wordt ook in de FAQ gebruikt.

  • MikeN
  • Registratie: April 2001
  • Laatst online: 13-09 17:41
Op dinsdag 25 december 2001 23:30 schreef elnino iets waar in het volledig mee eens ben
Het 2e is idd een heel stuk duidelijker.....

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 00:42

.oisyn

Moderator Devschuur®

Demotivational Speaker

Op dinsdag 25 december 2001 23:30 schreef elnino het volgende:
Ik ben het persoonlijk niet echt helemaal eens met die PEAR coding-standaard, vooral over:
code:
1
2
3
4
5
6
7
8
// Bron: http://pear.php.net/manual/standards.control.php
if ((condition1) || (condition2)) {
    action1;
} elseif ((condition3) && (condition4)) {
    action2;
} else {
    defaultaction;
}

[..]
Idd, dit vind ik gewoon een zootje... maar er zijn mensen die er anders over denken :)
Maar veel belangrijker vind ik nog het gebruik van duidelijke class-, functie- en variabelenamen, en consistentie. Afgezien van variabelen als i enzo in korte lusjes natuurlijk :)

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.


  • MikeN
  • Registratie: April 2001
  • Laatst online: 13-09 17:41
Wat ik me nog steeds afvraag:

Voor mysql tabellen en kolomnamen gebruik ik nu bijvoorbeeld:

table users

user_id
user_name
user_email

maar eigenlijk is dat user dan een beetje dubbelop, maar maakt het wel weer duidelijker.... wat vinden jullie nou, moet dat user_ er nou bij of niet?

  • chem
  • Registratie: Oktober 2000
  • Laatst online: 27-08 13:53

chem

Reist de wereld rond

Op dinsdag 25 december 2001 23:30 schreef elnino het volgende:
Ik ben het persoonlijk niet echt helemaal eens met die PEAR coding-standaard, vooral over:
[..]
Op die manier komen 'de diepte' en de compounds (het stuk tussen de allocades) het beste naar voren. Deze laatste manier wordt ook in de FAQ gebruikt.
klopt, dat het is het enige onderdeel dat ik niet snap dat ze het zo voorstellen..

Klaar voor een nieuwe uitdaging.


  • Johannes
  • Registratie: Juni 2000
  • Laatst online: 14-09 23:09
Op dinsdag 25 december 2001 23:46 schreef OiSyN het volgende:

[..]

Idd, dit vind ik gewoon een zootje... maar er zijn mensen die er anders over denken :)
Maar veel belangrijker vind ik nog het gebruik van duidelijke class-, functie- en variabelenamen, en consistentie. Afgezien van variabelen als i enzo in korte lusjes natuurlijk :)
Er zijn mensen die er anders over denken ja. Ik vind namelijk dat er gewoon veelsteveel whitespace op je scherm komt met een lijn voor elk haakje. Als ik vind dat het niet duidelijk is, dan zet ik zelf wel een whitespace neer(en dat doe ik dan ook wel aardig vaak), maar ik vind het te irritant. Ik gebruik het trouwens wel voor functies en classes, ook om het verschil wat duidelijker te maken. Met je tweede punt ben ik het wel eens en ik gebruik ook vaak i, j, k, etc.

Uit volle borst op weg naar nergens / Zonder reden zonder doel
Met m'n zeden en m'n zonden / En mijn angstig voorgevoel
Laat mij mijn kont tegen de krib / Laat mij dit goddeloze lied
Hef jij je handen maar ten hemel / Maar red mij niet


  • elnino
  • Registratie: Augustus 2001
  • Laatst online: 03-09 05:13
Op woensdag 26 december 2001 02:53 schreef Taradino het volgende:
Er zijn mensen die er anders over denken ja. Ik vind namelijk dat er gewoon veelsteveel whitespace op je scherm komt met een lijn voor elk haakje. Als ik vind dat het niet duidelijk is, dan zet ik zelf wel een whitespace neer(en dat doe ik dan ook wel aardig vaak), maar ik vind het te irritant.
Wat mijn beargumentatie is om een allocade op een nieuwe regel te zetten, heeft te maken met hoe hij bedoeld is.

Een accolade is eigenlijk bedoeld om één commando door meerdere te vervangen, zodat het door de compiler als een groep beschouwd wordt.
code:
1
2
if(expression)
    command;

wordt dus vervangen door:
code:
1
2
3
4
5
if(expression)
{
    command;
    ...
}

Die allocades horen dus niet bij het if-statement, maar bij de code zelf. Daarom vind ik zelf dat ze op een aparte regel horen.

edit: Ik typte allocade ipv accolade |:( ;)

Verwijderd

Op dinsdag 25 december 2001 23:49 schreef MikeN het volgende:
Wat ik me nog steeds afvraag:

Voor mysql tabellen en kolomnamen gebruik ik nu bijvoorbeeld:

table users

user_id
user_name
user_email

maar eigenlijk is dat user dan een beetje dubbelop, maar maakt het wel weer duidelijker.... wat vinden jullie nou, moet dat user_ er nou bij of niet?
ik heb een tabel article, en daarin heb ik als prefix gewoon de letter 'a' genomen, dus bvb

aid
aName
aDate
...

Ik heb ook wel een tabel author, maar dan neem ik gewoon au.

Ik vind het logisch, en kort...


Ander vraagje: ik heb dus bvb drie files article.php, author.php en category.php. Daarmee wordt contenet uit de db gehaald en ge-output.
Maar in de admin area moeten ook files bestaan om die zaken te editten. Is het dan "slecht" om deze admin files ook article.php, enzo te noemen, ook al staan ze in een andere dir?

  • chem
  • Registratie: Oktober 2000
  • Laatst online: 27-08 13:53

chem

Reist de wereld rond

Op woensdag 26 december 2001 02:53 schreef Taradino het volgende:

[..]

Met je tweede punt ben ik het wel eens en ik gebruik ook vaak i, j, k, etc.
i, j, k zijn juist ook weer heel duidelijk. Iedereen weet dat 'i' een teller is...

Klaar voor een nieuwe uitdaging.


  • brammetje
  • Registratie: Oktober 2000
  • Laatst online: 12-01-2025
Op woensdag 26 december 2001 12:07 schreef elnino het volgende:
een beetje lang stuk om te quoten
hmmz, interressant, allocades, waren het geen accolades? ;)

Op zich heb je wel gelijk, maar ik ben het met Taradino eens. Het geeft teveel whitespaces in je code. Zelf gebruik ik altijd if (expression) { en altijd function functie() {. Ik vind het maar lastig lezen als je die accolade op een eigen regel zet. Verder gebruik ik die eerste vorm die je gebruikt eigenlijk nooit. Zo hoort er bij een if() of een function() altijd een { en is dat ook weer duidelijk :)

  • Johannes
  • Registratie: Juni 2000
  • Laatst online: 14-09 23:09
Op woensdag 26 december 2001 12:07 schreef elnino het volgende:
<knip>
Ik vind sowieso niet dat de accolades niet bij het if-statement horen, aangezien het gewoon tekens zijn om aan te geven dat een bepaald blok code onder dat if-statement valt.
Ook al zou het wel zo zijn, dan vind ik het nog steeds duidelijker om toch mijn stijl te gebruiken. Ik vind het namelijk ook nog irritant lezen, met zoveel whitespace. Teveel whitespace is ook niet goed.

Uit volle borst op weg naar nergens / Zonder reden zonder doel
Met m'n zeden en m'n zonden / En mijn angstig voorgevoel
Laat mij mijn kont tegen de krib / Laat mij dit goddeloze lied
Hef jij je handen maar ten hemel / Maar red mij niet


Verwijderd

Hmm, ik weet niet of het mogelijk is om met php mooie code te schrijven ;) javascript regelt >:)

Maar ook voor PHP heb je toch wel een format-progje?

  • Johannes
  • Registratie: Juni 2000
  • Laatst online: 14-09 23:09
Op woensdag 26 december 2001 15:26 schreef Doekman het volgende:
Hmm, ik weet niet of het mogelijk is om met php mooie code te schrijven ;) javascript regelt >:)

Maar ook voor PHP heb je toch wel een format-progje?
Zeker, kijk maar eens naar Beautifier, oorspronkelijk in Perl, maar nu ook in PHP.

Uit volle borst op weg naar nergens / Zonder reden zonder doel
Met m'n zeden en m'n zonden / En mijn angstig voorgevoel
Laat mij mijn kont tegen de krib / Laat mij dit goddeloze lied
Hef jij je handen maar ten hemel / Maar red mij niet


  • elnino
  • Registratie: Augustus 2001
  • Laatst online: 03-09 05:13
Op woensdag 26 december 2001 14:50 schreef Taradino het volgende:
Ik vind sowieso niet dat de accolades niet bij het if-statement horen, aangezien het gewoon tekens zijn om aan te geven dat een bepaald blok code onder dat if-statement valt.
Ook al zou het wel zo zijn, dan vind ik het nog steeds duidelijker om toch mijn stijl te gebruiken.
Laten we het er maar op houden dat iedereen zijn eigen stijl heeft, en dat zelf het duidelijkste vindt. Daarover is het nutteloos om te discussiëren, het wordt dan een welles-nietes-discussie (over verschillende stijlen is het moeilijk om argumenten te geven). Ik houd het gewoon op mijn eigen stijl, want dat vind ik zelf het beste programmeren. Ik vind het wel belangrijk dat er ingesprongen wordt. (En daar zal bijna iedereen het wel met me eens zijn)

Als je meewerkt aan een project is het wel belangrijk dat je de stijl van het project aanhoudt en niet je eigen stijl.

Daarnaast is het belangrijk dat je commentaar erbij zet, maar niet overbodig commentaar, als je bijvoorbeeld $a = $b; hebt, moet je daar niet bij gaan zetten "maak a gelijk aan b", dat kan iedereen wel zien, maar eerder waarom je deze stap doet.

  • D2k
  • Registratie: Januari 2001
  • Laatst online: 31-08 10:19

D2k

Op woensdag 26 december 2001 16:41 schreef elnino het volgende:
Laten we het er maar op houden dat iedereen zijn eigen stijl heeft, en dat zelf het duidelijkste vindt. Daarover is het nutteloos om te discussiëren, het wordt dan een welles-nietes-discussie (over verschillende stijlen is het moeilijk om argumenten te geven).
zie ook hiervoor de linkjes in het al veel genoemde (goh dat iemand dat heeft gelezen ;) )stuk van mij dat onder de faq hangt

Doet iets met Cloud (MS/IBM)


  • elnino
  • Registratie: Augustus 2001
  • Laatst online: 03-09 05:13
Op woensdag 26 december 2001 16:43 schreef D2k het volgende:
zie ook hiervoor de linkjes in het al veel genoemde (goh dat iemand dat heeft gelezen ;) )stuk van mij dat onder de faq hangt
Helaas staat er wel een *klein* foutje in, er wordt namelijk het gebruik van print_r aanbevolen:
PHP:
1
2
3
4
5
<?
echo "<pre>";
print_r("$var");
echo "</pre>";
?>

Hier moeten de quotes weggehaald worden, omdat je een array niet kunt converteren naar een string.

De juiste wijze moet dan zijn:
PHP:
1
2
3
<?
print_r($var);
?>

Daarnaast wordt het gebruik van hoofdletters in variabelen aanbevolen, dus: 'ditIsEenFunctie'. In PHP raadt ik dan toch liever 'dit_is_een_functie' aan, omdat PHP ook in functies als mysql_connect() underscores gebruikt.

  • D2k
  • Registratie: Januari 2001
  • Laatst online: 31-08 10:19

D2k

Op woensdag 26 december 2001 17:03 schreef elnino het volgende:

[..]

Helaas staat er wel een *klein* foutje in, er wordt namelijk het gebruik van print_r aanbevolen:
PHP:
1
2
3
4
5
<?
echo "<pre>";
print_r("$var");
echo "</pre>";
?>
autsj :)
kan gebeuren
zal ff aan acm vragen als tie ooit tijd /zin heeft om het te verbeteren (das nl een hels karwei in een tekstbox en icm topix)
Daarnaast wordt het gebruik van hoofdletters in variabelen aanbevolen, dus: 'ditIsEenFunctie'. In PHP raadt ik dan toch liever 'dit_is_een_functie' aan, omdat PHP ook in functies als mysql_connect() underscores gebruikt.
ach daarover verschillen de meningen :)

Doet iets met Cloud (MS/IBM)


  • elnino
  • Registratie: Augustus 2001
  • Laatst online: 03-09 05:13
Op woensdag 26 december 2001 17:07 schreef D2k het volgende:
autsj :)
kan gebeuren
zal ff aan acm vragen als tie ooit tijd /zin heeft om het te verbeteren (das nl een hels karwei in een tekstbox en icm topix)
Kopieer het gewoon naar een teksteditor (Notepad/KEdit/VI, afhankelijk van het OS), daar bewerken en dan weer terugkopiëren. Tweaken in een tekstbox heeft weinig zin... ;)

  • Johannes
  • Registratie: Juni 2000
  • Laatst online: 14-09 23:09
Op woensdag 26 december 2001 16:41 schreef elnino het volgende:

[..]

Laten we het er maar op houden dat iedereen zijn eigen stijl heeft, en dat zelf het duidelijkste vindt. Daarover is het nutteloos om te discussiëren, het wordt dan een welles-nietes-discussie (over verschillende stijlen is het moeilijk om argumenten te geven). Ik houd het gewoon op mijn eigen stijl, want dat vind ik zelf het beste programmeren. Ik vind het wel belangrijk dat er ingesprongen wordt. (En daar zal bijna iedereen het wel met me eens zijn)

Als je meewerkt aan een project is het wel belangrijk dat je de stijl van het project aanhoudt en niet je eigen stijl.

Daarnaast is het belangrijk dat je commentaar erbij zet, maar niet overbodig commentaar, als je bijvoorbeeld $a = $b; hebt, moet je daar niet bij gaan zetten "maak a gelijk aan b", dat kan iedereen wel zien, maar eerder waarom je deze stap doet.
Hoe maak ik een discussie dood. Part 1 door elnino: :P
zeggen dat iedereen zijn eigen mening heeft.

Maar ik moet zeggen dat je onderste twee punten helemaal kloppen.

Uit volle borst op weg naar nergens / Zonder reden zonder doel
Met m'n zeden en m'n zonden / En mijn angstig voorgevoel
Laat mij mijn kont tegen de krib / Laat mij dit goddeloze lied
Hef jij je handen maar ten hemel / Maar red mij niet


  • .oisyn
  • Registratie: September 2000
  • Laatst online: 00:42

.oisyn

Moderator Devschuur®

Demotivational Speaker

mmmja dat verhaal over die whitespaces... persoonlijk vind ik dat je niet genoeg whitespaces kan hebben. Hoe meer enters je gebruikt, hoe rustiger en makkelijk leesbaarder het overkomt

Als je naar mijn code kijkt dan zie je ook heel veel lege regels erin staan; ik verpak statements die bij elkaar horen in alinea's zeg maar.

Vergelijk nou eens de volgende 2 stukjes code met elkaar
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
bool vgManager::detachClass (vgManagable * managable)
{
    if (managable->manager != this)
        return false;

    managable->manager = NULL;

    if (managable == first)
    {
        first = first->next;
        if (managable == last)
            last = NULL;
    }
    else
    {       
        vgManagable * prev = first;
        for (vgManagable * node = first->next; node; prev = node, node = node->next)
        {
            if (node == managable)
            {
                prev->next = managable->next;
                if (managable == last)
                    last = prev;

                break;
            }
        }

        if (!node)
            return false;
    }

    numClasses--;

    bool empty = pushMessage (vgMsg (BROADCAST, CLASS_ID, MSG_CLASSDETACHED,
        (int)managable->getClassID (), (int)managable));
    
    managable->onDetach (this);

    if (empty)
        emptyQueue ();

    managable->release ();
    
    return true;
}


code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
bool vgManager::detachClass (vgManagable * managable)
{
    if (managable->manager != this)
        return false;
    
    managable->manager = NULL;  
    if (managable == first) {
        first = first->next;
        if (managable == last)
            last = NULL;
    }
    else {      
        vgManagable * prev = first;
        for (vgManagable * node = first->next; node; prev = node, node = node->next) {
            if (node == managable) {
                prev->next = managable->next;
                if (managable == last)
                    last = prev;                
                break;
            }
        }       
        if (!node)
            return false;
    }
    
    numClasses--;   
    bool empty = pushMessage (vgMsg (BROADCAST, CLASS_ID, MSG_CLASSDETACHED,
        (int)managable->getClassID (), (int)managable));    
    managable->onDetach (this); 
    if (empty)
        emptyQueue ();  
    managable->release ();  
    return true;
}

Ik vind het bovenste gedeelte gewoon veeeeel prettiger lezen (ik gebruik overigens tabs = 4, maar of topix of mijn browser (IE 6) maakt er 6 van :))

Okee, misschien is het niet zo aardig voor de mensen die op een resolutie van minder dan 1280x1024 werken, maar dan moeten ze maar een goeie monitor kopen :P (en als je ergens werkt mag je van je baas wel eisen dat ie een degelijke monitor voor je koopt)

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.


  • elnino
  • Registratie: Augustus 2001
  • Laatst online: 03-09 05:13
Op woensdag 26 december 2001 17:45 schreef Taradino het volgende:
Hoe maak ik een discussie dood. Part 1 door elnino: :P
zeggen dat iedereen zijn eigen mening heeft.
:D ;) (misschien een leuke uitspraak in mijn sig ;) )

Nou ja, 't is nou eenmaal zo. De één houdt van een oase van rust, en de ander van alles zo compact mogelijk. Dat is net zoiets dat je sommige muzieksoorten wel mooi vindt en andere weer niet. Zolang je maar consequent blijft.
Op woensdag 26 december 2001 18:32 schreef OiSyN het volgende:
mmmja dat verhaal over die whitespaces... persoonlijk vind ik dat je niet genoeg whitespaces kan hebben. Hoe meer enters je gebruikt, hoe rustiger en makkelijk leesbaarder het overkomt

Als je naar mijn code kijkt dan zie je ook heel veel lege regels erin staan; ik verpak statements die bij elkaar horen in alinea's zeg maar.
Ben ik helemaal mee eens. Doordat de if-statements los van de accolades staan, is het duidelijk en begrijpbaar. Eigenlijk is programmeren net als een boek schrijven: een goede stijl is belangrijk, en die alinea's maken het geheel een stuk duidelijker.
OiSyN vervolgt zijn verhaal:
Okee, misschien is het niet zo aardig voor de mensen die op een resolutie van minder dan 1280x1024 werken, maar dan moeten ze maar een goeie monitor kopen :P (en als je ergens werkt mag je van je baas wel eisen dat ie een degelijke monitor voor je koopt)
Onder 1024x768 ziet het er ook nog goed uit. :)

  • Johannes
  • Registratie: Juni 2000
  • Laatst online: 14-09 23:09
Op woensdag 26 december 2001 22:13 schreef elnino het volgende:

[..]

:D ;) (misschien een leuke uitspraak in mijn sig ;) )

Nou ja, 't is nou eenmaal zo. De één houdt van een oase van rust, en de ander van alles zo compact mogelijk. Dat is net zoiets dat je sommige muzieksoorten wel mooi vindt en andere weer niet. Zolang je maar consequent blijft.
True, true.

Uit volle borst op weg naar nergens / Zonder reden zonder doel
Met m'n zeden en m'n zonden / En mijn angstig voorgevoel
Laat mij mijn kont tegen de krib / Laat mij dit goddeloze lied
Hef jij je handen maar ten hemel / Maar red mij niet


  • cobratbq
  • Registratie: Maart 2001
  • Laatst online: 17-12-2015
Op dinsdag 25 december 2001 20:49 schreef chem het volgende:
kijk hier maar:

http://pear.php.net/manual/standards.php

dat is hoe het ECHT hoort. En 2 of 3 spaties ipv 4 is heel ranzig. Zelf heb ik het liever in tabs, scheelt je een hoop ge-cursor-rechts, maar goed.

Verder is het gebruiken van duidelijke variabelen etc. wel nodig. Ranzige code met $i_1, $i_2 etc. is lelijk en onduidelijk...
Ja ik ook, tabs zijn makkelijker, behalve als je een schrijfprogrammatje hebt wat toch door de tabs heen leest en er vrolijk spaties van maakt. Dan moet je nog flink cursorren :)

One ring to rule them all, one ring to find them, one ring to bring them all, and in darkness bind them...


Verwijderd

mis. hebben julie het niet gezien, was beetje slecht geplaatst mis. Ik wou er gen nieuwe topic voor plaatsen omdat het er een beetje mee te mùaken heeft:
Ander vraagje: ik heb dus bvb drie files article.php, author.php en category.php. Daarmee wordt contenet uit de db gehaald en ge-output.
Maar in de admin area moeten ook files bestaan om die zaken te editten. Is het dan "slecht" om deze admin files ook article.php, enzo te noemen, ook al staan ze in een andere dir?

Verwijderd

Ga eens naar de site van je programma, zoals ww.delphi.com
Staat een mooi stukje over code opmaak :)

  • Johannes
  • Registratie: Juni 2000
  • Laatst online: 14-09 23:09
Op woensdag 26 december 2001 23:24 schreef Jppr het volgende:
mis. hebben julie het niet gezien, was beetje slecht geplaatst mis. Ik wou er gen nieuwe topic voor plaatsen omdat het er een beetje mee te mùaken heeft:

Ander vraagje: ik heb dus bvb drie files article.php, author.php en category.php. Daarmee wordt contenet uit de db gehaald en ge-output.
Maar in de admin area moeten ook files bestaan om die zaken te editten. Is het dan "slecht" om deze admin files ook article.php, enzo te noemen, ook al staan ze in een andere dir?
Slecht? Neuh niet echt, maar ik vind het zelf handig om het dan bijv. edit_article.php, edit_category.php te gebruiken. Dan zie je meteen wat het doet, itt bij de eerste benaming.

Uit volle borst op weg naar nergens / Zonder reden zonder doel
Met m'n zeden en m'n zonden / En mijn angstig voorgevoel
Laat mij mijn kont tegen de krib / Laat mij dit goddeloze lied
Hef jij je handen maar ten hemel / Maar red mij niet


  • elnino
  • Registratie: Augustus 2001
  • Laatst online: 03-09 05:13
Op woensdag 26 december 2001 23:22 schreef cobratbq het volgende:
Ja ik ook, tabs zijn makkelijker, behalve als je een schrijfprogrammatje hebt wat toch door de tabs heen leest en er vrolijk spaties van maakt. Dan moet je nog flink cursorren :)
Heb je het hier toevallig over Quanta Plus? (die werkt nogal vreemd met tabs... ik moet maar eens naar de instellingen gaan kijken)
Op woensdag 26 december 2001 23:42 schreef Taradino het volgende:
Slecht? Neuh niet echt, maar ik vind het zelf handig om het dan bijv. edit_article.php, edit_category.php te gebruiken. Dan zie je meteen wat het doet, itt bij de eerste benaming.
Bij sommige editors zie je niet de dir erbij staan, dus is het altijd handig om het er wel bij te zetten, zodat je wél het verschil tussen article.php en article.php kunt zien.

  • Johannes
  • Registratie: Juni 2000
  • Laatst online: 14-09 23:09
Op donderdag 27 december 2001 00:08 schreef elnino het volgende:

Bij sommige editors zie je niet de dir erbij staan, dus is het altijd handig om het er wel bij te zetten, zodat je wél het verschil tussen article.php en article.php kunt zien.
Da's waar. Maar bij edit_article.php zie je dan toch ook gelijk het verschil?

Koop dan een goede editor. :P

Uit volle borst op weg naar nergens / Zonder reden zonder doel
Met m'n zeden en m'n zonden / En mijn angstig voorgevoel
Laat mij mijn kont tegen de krib / Laat mij dit goddeloze lied
Hef jij je handen maar ten hemel / Maar red mij niet


  • elnino
  • Registratie: Augustus 2001
  • Laatst online: 03-09 05:13
Op donderdag 27 december 2001 00:27 schreef Taradino het volgende:
Da's waar. Maar bij edit_article.php zie je dan toch ook gelijk het verschil?
Daarom liever edit_article.php ipv article.php.
Taradino geeft een tip:
Koop dan een goede editor. :P
Kopen? Wat is dat? :p

(Quanta Plus is een *open-source*-editor voor KDE, ik moet 'm nog even configureren voor tabs, enzo...)

* elnino merkt dat deze discussie erg off-topic wordt...

Maar om even een nieuwe stelling in deze discussie te gooien:

Hoe kun je lange namen het beste aangeven? Met underscores (dit_is_een_lange_naam), of met hoofdletters (ditIsEenLangeNaam)?

Ik vind eigenlijk dat als je zulke lange namen moet gebruiken, je verkeerd bezig bent...

  • Johannes
  • Registratie: Juni 2000
  • Laatst online: 14-09 23:09
Op donderdag 27 december 2001 00:45 schreef elnino het volgende:

[..]

Daarom liever edit_article.php ipv article.php.
Dat zeg ik. :P
Kopen? Wat is dat? :p

(Quanta Plus is een *open-source*-editor voor KDE, ik moet 'm nog even configureren voor tabs, enzo...)

* elnino merkt dat deze discussie erg off-topic wordt...

Maar om even een nieuwe stelling in deze discussie te gooien:

Hoe kun je lange namen het beste aangeven? Met underscores (dit_is_een_lange_naam), of met hoofdletters (ditIsEenLangeNaam)?

Ik vind eigenlijk dat als je zulke lange namen moet gebruiken, je verkeerd bezig bent...
Ik gebruik zelf altijd underscores, ik hou niet zo van die kameelachtige vars. Dan moet ik namelijk ook gaan nadenken over lower/uppercase en als ik underscores gebruik, dan kan ik ook gewoon alleen lowercase in vars gebruiken en alleen uppercase in constanten. Bij zulke lange namen ben je trouwens ook wel verkeerd bezig, maar ook bij vars met twee woorden erin, kan je nog verschillende dingen doen.

Uit volle borst op weg naar nergens / Zonder reden zonder doel
Met m'n zeden en m'n zonden / En mijn angstig voorgevoel
Laat mij mijn kont tegen de krib / Laat mij dit goddeloze lied
Hef jij je handen maar ten hemel / Maar red mij niet


  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

er zijn intussen allerlei coding standaards...

bv..
code:
1
2
3
4
5
6
7
8
  if(a=0) 
  {
     actie1();
  }
  else
  {
     actie2();
  }

Dit gebruikte ik altijd, omdat je nooit een haakje vergeet en heel duidelijk alles kan overzien.

Maar onnodig haakjes gebruik maakt het alleen onoverzichtelijk omdat je minder regels kan overzien. Een enkel statement heeft bij mij geen accolades.
code:
1
2
3
4
if(a=0)
  actie1();
else
  actie2();

Zoals je ziet kun je dit ook uitstekend herkennen.

En de laatste tijd gebruik ik ook dit voor meerdere statements.
code:
1
2
3
4
5
6
7
if(a=0){
  actie1();
  actie1();
}else{
  actie2();
  actie2();
}

Ik vind dit persoonlijk ook erg duidelijk.

Maar het voornaamste van coden is commentaar. Goeie layout is net zo belangrijk als commentaar. Ik geef commentaar bij ieder object en iedere methode, en al onze stagaires die druk ik dit ook op het hart (vooral als je zelf later door heen moet ploegen).
code:
1
2
3
4
5
6
7
8
9
if(computerStuk){ //de computer is stuk
   //kijk of je hem kan fixen  
   geefKlap();
   enNogEen();  
}else{//de computer is niet stuk
   //je kan nu berekeningen uitvoeren.
   gaPiBerekenen();
   gaAnderZinloosWerkDoen();
}

Hierdoor krijg je veel sneller inzicht in je code.

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 00:42

.oisyn

Moderator Devschuur®

Demotivational Speaker

heej alarmnummer, die ifjes van jou gaan niet werken hoor ;)

(ik vind geen spaties gebruiken tussen operators overigens ook niet echt leesbaar... het maakt het zo druk)

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.


  • Killemov
  • Registratie: Januari 2000
  • Laatst online: 11-09 10:38

Killemov

Ik zoek nog een mooi icooi =)

Op woensdag 26 december 2001 12:15 schreef Jppr het volgende:

[..]

ik heb een tabel article, en daarin heb ik als prefix gewoon de letter 'a' genomen, dus bvb

aid
aName
aDate
...

Ik heb ook wel een tabel author, maar dan neem ik gewoon au.

Ik vind het logisch, en kort...


Ander vraagje: ik heb dus bvb drie files article.php, author.php en category.php. Daarmee wordt contenet uit de db gehaald en ge-output.
Maar in de admin area moeten ook files bestaan om die zaken te editten. Is het dan "slecht" om deze admin files ook article.php, enzo te noemen, ook al staan ze in een andere dir?
Gewoon id, name en birthday. In een query met meer tabellen zou je toch user.name gebruiken. date is een keyword en is daarnaast te abstract. De velden moeten zeker wel nuttige namen krijgen.

Hey ... maar dan heb je ook wat!


  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Op donderdag 27 december 2001 01:36 schreef OiSyN het volgende:
heej alarmnummer, die ifjes van jou gaan niet werken hoor ;)

(ik vind geen spaties gebruiken tussen operators overigens ook niet echt leesbaar... het maakt het zo druk)
Ben al blij dat ik de 'then' weer heb weg gehaald :) Ben veel aan het werk met een pascal achtige vandaar de '=' ipv '=='

  • markvt
  • Registratie: Maart 2001
  • Laatst online: 17:17

markvt

Peppi Cola

Op dinsdag 25 december 2001 23:30 schreef elnino het volgende:
Ik ben het persoonlijk niet echt helemaal eens met die PEAR coding-standaard, vooral over:
code:
1
2
3
4
5
6
7
8
// Bron: http://pear.php.net/manual/standards.control.php
if ((condition1) || (condition2)) {
    action1;
} elseif ((condition3) && (condition4)) {
    action2;
} else {
    defaultaction;
}

Ik programmeer zelf altijd zo:
code:
1
2
3
4
5
6
7
8
9
10
11
12
if ((condition1) || (condition2)) 
{
    action1;
} 
elseif ((condition3) && (condition4)) 
{
    action2;
} 
else 
{
    defaultaction;
}

Op die manier komen 'de diepte' en de compounds (het stuk tussen de allocades) het beste naar voren. Deze laatste manier wordt ook in de FAQ gebruikt.
Dit is toch duidelijker ?
code:
1
2
3
4
5
6
7
8
9
10
11
12
if ((condition1) || (condition2)) 
    {
     action1;
    } 
elseif ((condition3) && (condition4)) 
    {
     action2;
    } 
else 
    {
     defaultaction;
    }

van-tilburg.info -=- meka (sega emulator) - Proud MEDION fanclub member - KOPPIG VOLHOUDEN !


  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

vind ik nog onhandiger dan:
code:
1
2
3
4
5
6
7
8
9
10
11
12
if ((condition1) || (condition2)) 
{
    action1;
} 
elseif ((condition3) && (condition4)) 
{
    action2;
} 
else 
{
    defaultaction;
}

En het kost je ook een enorme lading regels.

  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 06-11-2025
code:
1
2
3
4
if( ... )
   {
     ...
   }

Qua logica is er wat voor te zeggen: een statement onder een if, while of for moet inspringen. Een block is een statement, dus moet die ook inspringen :+ .

Maar goed, of het prettig leest, das een ander verhaal :) . Ik was eerder een fel voorstander van deze layout:
code:
1
2
3
4
if( ...)
{
   ...
}

Maar ik ben nu in een andere taal bezig, waar ; een scheidingsteken is tussen statements en dus geen afsluiting. Bovendien zijn daar geen blocks, maar wel veel grote constructoren. Daarom werkt daar dit nu wel prettig:
code:
1
2
3
4
5
where(  
   stm1
;  stm2
;  stm3
)

constructoren worden zo geschreven:
code:
1
2
3
4
5
MethodDeclaration(
    arg1
,   arg2
,   arg2
)

maar goed, das een beetje off-topic want het is een vage taal ;) .

Het belangrijkste lijkt mij:
1. wees consequent, zeer consequent

2. probeer 'alinea's' van code aan te geven

3. zorg dat de nesting op een of andere manier goed zichtbaar is.

4. Maak code niet te 'druk': lange regels, grote lappen voorkomen.

5. Gebruik niet zwaar onnodig veel whitespace

Hoe je dit dan verder realiseert boeit mij niet zoveel :) .

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment


Verwijderd

Op donderdag 27 december 2001 00:45 schreef elnino het volgende:

[..]

Daarom liever edit_article.php ipv article.php.
bedankt iedereen die dit heeft gezegd...
[..]

Maar om even een nieuwe stelling in deze discussie te gooien:

Hoe kun je lange namen het beste aangeven? Met underscores (dit_is_een_lange_naam), of met hoofdletters (ditIsEenLangeNaam)?

Ik vind eigenlijk dat als je zulke lange namen moet gebruiken, je verkeerd bezig bent...
ik gebruik altijd hoofdletters. Erg lange namen gebruik ik ook niet, maar vanaf twee woorden dus, bvb
printPage()
$subcatName
$subcatDescription

enzo

tegelijk een soortgelijke vraag ertussen: gebruiken jullie ook wel "afkortingen" die je consequent gebruikt? Iemand die je code voor het eerst ziet, snapt mis. niet watze betekenen, maar is het daarom minder "net" hoewel het mis. vrij logisch is?

Ik heb het bvb over dit:
PHP:
1
2
3
4
5
<?
$articleQ = "SELECT * FROM article WHERE aid=$aid";
$articleR = mysql_query($articleQ);
$articleA = mysql_fetch_array($articleR);
?>

Hier staat de Q voor query, R voor result en A voor array. Logisch toch? of niet?

  • elnino
  • Registratie: Augustus 2001
  • Laatst online: 03-09 05:13
Op donderdag 27 december 2001 11:51 schreef Jppr het volgende:
tegelijk een soortgelijke vraag ertussen: gebruiken jullie ook wel "afkortingen" die je consequent gebruikt? Iemand die je code voor het eerst ziet, snapt mis. niet watze betekenen, maar is het daarom minder "net" hoewel het mis. vrij logisch is?
:D ;) - over afkortingen gebruiken gesproken...

Het hangt ervan af HOE je ze gebruikt.
Ik heb het bvb over dit:
PHP:
1
2
3
4
5
<?
$articleQ = "SELECT * FROM article WHERE aid=$aid";
$articleR = mysql_query($articleQ);
$articleA = mysql_fetch_array($articleR);
?>

Hier staat de Q voor query, R voor result en A voor array. Logisch toch? of niet?
Ik zou hier toch liever kiezen voor andere namen. Als je deze code snel door zou lezen, zie je niet zo snel het verschil tussen Q, R en A.

Ik gebruik zelf altijd $sqlq ("sqlquery") voor de query, die ik overigens ook altijd op meerdere regels zet, bijvoorbeeld:
code:
1
2
3
$sqlq = "SELECT   *
       FROM     table
       WHERE    blaat";

Zo zie je namelijk het beste hoe een SQL-query opgebouwd is.

Ik gebruik $result voor het resultaat, en vervolgens een naam waar het mee te maken heeft als array-naam, bijv: $user als je het over een user-management-systeem hebt, dan kun je namelijk 'eigenschappen' van die user aanvragen met behulp van $user['email'] etc.

Misschien is die $sqlq niet zo'n goede naam, maar ik denk dat het voor de meeste mensen wel duidelijk is.

  • joepP
  • Registratie: Juni 1999
  • Niet online
Zoals al door velen is gezegd, het gaat om smaak. En over smaak valt te twisten. Zolang je maar consequent bent en je code leesbaar houdt.

Mijn persoonlijke smaak:

1. Naamgeving van variabelen volgens een vaste standaard (i,j,k = integer, S,R = string, etc). Gebruik prefixes voor objecten: slText is dus een TStringList, frmMain is een TForm, etc etc.

2. Duidelijke naamgeving voor functies en parameters.

3. 2 spaties inspringen

4. Code in korte alinea's (max 5/6 regels) groeperen, gescheiden door een witte regel.

5. Boven elke alinea op een aparte regel commentaar over WAT de code doet. In combinatie met colorcoding kan je in 1 oogopslag zien wat de code doet.

6. begin (of { ) op dezelfde regel houden, end (of } ) op een losse regel. Zo houd je je code fatsoenlijke copy/pastable.

7. Geen onnodige begin/end (of {} in c/java) constructies gebruiken.

8. Niet overdreven inspringen, bij een for die alleen een if bevat, de if niet inspringen. Voorbeeld:
code:
1
2
3
4
//move all items of length 5 in slAap to slVijf
For i := 0 to slAap.Count-1 do
if Length(slAap[i]) = 5 then
  slVijf.Add(slAap[i]);

En verder nog wat zaken die ik vergeten ben :)

  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 06-11-2025
7. Geen onnodige begin/end (of {} in c/java) constructies gebruiken.
In veel andere conventies wordt dit juist wel aanbevolen omdat een verkeerde layout in combinatie een vergeten block statement erg bedriegelijk kan zijn. Ik gebruik daarom zelf altijd blocks voor de bodys van for, while en if-constructies.

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment


  • D2k
  • Registratie: Januari 2001
  • Laatst online: 31-08 10:19

D2k

joepP: Zoals al door velen is gezegd, het gaat om smaak. En over smaak valt te twisten.
en dat ga ik ook ff doen ;)
8. Niet overdreven inspringen, bij een for die alleen een if bevat, de if niet inspringen. Voorbeeld:
code:
1
2
3
4
//move all items of length 5 in slAap to slVijf
For i := 0 to slAap.Count-1 do
if Length(slAap[i]) = 5 then
  slVijf.Add(slAap[i]);

En verder nog wat zaken die ik vergeten ben :)
dat vin ik dus onzin
consequent inspringen lijkt me beter

Doet iets met Cloud (MS/IBM)


  • roelio
  • Registratie: Februari 2001
  • Niet online

roelio

fruitig, en fris.

ik doe mee met d2k: conseqeunt inspringen is veel beter, een if meteen onder een for leest gewoon minder prettig. En martin, bij een for statement met maar 1 statement in de lus, vindt je het dan echt nodig om quotes te gebruiken?
Ik bedoel, dat ene statement in de lus kun je ook wel ff inspringen :)

AMD Phenom II X4 // 8 GB DDR2 // SAMSUNG 830 SSD // 840 EVO SSD // Daar is Sinterklaas alweer!!


  • RickN
  • Registratie: December 2001
  • Laatst online: 14-06-2025
Op donderdag 27 december 2001 12:56 schreef mbravenboer het volgende:

[..]

In veel andere conventies wordt dit juist wel aanbevolen omdat een verkeerde layout in combinatie een vergeten block statement erg bedriegelijk kan zijn. Ik gebruik daarom zelf altijd blocks voor de bodys van for, while en if-constructies.
Ja, ik ook.

En zo'n specifieke "stijlbreuk" om bij een if na een for de if niet in te springen maakt de code er (iig voor anderen) veel minder leesbaar op.

[persoonlijk]
Ik zelf moest bijna :r toen ik dat stukje code met die niet ingesprongen if zag.
[/persoonlijk]

Waarom doe je dat zo? Wat is het nut ervan?

He who knows only his own side of the case knows little of that.


  • joepP
  • Registratie: Juni 1999
  • Niet online
Op donderdag 27 december 2001 12:56 schreef mbravenboer het volgende:

[..]

In veel andere conventies wordt dit juist wel aanbevolen omdat een verkeerde layout in combinatie een vergeten block statement erg bedriegelijk kan zijn. Ik gebruik daarom zelf altijd blocks voor de bodys van for, while en if-constructies.
Je hebt idd kans om bij geneste if-statements in de problemen te komen, daar gebruik ik ze dus wel. Maar ik vind het volgende gewoon totaal geen gezicht:
code:
1
2
3
4
5
6
7
if (bla) {
  blabla();
}
else if (bla2) {
  blabla2();
}
else if ...

Doe mij maar:
code:
1
2
3
4
5
if (bla)
  blabla()
else if (bla2)
  blabla2()
else if ...

Maar dat is echt een kwestie van smaak. Zolang je maar consequent bent!

  • D2k
  • Registratie: Januari 2001
  • Laatst online: 31-08 10:19

D2k

Op donderdag 27 december 2001 12:52 schreef joepP het volgende:
8. Niet overdreven inspringen, bij een for die alleen een if bevat, de if niet inspringen. Voorbeeld:
code:
1
2
3
4
//move all items of length 5 in slAap to slVijf
For i := 0 to slAap.Count-1 do
if Length(slAap[i]) = 5 then
  slVijf.Add(slAap[i]);
en
Op donderdag 27 december 2001 13:02 schreef joepP het volgende:
Maar dat is echt een kwestie van smaak. Zolang je maar consequent bent!
dat kan ik ff niet rijmen dan
sorry

Doet iets met Cloud (MS/IBM)


  • RickN
  • Registratie: December 2001
  • Laatst online: 14-06-2025
Op donderdag 27 december 2001 13:00 schreef limoentje het volgende:
ik doe mee met d2k: conseqeunt inspringen is veel beter, een if meteen onder een for leest gewoon minder prettig. En martin, bij een for statement met maar 1 statement in de lus, vindt je het dan echt nodig om quotes te gebruiken?
Ik bedoel, dat ene statement in de lus kun je ook wel ff inspringen :)
Ik zet gewoon altijd begin-end ({}) neer, ongeacht wat er tussen komt. Als ik aan het proggen ben en ik weet dat er een if-then-else statement gaat komen dan tik ik gewoon al meteen:
code:
1
2
3
4
5
if then
begin
end
else begin
end;

Dit is een paar seconden werk en ondertussen kun je vast nadenken over wat er tussen moet komen :)

In C heb ik overigens een iets andere conventie, nl:
code:
1
2
3
4
5
6
if ()
{
}
else
{
}

Ik denk dat dat komt omdat ik een begin meteen onder een else (met verder niets op die 2 regels) lelijk vindt. Tja, het oog wil ook wat...

He who knows only his own side of the case knows little of that.


  • joepP
  • Registratie: Juni 1999
  • Niet online
Op donderdag 27 december 2001 13:01 schreef RickN het volgende:
En zo'n specifieke "stijlbreuk" om bij een if na een for de if niet in te springen maakt de code er (iig voor anderen) veel minder leesbaar op.

[persoonlijk]
Ik zelf moest bijna :r toen ik dat stukje code met die niet ingesprongen if zag.
[/persoonlijk]

Waarom doe je dat zo? Wat is het nut ervan?
Het nut? Kvind het mooier :)

Xal het nog even toelichten.. Ik programmeer al 13 jaar, en mijn stijl is steeds veranderd. Deze keuze heeft zich langzaam ontwikkeld. Het begon met het volgende stukje code in GWBASIC:
code:
1
2
3
4
5
10 FOR x = 1 TO 10
20   FOR y = 1 TO 10
30     blabla
40   NEXT
50 NEXT

Aangezien de y-loop gelijkwaardig is aan de x-loop (ze kunnen ook andersom gezet worden) wilde ik eigenlijk 1 statement voor beide loops. Maar dat kan niet. Om de gelijkheid aan te geven sprong ik dus niet meer in:
code:
1
2
3
4
5
10 FOR x = 1 TO 10
20 FOR y = 1 TO 10
30     blabla
40 NEXT
50 NEXT

Hier valt over te twisten, maar dit vond ik veel mooier en duidelijker. En het scheelt 2 spaties. Omdat ik lui ben, ben ik het ook gaan toepassen bij for-loops met een enkele if erin. Het inspringen voegt daar ook niets toe.

Maar ik kan me voorstellen dat je ervan moet :r, ik moest er zelf ook flink aan wennen ;)

Tot slot van deze post nog ff een voorbeeldje waarom ik geen onnodige begin/end constructies wil zien in mijn code:
code:
1
2
3
4
//move all items of length 5 in slAap to slVijf
For i := 0 to slAap.Count-1 do
if Length(slAap[i]) = 5 then
  slVijf.Add(slAap[i]);

Is toch 1000x mooier (in mijn ogen :) ) dan:
code:
1
2
3
4
5
6
//move all items of length 5 in slAap to slVijf
For i := 0 to slAap.Count-1 do begin
  if Length(slAap[i]) = 5 then begin
    slVijf.Add(slAap[i]);
  end;
end;

Plus dat het 20 karakters korter is! :)

  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 06-11-2025
joepP: Je hebt idd kans om bij geneste if-statements in de problemen te komen, daar gebruik ik ze dus wel.
Het probleem is niet zozeer geneste ifs (alhoewel die ook een probleem zijn) maar 'zwevende' statements:
code:
1
2
for( .... )
     statement1;

later bedenk je dat er nog ff wat moet gebeuren:
code:
1
2
3
for( .... )
     statement1;
     statement2;

Auw, dat klopt dus niet in een taal die layout niet meeneemt. Heel vervelend dus en heel erg lastig te vinden *D . Hetzelfde probleem heb je ook bij ifs en whiles uiteraard.

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment


  • joepP
  • Registratie: Juni 1999
  • Niet online
Nog ff iets over het begrip 'leesbaarheid'...

Ik weet niet hoe jullie code 'lezen', maar ik maak gebruik van een editor met color-coding. Dat betekent dat commentaar zeer snel te spotten is. Als ik mijn eigen code moet lezen, lees ik alleen het commentaar boven elke alinea (= 5/6 regels code). Ik ga pas 'echte' code lezen als dat nodig is.

  • Johannes
  • Registratie: Juni 2000
  • Laatst online: 14-09 23:09
Op donderdag 27 december 2001 13:00 schreef limoentje het volgende:
ik doe mee met d2k: conseqeunt inspringen is veel beter, een if meteen onder een for leest gewoon minder prettig. En martin, bij een for statement met maar 1 statement in de lus, vindt je het dan echt nodig om quotes te gebruiken?
Ik bedoel, dat ene statement in de lus kun je ook wel ff inspringen :)
Ja, dat is zeker nodig. Misschien wil je later nog wel 's een statement toevoegen aan dat if-blokje, en dan kan je weer makkelijk vergeten dat je geen {} er om heen hebt staan. En nog een voordeel is dat als je { gebruikt, m'n editor automatisch inspringt, dus dat scheelt één tab, waardoor je maar één extra teken hoeft in te tikken voor veel extra duidelijkheid. :)

Edit Martin was me voor. ;(

Uit volle borst op weg naar nergens / Zonder reden zonder doel
Met m'n zeden en m'n zonden / En mijn angstig voorgevoel
Laat mij mijn kont tegen de krib / Laat mij dit goddeloze lied
Hef jij je handen maar ten hemel / Maar red mij niet


  • joepP
  • Registratie: Juni 1999
  • Niet online
Op donderdag 27 december 2001 13:13 schreef mbravenboer het volgende:

[..]

Het probleem is niet zozeer geneste ifs (alhoewel die ook een probleem zijn) maar 'zwevende' statements:
code:
1
2
for( .... )
     statement1;

later bedenk je dat er nog ff wat moet gebeuren:
code:
1
2
3
for( .... )
     statement1;
     statement2;

Auw, dat klopt dus niet in een taal die layout niet meeneemt. Heel vervelend dus en heel erg lastig te vinden *D . Hetzelfde probleem heb je ook bij ifs en whiles uiteraard.
Dus? Ik zie echt zelf wel of ik een begin/end moet toevoegen, daar heb ik nog nooit een fout mee gemaakt. Voor beginners geldt je argument, maar dat ben ik niet.

* joepP vind overbodige begin/end statement gewoon fies! ;)

  • Johannes
  • Registratie: Juni 2000
  • Laatst online: 14-09 23:09
Op donderdag 27 december 2001 13:18 schreef joepP het volgende:
Nog ff iets over het begrip 'leesbaarheid'...

Ik weet niet hoe jullie code 'lezen', maar ik maak gebruik van een editor met color-coding. Dat betekent dat commentaar zeer snel te spotten is. Als ik mijn eigen code moet lezen, lees ik alleen het commentaar boven elke alinea (= 5/6 regels code). Ik ga pas 'echte' code lezen als dat nodig is.
Ik denk dat iedere zichzelf respecterende coder een editor met syntax highlighting heeft. Zonder werken gaat gewoon veel en veel langzamer. Ik zet meestal als comments bovenaan in een bestand wat het (zou moeten :P ) doen, en bij sommige vars waarvoor ze gebruikt worden, als dat niet meteen duidelijk is door de naam. Als ik met moeilijkere dingen bezig bven dan komen er wel altijd veel comments in te staan hoe en waarom iets gebeurt, maar als ik gewoon simpele PHP scriptjes aan het kloppen ben, dan komen er meestal maar heel weinig comments, omdat ze toch heel makkelijk te lezen. Ik doe dus eigenlijk het tegenovergestelde van 'If code was hard to write, it should be hard to understand.'(oid?), nl. hoe moeilijker de code, hoe meer comments ik neer zet.

Uit volle borst op weg naar nergens / Zonder reden zonder doel
Met m'n zeden en m'n zonden / En mijn angstig voorgevoel
Laat mij mijn kont tegen de krib / Laat mij dit goddeloze lied
Hef jij je handen maar ten hemel / Maar red mij niet


  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 06-11-2025
joepP: Dus? Ik zie echt zelf wel of ik een begin/end moet toevoegen, daar heb ik nog nooit een fout mee gemaakt. Voor beginners geldt je argument, maar dat ben ik niet.
Een ervaren programmeur vertrouwt zichzelf en zeker zijn mede-programmeurs niet :+ .

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment


  • joepP
  • Registratie: Juni 1999
  • Niet online
Op donderdag 27 december 2001 13:28 schreef Taradino het volgende:

[..]

Ik denk dat iedere zichzelf respecterende coder een editor met syntax highlighting heeft. Zonder werken gaat gewoon veel en veel langzamer. Ik zet meestal als comments bovenaan in een bestand wat het (zou moeten :P ) doen, en bij sommige vars waarvoor ze gebruikt worden, als dat niet meteen duidelijk is door de naam. Als ik met moeilijkere dingen bezig bven dan komen er wel altijd veel comments in te staan hoe en waarom iets gebeurt, maar als ik gewoon simpele PHP scriptjes aan het kloppen ben, dan komen er meestal maar heel weinig comments, omdat ze toch heel makkelijk te lezen. Ik doe dus eigenlijk het tegenovergestelde van 'If code was hard to write, it should be hard to understand.'(oid?), nl. hoe moeilijker de code, hoe meer comments ik neer zet.
Zo dacht ik er vroeger ook over..

Maar als je na 2 jaar je php-scriptje van 200 regels bekijkt, is het allemaal niet meer zo superlogisch. Met commentaar boven elk blokje kan je 'comment-skimmen', en dat leest 100x sneller dan de echte code te moeten ontcijferen. Je bent tenslotte een mens, en die zijn beter in het lezen van tekst dan van code. Zelfs als je programmeur bent.

Ik schrijf tijdens het coden altijd EERST mijn commentaarregeltje, en dan pas het blokje code. Voor beginners is dit een perfecte training, aangezien je gedwongen wordt na te denken voor je wat doet.

  • chem
  • Registratie: Oktober 2000
  • Laatst online: 27-08 13:53

chem

Reist de wereld rond

Op woensdag 26 december 2001 17:07 schreef D2k het volgende:

[..]

autsj :)
kan gebeuren
zal ff aan acm vragen als tie ooit tijd /zin heeft om het te verbeteren (das nl een hels karwei in een tekstbox en icm topix)
al gedaan ;)

Klaar voor een nieuwe uitdaging.


  • D2k
  • Registratie: Januari 2001
  • Laatst online: 31-08 10:19

D2k

Op donderdag 27 december 2001 13:38 schreef chem het volgende:

[..]

al gedaan ;)
tnx

voor joepP: je leest wel consequent over mijn replys heen. Hoe komt dat toch?

Doet iets met Cloud (MS/IBM)


  • joepP
  • Registratie: Juni 1999
  • Niet online
Op donderdag 27 december 2001 13:06 schreef D2k het volgende:

8. Niet overdreven inspringen, bij een for die alleen een if bevat, de if niet inspringen. Voorbeeld:

en

... Zolang je maar consequent bent!

dat kan ik ff niet rijmen dan
sorry
Met 'consequent' bedoel ik dat je je aan je eigen regels moet houden. En dat doe ik dus ook. Dat jij mijn regels onderling niet consequent vind, tsja, da's niet mijn probleem ;)

  • D2k
  • Registratie: Januari 2001
  • Laatst online: 31-08 10:19

D2k

Op donderdag 27 december 2001 13:46 schreef joepP het volgende:
Met 'consequent' bedoel ik dat je je aan je eigen regels moet houden. En dat doe ik dus ook. Dat jij mijn regels onderling niet consequent vind, tsja, da's niet mijn probleem ;)
dus toch inconsequent ;)
maar goed, ik volg je wel maar ben het er niet mee eens. Maar dat hoeft ook niet gelukkig :) .

Doet iets met Cloud (MS/IBM)


  • elnino
  • Registratie: Augustus 2001
  • Laatst online: 03-09 05:13
Op donderdag 27 december 2001 13:13 schreef mbravenboer het volgende:
Auw, dat klopt dus niet in een taal die layout niet meeneemt. Heel vervelend dus en heel erg lastig te vinden *D . Hetzelfde probleem heb je ook bij ifs en whiles uiteraard.
Ik ben het volledig met mbravenboer eens. Het is ook makkelijker, want stel je wilt later nog wat code toevoegen, dan hoef je er niet op te letten of er al {} staan. Maar goed inspringen is ook belangrijk.

Laatst kwam ik ook nog wat :r tegen van phpBB (een veelgebruikt php-forum): (een klein fragment uit install.php)
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
<?
if($next) {
   switch($next) {
    case 'database':
      if(!$done) {
     echo "Testing DB Connection...";
     flush();
     if(!$db = mysql_connect("$dbserver", "$dbuser", "$dbpass"))
       die("<font color=\"#FF0000\">Error, I could not connect to the database at $dbserver.");
     echo "<font color=\"#00FF00\">DB Connection Good!</FONT><BR>";
     flush();
     echo "Selected database $dbname...";
     flush();
     if(!@mysql_select_db("$dbname", $db)) {
        echo "<font color=\"#FF0000\">Database could not be found</font><BR>";
        flush();
        echo "Attempting to create database $dbname...";
        flush();
        if(!$r = mysql_query("CREATE DATABASE $dbname", $db))
          die("<font color=\"#FF0000\">Error, count not select or create database $dbname.");
        mysql_select_db("$dbname", $db);
        echo "<font color=\"#00FF00\">Database Created!</font><BR>";
        flush();
     }
?>

Dit is nou echt een voorbeeld van hoe je niet moet programmeren. (Je ziet nauwelijks wat bij wat hoort)

  • Johannes
  • Registratie: Juni 2000
  • Laatst online: 14-09 23:09
Op donderdag 27 december 2001 14:59 schreef elnino het volgende:

Laatst kwam ik ook nog wat :r tegen van phpBB (een veelgebruikt php-forum): (een klein fragment uit install.php)

<knip>

Dit is nou echt een voorbeeld van hoe je niet moet programmeren. (Je ziet nauwelijks wat bij wat hoort)
Je hebt zeker naar phpBB 1.* gekeken? Het was toen nogal een zooitje in de code daar, maar als je naar de code van v2 kijkt, blijkt dat ze zich al heel wat beter gedragen:
Install.php

Ze hadden dan ook deze keer coding standards afgesproken terwijl dit(volgens mij) bij versie 1 nog helemaal niet werd gedaan en iedereend dus maar aanklooide.

Uit volle borst op weg naar nergens / Zonder reden zonder doel
Met m'n zeden en m'n zonden / En mijn angstig voorgevoel
Laat mij mijn kont tegen de krib / Laat mij dit goddeloze lied
Hef jij je handen maar ten hemel / Maar red mij niet


  • Mithrandir
  • Registratie: Januari 2001
  • Laatst online: 14-09 20:56
Op donderdag 27 december 2001 14:59 schreef elnino het volgende:

[..]

Ik ben het volledig met mbravenboer eens. Het is ook makkelijker, want stel je wilt later nog wat code toevoegen, dan hoef je er niet op te letten of er al {} staan. Maar goed inspringen is ook belangrijk.

Laatst kwam ik ook nog wat :r tegen van phpBB (een veelgebruikt php-forum): (een klein fragment uit install.php)
[code]

Dit is nou echt een voorbeeld van hoe je niet moet programmeren. (Je ziet nauwelijks wat bij wat hoort)
Oei! onleesbaar!

Das echt erg. Toen ik de eerste 3 regels had bekeken stopte ik al, want 't is echt niet om aan te zien.

Verbouwing


  • .oisyn
  • Registratie: September 2000
  • Laatst online: 00:42

.oisyn

Moderator Devschuur®

Demotivational Speaker

Op donderdag 27 december 2001 19:37 schreef DinoRaptor het volgende:

[..]

Oei! onleesbaar!

Das echt erg. Toen ik de eerste 3 regels had bekeken stopte ik al, want 't is echt niet om aan te zien.
welke slechte code :?


oh wacht ik snap het al, ik had de laat-onleesbare-code-niet-zien-optie van mijn monitor aan staan :P

en dan ben ik wel eens aan het coden, en dan staat er na een uur nog steeds niets op mijn beeldscherm :+

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.


  • Johannes
  • Registratie: Juni 2000
  • Laatst online: 14-09 23:09
Op donderdag 27 december 2001 19:52 schreef OiSyN het volgende:

[..]

welke slechte code :?


oh wacht ik snap het al, ik had de laat-onleesbare-code-niet-zien-optie van mijn monitor aan staan :P

en dan ben ik wel eens aan het coden, en dan staat er na een uur nog steeds niets op mijn beeldscherm :+
:D :P :D

Uit volle borst op weg naar nergens / Zonder reden zonder doel
Met m'n zeden en m'n zonden / En mijn angstig voorgevoel
Laat mij mijn kont tegen de krib / Laat mij dit goddeloze lied
Hef jij je handen maar ten hemel / Maar red mij niet


  • elnino
  • Registratie: Augustus 2001
  • Laatst online: 03-09 05:13
Op donderdag 27 december 2001 19:52 schreef OiSyN het volgende:
en dan ben ik wel eens aan het coden, en dan staat er na een uur nog steeds niets op mijn beeldscherm :+
:D - Tip: zet je beeldscherm aan ;)

Sommige mensen hebben inderdaad niet door dat je naar rechts moet inspringen. :+

Maar met die nieuwe phpBB Coding Standard ben ik het wel mee eens, behalve dan met het gedeelte over ... ? ... : ..., ik vind persoonlijk dat je die dingen gewoon nooit moet gebruiken, dan kan je het ook niet fout doen. Een if/else-statement is dan wel langer, maar dan wel 100 keer duidelijker.
Pagina: 1 2 Laatste