Goede code opmaak

woensdag 26 december 2001 23:22

Op woensdag 26 december 2001 22:13 schreef elnino het volgende:

[..]

(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

Acties:

cobratbq

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...

woensdag 26 december 2001 23:24

Acties:

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?

woensdag 26 december 2001 23:24

Acties:

Verwijderd

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

woensdag 26 december 2001 23:42

Acties:

donderdag 27 december 2001 00:08

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

Acties:

donderdag 27 december 2001 00:27

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.

Acties:

donderdag 27 december 2001 00:45

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.}

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

Acties:

donderdag 27 december 2001 00:51

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.}

Kopen? Wat is dat?

(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...

Acties:

donderdag 27 december 2001 01:05

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

[..]

Daarom liever edit_article.php ipv article.php.

Dat zeg ik.

Kopen? Wat is dat?

(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

Acties:

Alarmnummer

-= Tja =-

er zijn intussen allerlei coding standaards...

bv..

code:

  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:

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:

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:

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.

donderdag 27 december 2001 01:36

Acties:

donderdag 27 december 2001 01:46

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.

Acties:

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!

donderdag 27 december 2001 01:49

Acties:

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 '=='

donderdag 27 december 2001 10:15

Acties:

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:

if ((condition1) || (condition2)) 
    {
     action1;
    } 
elseif ((condition3) && (condition4)) 
    {
     action2;
    } 
else 
    {
     defaultaction;
    }

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

donderdag 27 december 2001 11:36

Acties:

Alarmnummer

-= Tja =-

vind ik nog onhandiger dan:

code:

if ((condition1) || (condition2)) 
{
    action1;
} 
elseif ((condition3) && (condition4)) 
{
    action2;
} 
else 
{
    defaultaction;
}

En het kost je ook een enorme lading regels.

donderdag 27 december 2001 11:45

Acties:

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

code:

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:

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:

where(  
   stm1
;  stm2
;  stm3
)

constructoren worden zo geschreven:

code:

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

.

donderdag 27 december 2001 11:51

Acties:

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:

<?
$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?

donderdag 27 december 2001 12:08

Acties:

donderdag 27 december 2001 12:52

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?

- 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.

Acties:

donderdag 27 december 2001 12:56

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:

//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

Acties:

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

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.

donderdag 27 december 2001 12:57

Acties:

donderdag 27 december 2001 13:00

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)

Acties:

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!!

donderdag 27 december 2001 13:01

Acties:

RickN

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

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.

donderdag 27 december 2001 13:02

Acties:

donderdag 27 december 2001 13:06

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:

if (bla) {
  blabla();
}
else if (bla2) {
  blabla2();
}
else if ...

Doe mij maar:

code:

if (bla)
  blabla()
else if (bla2)
  blabla2()
else if ...

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

Acties:

donderdag 27 december 2001 13:08

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)

Acties:

RickN

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:

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:

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.

donderdag 27 december 2001 13:13

Acties:

donderdag 27 december 2001 13:13

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 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:

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:

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

, 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:

//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:

//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!

Acties:

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

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

. Hetzelfde probleem heb je ook bij ifs en whiles uiteraard.

donderdag 27 december 2001 13:18

Acties:

donderdag 27 december 2001 13:19

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.

Acties:

donderdag 27 december 2001 13:23

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

Acties:

donderdag 27 december 2001 13:28

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 . 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!

Acties:

donderdag 27 december 2001 13:30

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

) 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

Acties:

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

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

.

donderdag 27 december 2001 13:36

Acties:

donderdag 27 december 2001 13:38

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 ) 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.

Acties:

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.

donderdag 27 december 2001 13:40

Acties:

donderdag 27 december 2001 13:46

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)

Acties:

donderdag 27 december 2001 13:49

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

Acties:

donderdag 27 december 2001 14:59

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)

Acties:

donderdag 27 december 2001 15:51

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 . 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

tegen van phpBB (een veelgebruikt php-forum): (een klein fragment uit install.php)

PHP:

<?
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)

Acties:

donderdag 27 december 2001 19:37

Op donderdag 27 december 2001 14:59 schreef elnino het volgende:

Laatst kwam ik ook nog wat 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

Acties:

Mithrandir

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 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

donderdag 27 december 2001 19:52

Acties:

donderdag 27 december 2001 20:19

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

^{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.

Acties:

donderdag 27 december 2001 23:19

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

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

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

Acties:

donderdag 27 december 2001 23:30

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}

- 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.

Acties:

marcusk

Op donderdag 27 december 2001 23:19 schreef elnino het volgende:
over ... ? ... : ..., ik vind persoonlijk dat je die dingen gewoon nooit moet gebruiken

dat heb ik hier wel vaker zien langskomen als 'evil language construct'. maar wat is er nou mis mee?

donderdag 27 december 2001 23:33

Acties:

Verwijderd

Op donderdag 27 december 2001 23:30 schreef marcusk het volgende:

[..]

dat heb ik hier wel vaker zien langskomen als 'evil language construct'. maar wat is er nou mis mee?

het is geen "nette" code, ofmdat je geen duidelijk overzicht hebt hoe het zit, over een vraagteken en een dubbele punt lees je snel heen.

Daarbij komt ook dat je maar een statement kan plaatsen, en als er eentje bij komt, je plots toch een hele if moet maken.

donderdag 27 december 2001 23:59

Acties:

vrijdag 28 december 2001 00:06

Op donderdag 27 december 2001 23:33 schreef Jppr het volgende:
het is geen "nette" code, ofmdat je geen duidelijk overzicht hebt hoe het zit, over een vraagteken en een dubbele punt lees je snel heen.

Daarbij komt ook dat je maar een statement kan plaatsen, en als er eentje bij komt, je plots toch een hele if moet maken.

Vooral met debuggen kun je daar snel overheen lezen. Misschien zijn er wel situaties waar het wel overzichtelijk gebruikt kan worden, maar een if statement blijft gewoon beter en vooral duidelijker.

Daarnaast zijn er nog een paar dingen die een programmeur zoveel mogelijk moet ontwijken:

Goto - dit maakt van je code een zooitje, en het voordeel van 'hogere programmeertalen' t.o.v. ASM is dat je for/while/do-lussen hebt, waarbij je Goto dus niet nodig hebt. Gelukkig kent PHP geen Goto...
Global variabelen - De argumenten en de 'return' van een functie zijn bedoeld om waardes af te geven, niet willekeurige variabelen. Anders krijg je tijdens het debuggen zoiets van: "Hé waarom is die variabele i 10 i.p.v. 3?".
In PHP raadt ik het sowieso aan om van de variabelen $REMOTE_HOST enzo eerst constanten te maken, die zijn namelijk wel overal beschikbaar, en bovendien die kunnen niet van waarde veranderen, dus onverwachte effecten zijn er ook niet.

Acties:

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

Het is jammer dat niet meer talen een degelijke syntax hebben voor een if constructie als expressie. Die ? ... : ... zuigt uiteraard

.

Er is in feite geen enkele reden waarom de gewone if syntax niet ook als expressie zou kunnen worden gebruikt...

vrijdag 28 december 2001 00:10

Acties:

Nielsz

Op vrijdag 28 december 2001 00:06 schreef mbravenboer het volgende:
Het is jammer dat niet meer talen een degelijke syntax hebben voor een if constructie als expressie. Die ? ... : ... zuigt uiteraard .

Er is in feite geen enkele reden waarom de gewone if syntax niet ook als expressie zou kunnen worden gebruikt...

Yep die heb ik nog nooit gebruikt. Zeer onleesbaar

vrijdag 28 december 2001 00:15

Acties:

Bergen

Spellingscontroleur

ach wat... dit leest toch veel prettiger:

code:

#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <time.h>
#define e(t, v, w) n t(u x, u y) { n a = sqrt(x+y); r ((v - a) * (w - a)); }
#define w while(
#define r return
typedef char u; typedef short q; typedef double n;
u *z = "Z\253\345\252\256\351\325\232\265f\256\246nyZf\253U^\266\232]z\352i\236\226i[m\266\351\252\255\246\235V\247e\235\226\276Z\371jUg\x3\362\212pX\254\251PH\253\332\225\373\235\b\v\336HO.\203Qf\201\x1d\207\211\357\367S7|)=\331n\x4!E<\233Z\246\x1flv\232d(r\263\274\375\313\305\200\361\302\327\274\375\300\201c\250-|\246]\304\253I\377W\227R^\251\350\x2""C\251\203\311O\346\242\vDh\r\357\306x\325\274\315\366c\th\325\272\376\311X+:\325\354q\263|\257\x1c\327\316g\204\266s\211\357\370A(\x11""D\321\x1d:\352\327\x1bk@\x11""E-\310s\271\235\304\273\x2+\x4I\274jT\256\363\214\307{\232a\3270\a+qm\270\aI\315\337\220\x17\x18\315G\217\371@\215\335\v[v\335\205\343\250-|\246\373:\225\f\2552Oe]\206U\272\355\x10\327)u\rY]\276>\243\333w{3\x19\v""acC8\3775\351\b\377\204lJnsy.:\330\2553rKx'\362'!%\302\271\376|\236skq\242C\251\263&\x15K\x4""fA\227\211\242r7]\371\333\200z%\277\207CJ\255^}\264\237\327\275Z\n;L\x1aN#\371N\354G\256skq\242K!\364\211E\214\x17\377\343z\340w\233\272\354eTD\262t\365\335[_\233\225J\313\2746\334\x3\b\244F&\240]\222\332\210\351\376rJs<\2265I;\203Xd\272\377\345\214\x17\263]2I\237\302\253\346\355\332\343\350G\327\"\350f}\301n\223\366\300\210\343j\247\316%\363\210\345\n\252\215c\255\314\3248\300\261\350RM7\203\261\371\265\r_\220\x17\x19\a(+u\x1d=I\235\314\331@\310Cl\x16\210\307\345\357\306\x1f""e\345R\354y\257\367\350!.\x1f`\345uW&\204\246\367>\226\335\205\353\x18\336;\302\334\266\213Fn\233\201vAE\325+qnVR\222e\237E<e\203!f\333\345[\x17#\205\273I\314\371n\340\304\205\225h\323\336\371\x1c""7\227\201%\327\201p\326\263\351f\x19\a\v\336;uI\312?\214\265I1$\302+\373\233v\336\x5\306,y\313OD\351d*\350f\357H\262]\x3\332l\365L\237Qs\320{\231\244\204d\352v\335\215\327\357\200\247\302W\x10", x, y;
n g() { r (n)rand()/18972; } n t, v; q F, B, C; e(a, 0, 3.0) e(b, 3.0, 4.125) 
e(c, 4.125, 9) u f(n (*h)()) { do { t=g() * 6.283184; v = sqrt(g() * 72); y = 
sin(t) * v; x=cos(t)*v; } w (h(x*x,y*y)>=0)||(fabs(x) > 5) || (fabs(y) > 5));
r ((y+5) * 11) + x + 7; } u k(q x, u l) { u o = 0; F = 0; w F < 189) { B =C =
0; w 1) { y = ((z[F/4]>>((F++%4)*2))&3) - 1; if (y&2) 
break; C = (C*2)+y, ++B; } if (!(C - x | B - l)) r (o<26)?o+0x61:((2108973>>(
(o-26)*8))&47); ++o; } r 1; } u s[1079]; u *E(u v) { u *x = s; w v--)w *(x++)
); r x; } main() { q A = 0, B = 0, C = 1078; u l = 0; u *p = s; srand(time( 0
) ); w C) { A = (A*2) + ((((z[B/8+48]+114)^2)>>(7-(B++%8)))&1),++l; x = k(A,l
); if (x-1) { *(p++)=x, A=l=0, C--; } } printf("%s%s %s%s%s\n", E(0), E(f(c))
, E(f(a)), E(1), E(f(b))); }

Komt van http://www.ioccc.org, The International Obfuscated C Code Contest: echt werkende code die er niet uit ziet

Als je bovenin op Winning Entries klikt kom je bij de prachtige inzendingen.

vrijdag 28 december 2001 00:26

Acties:

vrijdag 28 december 2001 00:34

I think we should take a look.

Op donderdag 27 december 2001 23:30 schreef marcusk het volgende:
dat heb ik hier wel vaker zien langskomen als 'evil language construct'. maar wat is er nou mis mee?

Dat snap ik dus ook niet. Ik vind zo'n constructie ideaal vooral als het om iets gaan als
boolwaarde ? 1 : 2
of zo. Helemaal als het een argument voor een functie is.
Hoofdregel blijft wel dat het leesbaar moet zijn. Ik heb ze wel gezien dat er na de ? een lap code kwam, en daarna nog ergens een : met ook een lap erachteraan. Da's gewoon crap natuurlijk...
(de VB versie is Iif() en die gebruik ik erg vaak voor kleine dingen, maar zodra het iets meer als 1 waarde, maar ik er een gewone if van)

Exact expert nodig?

Acties:

vrijdag 28 december 2001 01:18

Op vrijdag 28 december 2001 00:26 schreef Crazy_D het volgende:
Dat snap ik dus ook niet. Ik vind zo'n constructie ideaal vooral als het om iets gaan als
boolwaarde ? 1 : 2
of zo. Helemaal als het een argument voor een functie is.
Hoofdregel blijft wel dat het leesbaar moet zijn. Ik heb ze wel gezien dat er na de ? een lap code kwam, en daarna nog ergens een : met ook een lap erachteraan. Da's gewoon crap natuurlijk...
(de VB versie is Iif() en die gebruik ik erg vaak voor kleine dingen, maar zodra het iets meer als 1 waarde, maar ik er een gewone if van)

Het is gewoon lastiger bij debuggen enzo. Het maakt code soms gewoon onoverzichtelijk, en zeker voor anderen. Als je alleen aan een project werkt, dan moet je het zelf weten, maar als je met anderen werkt, liever niet. En aangezien ik liever consequent ben dan niet consequent, gebruik ik dus alleen if, het liefst met accolades {} erbij, kan er nooit wat fout gaan...

Acties:

vrijdag 28 december 2001 01:27

I think we should take a look.

Op vrijdag 28 december 2001 00:34 schreef elnino het volgende:
Het is gewoon lastiger bij debuggen enzo. Het maakt code soms gewoon onoverzichtelijk, en zeker voor anderen.

Tjah misschien is dat wat je gewend bent. Bij m'n eerste echte baantje als programmeur moest ik door een hoop code heen wroten waarin het vrij veel gebruikt werd (vooral in de situatie waarin ik noemde) en daar had ik nooit problemen mee eigenlijk. Ik kan me ook niet herinneren ooit een bug gecreëert te hebben daardoor (wel genoeg andere trouwens

).
Maar ja ik vind het geen onmisbaar iets, dus als ze het eruit zouden slopen of zo zal ik 't niet missen...

Exact expert nodig?

Acties:

marcusk

Ik heb er ook nooit problemen mee gehad, maar ik gebruik het ook nooit genest binnen statements ofzo, alleen bij toewijzingen:

a = ( blaat ? 1 : 2 );

Dit vind ik ook niet onleesbaar, en kan me niet voorstellen dat iemand hier overheen leest

vrijdag 28 december 2001 01:53

Acties:

vrijdag 28 december 2001 01:58

Moderator Devschuur®

Demotivational Speaker

ja maar juist bij die statement kun je net zo goed zeggen

code:

if (blaat)
    a = 1;
else
    a = 2;

bij dit wordt het wat anders:

code:

1	functie ((blaat1) ? 1 : 0, (blaat2) ? 2 : 1);

dat zou je moeten vertalen naar zoiets:

code:

if (blaat1)
    p1 = 1;
else
    p1 = 0;

if (blaat2)
    p2 = 2;
else
    p2 = 1;

functie (p1, p2);

wat nogal een hoop regels code produceert, en ook nog eens 2 extra variabelen

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

Acties:

marcusk

Op vrijdag 28 december 2001 01:53 schreef OiSyN het volgende:
ja maar juist bij die statement kun je net zo goed zeggen
code:
1
2
3
4
if (blaat)
    a = 1;
else
    a = 2;

is anders wel 4x zo weinig regels

bij dit wordt het wat anders:

dat zou ik eerder zo doen:

code:

int p1 = ( blaat1 ? 1 : 0 );
int p2 = ( blaat2 ? 2 : 1 );

functie(p1, p2);

vrijdag 28 december 2001 02:09

Acties:

vrijdag 28 december 2001 11:28

Moderator Devschuur®

Demotivational Speaker

wat ik bedoelde te zeggen is dat het voorbeeld van jou kwa door de compiler gegenereerde code totaal niets uitmaakt als je het vervangt met een if statement, terwijl het bij mijn statement juist wel uitmaakt

Ik bedenk me overigens ineens een voorbeeld waarbij je wel gebruik moet maken van de ?: operator: bij base-class en member initialisatie in de constructor

code:

class Base
{
private:
    int i;

public:
    Base (int i) : i (i)
    {
    }
};

class Derived : public Base
{
public:
    Derived (bool blaat) : Base ((blaat) ? 10  : 20)
    {
    }
};

hier kun je gewoon geen if gebruiken

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

Acties:

Verwijderd

Goede code opmaak:

PHP:

<?
function gablaten($iets)
{
     if($iets=="dat")
     {
          return "Dit";
     }
     else
     {
          return "Dat";
     }
}
?>

Qua layout heb ik niets op aan te merken, maar de kleuren zijn hopeloos. Groen op paars en rood op paars hebben gewoon te weinig contrast om goed leesbaar te zijn. En het lettertype zou ook wat groter mogen. De huidige kleuren zijn goed geschikt voor een witte achtergrond, niet voor paars.

vrijdag 28 december 2001 11:44

Acties:

vrijdag 28 december 2001 13:00

I think we should take a look.

Op vrijdag 28 december 2001 11:28 schreef Thargol het volgende:
De huidige kleuren zijn goed geschikt voor een witte achtergrond, niet voor paars.

Hoeveel mensen hebben nou een paarse achtergrond in hun favoriete edittor

(maar ik ben het met je eens, alleen staat het denk ik zo stom als de code-blokken een witte achtergrond krijgen)

Exact expert nodig?

Acties:

vrijdag 28 december 2001 13:30

Op vrijdag 28 december 2001 02:09 schreef OiSyN het volgende:
hier kun je gewoon geen if gebruiken

Als het niet kan, dan kan het gewoon niet, maar ik blijf van mening dat je, als je if efficiënt kunt gebruiken, if moet gebruiken.

Op vrijdag 28 december 2001 11:28 schreef Thargol het volgende:
Qua layout heb ik niets op aan te merken, maar de kleuren zijn hopeloos. Groen op paars en rood op paars hebben gewoon te weinig contrast om goed leesbaar te zijn. En het lettertype zou ook wat groter mogen. De huidige kleuren zijn goed geschikt voor een witte achtergrond, niet voor paars.

Kleurtjes op GoT maken mij niet zoveel uit. Zolang ze maar wel goed in mijn editor staan. Over de grote en dergelijke van PHP op GoT zijn al meerdere discussies geweest, waar het om een sleutelwoord ging:

Topix.

Acties:

vrijdag 28 december 2001 13:40

swiekie swoeng

...en doen we in HTML dan ook keurig inspringen na een <td>? Als in:

code:

<table cellpadding="0" cellspacing="0" border="0">
  <tr>
    <td>
    Bla<br>
    Wop<br>
    koeien<br>
    </td>
  </tr>
</table>

al vele conflicten over gehad.

"Passing silhouettes of strange illuminated mannequins"

Acties:

vrijdag 28 december 2001 13:45

Op vrijdag 28 december 2001 13:30 schreef klokop het volgende:
...en doen we in HTML dan ook keurig inspringen na een <td>? Als in:

Als het goed zou werken in HTML, zou het ideaal zijn. Maar er zijn situaties waar een spatie niet gewenst is. Denk maar aan plaatjes waarbij absolute positionering gebruikt wordt. Dus doe de <td></td> gewoon op een regel, als het niet anders kan.

Acties:

vrijdag 28 december 2001 13:56

swiekie swoeng

Lijkt me duidelijk.
Conflicten gingen meestal over tabellen in tabellen dus zo:

code:

<table cellpadding="0" cellspacing="0" border="0">
  <tr>
    <td>
    <table cellpadding="0" cellspacing="0" border="0">
      <tr>
        <td>
        Bla<br>
        Wop<br>
        Koeien<br>
        </td>
        <td>[img]"http://217.17.139.168/ads/sites/Maczine/maczine.gif"[/img]</td>
        <td>irritante banners</td>
      </tr>
    </table>
    </td>
  </tr>
</table>

"Passing silhouettes of strange illuminated mannequins"

Acties:

vrijdag 28 december 2001 14:00

swiekie swoeng

Dat is dus gewoon niet leesbaar.

"Passing silhouettes of strange illuminated mannequins"

Acties:

Verwijderd

Op vrijdag 28 december 2001 13:56 schreef klokop het volgende:
Dat is dus gewoon niet leesbaar.

waarom moet iets dat binnen hetzelfde blok (de <td>'s) hoort inspringen?

tekst begint toch ook aan de kantlijn. de td's zijn in dit geval de kantlijn

vrijdag 28 december 2001 14:07

Acties:

Verwijderd

Op vrijdag 28 december 2001 11:28 schreef Thargol het volgende:

[..]

Qua layout heb ik niets op aan te merken, maar de kleuren zijn hopeloos. Groen op paars en rood op paars hebben gewoon te weinig contrast om goed leesbaar te zijn. En het lettertype zou ook wat groter mogen. De huidige kleuren zijn goed geschikt voor een witte achtergrond, niet voor paars.

die kleuren kiezen wij zelf niet, die worden door het forum hier gemaakt met syntax highlighting. (highlight_string() voor wie het zich afvraagt: http://www.php.net/manual/en/function.highlight-string.php)

vrijdag 28 december 2001 14:12

Acties:

vrijdag 28 december 2001 14:15

Op vrijdag 28 december 2001 14:07 schreef Jppr het volgende:

[..]

die kleuren kiezen wij zelf niet, die worden door het forum hier gemaakt met syntax highlighting. (highlight_string() voor wie het zich afvraagt: http://www.php.net/manual/en/function.highlight-string.php)

Maar dit is één van de weinige dingen die ACM/Kees wel zouden kunnen veranderen. De kleuren staan namelijk gewoon in je php config file, en je kan ze ook aanpassen. Idee?

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

Acties:

Verwijderd

<td>
Bla 
Wop 
Koeien 
</td>

Het probleem van inspringen na een <td> is dat het omgewenste effecten kan veroorzaken. Een enter of een newline worden in HTML gezien als whitespace. Dus "<td>[enter]Bla" is dus anders als "<td>Bla", maar weer hetzelfde als "<td> Bla". Met name in Netscape 4.x krijg je hiermee vaak ongewenste layout effecten.

vrijdag 28 december 2001 14:18

Acties:

Verwijderd

Op vrijdag 28 december 2001 14:12 schreef Taradino het volgende:

[..]

Maar dit is één van de weinige dingen die ACM/Kees wel zouden kunnen veranderen. De kleuren staan namelijk gewoon in je php config file, en je kan ze ook aanpassen. Idee?

ok, ze kunnen het aanpassen, maar is dat zo nodig? Als we mooie (en duidelijke!) kleuren kunnen overeen komen kunnen we het eens lief vragen, maar dan blijft het de vraag of iemand het er wil in zetten...

vrijdag 28 december 2001 14:23

Acties:

farlane

Op vrijdag 28 december 2001 01:53 schreef OiSyN iets over die mooie operator

De problemen gaan ontstaan als je ?: gaat gebruiken voor de bijwerkingen die je ermee kunt krijgen (door het conditionele aspect van de operator).

Als je 'em als 'normale' operator gebruikt, is het echt een zeer duidelijke instructie. Op die plaatsen is een if...else.. niet duidelijker. Sterker nog, als je veel VB leest met al die

code:

If blaat Then 
    foo=blabla 
Else
    foo=blablabla
EndIf

zou je willen dat VB ook zo'n operator had. Scheelt 10% code.

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.

vrijdag 28 december 2001 14:29

Acties:

vrijdag 28 december 2001 14:56

swiekie swoeng

Dus "<td>[enter]Bla" is dus anders als "<td>Bla", maar weer hetzelfde als "<td> Bla". Met name in Netscape 4.x krijg je hiermee vaak ongewenste layout effecten.

Stuur eens een voorbeeldje??? Ga ik er met netscape naar kijken. Thnx

"Passing silhouettes of strange illuminated mannequins"

Acties:

Verwijderd

code:

<td>
Bla<br>
Wop<br>
Koeien<br>
</td>

Als we het toch over nette code hebben moet dat niet zijn:

code:

<td>
Bla<br />
Wop<br />
Koeien<br />
</td>

Deze week heb ik dat op w3c gelezen. Elke Tag moet gesloten worden is de aanbeveling.

code:

1 2	dus: <br></br> geeft een extra witte regel gebruikt moet worden <br /> <p> -> <p />

enuwh natuurlijk:

code:

1
2
3

<b><i>blaat</b></i>
moet zijn:
<b><i>blaat</i></b>

Ik heb nog wat te verbeteren op mijn pagina's

vrijdag 28 december 2001 14:59

Acties:

Verwijderd

Op vrijdag 28 december 2001 14:56 schreef X-Fire het volgende:

[...]
Als we het toch over nette code hebben moet dat niet zijn:
code:
1
2
3
4
5
<td>
Bla 
Wop 
Koeien 
</td>
Deze week heb ik dat op w3c gelezen. Elke Tag moet gesloten worden is de aanbeveling.
[...]

Is dat niet enkel voor XHTML valid pages enzo. XML ook, maar niet voor plain HTML, toch?

vrijdag 28 december 2001 15:07

Acties:

vrijdag 28 december 2001 15:10

swiekie swoeng

Maar dan natuurlijk:

code:

<td>
  Bla<br />
  Wop<br />
  Koeien<br />
</td>

"Passing silhouettes of strange illuminated mannequins"

Acties:

Verwijderd

Op vrijdag 28 december 2001 15:07 schreef klokop het volgende:
Maar dan natuurlijk:
code:
1
2
3
4
5
<td>
 Bla 
 Wop 
 Koeien 
</td>

nee. voor HTML gewoon

code:

<td>
Bla<br>
Wop<br>
Koeien<br>
</td>

en voor xhtml

code:

<td>
Bla<br />
Wop<br />
Koeien<br />
</td>

vrijdag 28 december 2001 15:13

Acties:

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

Sorry maar ik moet ff gapen

.

Dit gaat nergens meer over!

vrijdag 28 december 2001 15:21

Acties:

vrijdag 28 december 2001 15:23

I think we should take a look.

Op vrijdag 28 december 2001 14:23 schreef farlane het volgende:
zou je willen dat VB ook zo'n operator had. Scheelt 10% code.

Hmm die heb je. Iif(voorwaarde, truewaarde, falsewaarde)

En voor html...
Als het werkt probeer ik wel altijd netjes te laten inspringen als in

code:

<table>
    <tr>
      <td>
        blah blah
      </td>
    </tr>
</table>

Maar soms kort ik dat ook wel af tot:

code:

<table>
    <tr>
      <td>blah blah</td>
    </tr>
</table>

Is een klein beetje afhankelijk van wat er moet komen te staan, en of het de layout niet verziekt. Het 1e vind ik wel duidelijker, maar als het tegenzit zit je 4 pagina's door te scrollen om het einde van de table te vinden, en dan vind ik de <td> en </td> op dezelfde regel zetten weer wat makkelijker. Maar belangrijkste vind ik dat als je de html code bekijkt, het gewoon duidelijk is wat er staat. De <td> zet ik ook nog weleens recht onder de table, zeker als je dan nog een table binnen de table krijgt, zit je eerst 20 keer te tabben voordat je de tekst kan plaatsen, en daar vind ik het dan niet echt duidelijker van worden...

Exact expert nodig?

Acties:

Verwijderd

Op vrijdag 28 december 2001 15:13 schreef mbravenboer het volgende:
Sorry maar ik moet ff gapen .

Dit gaat nergens meer over!

ow...

vrijdag 28 december 2001 15:27

Acties:

vrijdag 28 december 2001 15:34

swiekie swoeng

Op vrijdag 28 december 2001 15:13 schreef mbravenboer het volgende:
Sorry maar ik moet ff gapen .

Dit gaat nergens meer over!

nou jaaaaaaaaa

"Passing silhouettes of strange illuminated mannequins"

Acties:

Verwijderd

/me zucht.

In deze vrolijke heilige oorlog betreffende de god 1TBS zal ik ook maar een waargebeurd (

) religieus verhaaltje posten; hier komtie:

Op een dag liep de Meester door het klooster, waar de leerlingen in hun cellen in meditatieve code-oefeningen verzonken waren. De aandacht van de Meester werd getrokken door de kreten van wanhoop die uit een van de cellen weerklonken en de contemplatieve rust in het klooster ruw verstoorden. De Meester naderde de cel waar deze wanklanken hun oorzaak vonden en aldaar aangekomen spiedde Hij door het sleutelgat. Zo werd de Meester er getuige van hoe de leerling Wu Li in tranen zich de haren uit het hoofd trok en daarbij de voornoemde bloedstollende kreten slaakte.

De Meester wachtte geduldig voor de cel en stuurde de leerlingen die hun hoofden uit de celdeuren staken en deels door de kloostergang toegesneld kwamen terug naar hun lessen en meditaties. Onderwijl sloeg hij de leerling Wu Li regelmatig gade door het sleutelgat. Toen Wu Li's haar tot de laatste pluk van zijn hoofd verdwenen was, klopte de Meester aan en trad de cel binnen.

De leerling Wu Li keek op en werd ondanks zijn tranen de Meester gewaar. Hij kreette: "Meester, Meester, oh help mij! Al Uw proeven heb ik doorstaan, al Uw lessen heb ik geleerd, maar Uw Laatste Proef heeft mij met verwarring en wanhoop geslagen!".
De Meester sprak: "Wat heeft Uwen Geest alzo verduisterd dat Gij Uzelve de haardracht enes Meesters toedient?".
"Meester," sprak Wu Li, "ondanks dat ik de Heilige Leer der Indentering tot op de letter volg, de Ene Ware Stijl aanbidt en mijne Werken rijkelijk van diepzinnige Commentariëen voorzie, blijft het Grote Plan achter Uw Laatste Proef mij verborgen!". "Onmogelijk is het mij, deze Opgave in het Licht van Uw Leer te zien!", zo sprak Wu Li.
De Meester sprak: "Vertel mij, Wu Li, welks Uwes Laatsten Proeve zijde zou?".
"De Universele Zelfgelijkzaamheid en het Kosmische Zelfverwantschap en hun onverbrekelijke band met de Wet van Verdeel en Heers waren het die mij verblindden, oh Meester. Uwe proeve der Torens van Hanoi is teveel voor mij!", zo antwoordde Wu Li.

Dit horende ontstak de Meester in grote vreugde. Hij nam de handgeschreven, ledergebonden kopie van de Heilige K.R. Bijbel die hij altijd aan een koord gebonden aan Zijn zijde meedroeg ter hand en sloeg de verbijserde Wu Li er recht mee op het onlangs kaal geworden voorhoofd zodat de klap door het hele klooster te horen was. Toen Wu Li weer bij zinnen was en op de grond zittend zijn buil betastte sprak de Meester: "Zo geindenteerd was Uw hoofd door Heilige Wetten, dat Uw Geest erdoor belemmerd werd. U behoefde node een exdentatie!". Dit horende werd Wu Li de Verlichting ten deel.

[sup]Copyright 2001 by /me :P[/sup]

vrijdag 28 december 2001 15:36

Acties:

vrijdag 28 december 2001 15:46

swiekie swoeng

zooo, en er kan weer een topic dicht...

"Passing silhouettes of strange illuminated mannequins"

Acties:

vrijdag 28 december 2001 17:24

Op vrijdag 28 december 2001 15:34 schreef mietje een lang verhaal:
...
Toen Wu Li weer bij zinnen was en op de grond zittend zijn buil betastte sprak de Meester: "Zo geindenteerd was Uw hoofd door Heilige Wetten, dat Uw Geest erdoor belemmerd werd. U behoefde node een exdentatie!". Dit horende werd Wu Li de Verlichting ten deel.
^{Copyrighted 2001 by /me}

En ze leefden nog lang en gelukkig...

Geef mij maar de Allman-style.

Op vrijdag 28 december 2001 15:13 moest mbravenboer gapen:
Sorry maar ik moet ff gapen .

Dit gaat nergens meer over!

Idd, de topicstarter is alang geholpen, en de discussie over de {} ?: is inmiddels al gevoerd, en die dwaalt nu af naar inspringen in HTML/XML/XHTML.

edit: Toevoeging en copyright van mietje toegevoegd

Acties:

packman

Ik vindt ook dat een mooie code opmaak zeer belangrijk is, en je moet inderdaad gewoon concequent zijn. Wat ook heel belangrijk is dat je voor een project waar je met meerdere personen aan werkt daarover ook een duidelijke afspraak hebt. Toch zijn er bepaalde dingen in praktijk bijna onbruikbaar of onleesbaar die hier getoond zijn.

code:

if ((condition1) || (condition2))
{
    action1;
}
else if ((condition3) && (condition4))
{
    action2;
}
else
{
    defaultaction;
}

is hier een voorbeeld van. Zier er mooi uit als je het alleen ziet staan, maar hier verlies je zo even 7 regels op een stomme if-else if-else conditie. De hoeveelheid code die je tegelijkertijd op je scherm kan zien is ook zeer belangrijk volgens mij. Dan is dit toch de betere code:

code:

if ((condition1) || (condition2)) {
    // Doe iets;
} else if ((condition3) && (condition4)) {
    // Doe iets anders;
} else {
    // Doe nog iets anders;
}

Je moet er ook zoveel mogelijk voor zorgen dat alle condities zo duidelijk mogelijk zijn, zo duidelijk dat ze eigenlijk geen commentaar nodig hebben. Inline commentaar kan dingen ook serieus onduidelijk maken, en moet zoveel mogelijk vermeden worden, enkel in echt tricky constructies waarvan je zelf vind dat je later er niet meer aan uit gaat geraken is dit nuttig.
Te veel commentaar zetten is trouwens ook moeilijker om later bugs te vinden. Je ziet er gewoon over als je bij elke conditie bijzet wat ze doet (of zou moeten doen). Op dat ogenblik moet je je aandacht erbij houden, en niet precies een verhaaltje zijn dat je leest. Ik heb zo ooit (java)code moeten debuggen - en dat was te vergelijken met cobol (

)

If's zonder accolades vind ik enkel toegestaan indien er geen else achter komt, en de code die uitgevoerd moet worden moet op de volgende regel 1 tab geindenteerd zijn.

Een tabwidth van kleiner dan 4 is totaal uit den boze. Als je dan buiten je scherm gaat heb je dringend een cursus softwaredesign nodig. Gebruik dan functies. Ikzelf gebruik voor java een tabwidth van 4 en voor C een van 8. Een regel van langer dan 80 karakters is ook niet mooi - en is vanzelf al onleesbaar.

Nog iets waar ik een grondige hekel aan heb is het inline declareren van variabelen. De meeste talen staan dat nu toe - maar dat maakt ook alles lekker ingewikkeld en onleesbaar. Declareer variabelen altijd in het begin van een block ( na de { ). Bij PHP heb je hier geen last van natuurlijk...

I heard if you play the XP CD backwards, you get a satanic message. Thats nothing compared to what happens if you play it forward, then it installs Windows XP born2oc.be - Facts Of Life

vrijdag 28 december 2001 17:44

Acties:

zaterdag 29 december 2001 16:39

Moderator Devschuur®

Demotivational Speaker

als we dan toch verhaaltjes gaan vertellen...

novice asked the Master: "Here is a programmer that never designs, documents, or tests his programs. Yet all who know him consider him one of the best programmers in the world. Why is this?"

The Master replies: "That programmer has mastered the Tao. He has gone beyond the need for design; he does not become angry when the system crashes, but accepts the universe without concern. He has gone beyond the need for documentation; he no longer cares if anyone else sees his code. He has gone beyond the need for testing; each of his programs are perfect within themselves, serene and elegant, their purpose self-evident. Truly, he has entered the mystery of the Tao."

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

Acties:

farlane

Op vrijdag 28 december 2001 15:21 schreef Crazy_D het volgende:

Hmm die heb je. Iif(voorwaarde, truewaarde, falsewaarde)

Is dat een VB operator?

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.

zaterdag 29 december 2001 16:51

Acties:

zaterdag 29 december 2001 16:54

Moderator Devschuur®

Demotivational Speaker

Op zaterdag 29 december 2001 16:39 schreef farlane het volgende:

[..]

Is dat een VB operator?

nee het is gewoon een functie

zo van (en dan moet ik even mijn VB-kennis weer optrommelen)

code:

Function Iif (exp as Boolean, vTrue as Variant, vFalse as Variant) as Variant

    If exp Then
      Iif = vTrue
    Else
      Iif = vFalse

Exit Function

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

Acties:

zaterdag 29 december 2001 17:12

I think we should take a look.

Op zaterdag 29 december 2001 16:39 schreef farlane het volgende:
Is dat een VB operator?

Yup.

MSDN:

IIf Function

Returns one of two parts, depending on the evaluation of an expression.

Syntax

IIf(expr, truepart, falsepart)

The IIf function syntax has these named arguments:

Part Description
expr Required. Expression you want to evaluate.
truepart Required. Value or expression returned if expr is True.
falsepart Required. Value or expression returned if expr is False.

Remarks

IIf always evaluates both truepart and falsepart, even though it returns only one of them. Because of this, you should watch for undesirable side effects. For example, if evaluating falsepart results in a division by zero error, an error occurs even if expr is True.

Helaas is het Remarks stukje (dus) ook waar, en dat vind ik wel erg spijtig... (of dat in VB.net beter is weet ik eigenlijk niet, heb 'm hier niet geinstalleerd staan).

[edit]
In Excel zit 'ie volgens mij ook, alleen in asp (vbscript) weer niet (iig niet in mijn vbscript engine (5.1 of 5.5)). En misschien zit ie er pas sinds VB6 in, ook dat weet ik niet zeker

(goh ik weet eigenlijk ook niks

)

Exact expert nodig?

Acties:

zaterdag 29 december 2001 17:32

Moderator Devschuur®

Demotivational Speaker

Op zaterdag 29 december 2001 16:54 schreef Crazy_D het volgende:

Helaas is het Remarks stukje (dus) ook waar, en dat vind ik wel erg spijtig... (of dat in VB.net beter is weet ik eigenlijk niet, heb 'm hier niet geinstalleerd staan).

Das natuurlijk ook logisch, omdat het gewoon een functie is die een parameter teruggeeft als ie true geeft, en een andere parameter teruggeeft als ie false is. Aangezien de expressies voor die parameters worden uitgerekend voordat de functie wordt aangeroepen (om vervolgens de uitkomst aan de functie te geven), zit je dus altijd met dat probleem.

Wat je eigenlijk nodig hebt is een echte operator zoals in C++, wat deel uitmaakt van de taal-syntax zelf, en niet gewoon een support routine is

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

Acties:

Verwijderd

nog even hierover:

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.

om de article bvb volledig te kunnen adminnen moet ik er kunnen toevoegen, verwijderen en editten.

Wat is dan netter?

* drie files: add_article.php, edit_article en rem_article ofzo

* 1 file: admin_article.php waarin de drie functies onderscheiden worden door bvb een var $func ofzo...

zondag 30 december 2001 01:57

Acties:

zondag 30 december 2001 13:05

Op zaterdag 29 december 2001 17:32 schreef Jppr het volgende:
nog even hierover:
[..]

om de article bvb volledig te kunnen adminnen moet ik er kunnen toevoegen, verwijderen en editten.

Wat is dan netter?

* drie files: add_article.php, edit_article en rem_article ofzo

* 1 file: admin_article.php waarin de drie functies onderscheiden worden door bvb een var $func ofzo...

Ik maak zelf niet te veel verschillende files, optie 2 dus. Als je maar één file maakt, dan kan je namelijk vaak heel wat code hergebruiken, terwijl je bij drie files vaak dezelfde code in drie bestanden hebt staan. Als je die weer moet veranderen, kan je er drie veranderen en dat is wel wat minder.

Meestal zet ik alle gewoon alle admin bestanden in een aparte directory, maak dan een bestand admin.php aan. Hier in loop ik alle files langs, waarin ik een korte beschrijving van de pagina + categorie gedefinieerd heb. Die dump ik dan in een frame, gesorteerd op categorie en beschrijving. Hierdoor kan ik heel erg makkelijk nieuwe admin modules toevoegen.

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

Acties:

Verwijderd

het gaat niet meer echt over nette code, maar heeft er toch nog iets mee te maken:

standaard hebben we als url bvb
.../article.php?aid=17

nu kun je er vrij makkelijk van maken:
.../article/17

nu, wat vinden jullie pers. mooier/professioneler/...

zondag 30 december 2001 13:12

Acties:

whoami

Op zondag 30 december 2001 13:05 schreef Jppr het volgende:
het gaat niet meer echt over nette code, maar heeft er toch nog iets mee te maken:

standaard hebben we als url bvb
.../article.php?aid=17

nu kun je er vrij makkelijk van maken:
.../article/17

nu, wat vinden jullie pers. mooier/professioneler/...

Volgens mij zijn beiden niet goed. Het article-id mag je nl niet kunnen afleiden uit de url.

https://fgheysels.github.io/

zondag 30 december 2001 13:12

Acties:

Verwijderd

Op zondag 30 december 2001 13:12 schreef whoami het volgende:

[..]

Volgens mij zijn beiden niet goed. Het article-id mag je nl niet kunnen afleiden uit de url.

waarom niet? wat zou jij anders als link nemen?

zondag 30 december 2001 13:43

Acties: