[/14] [ PHP, C, C++, JAVA, etc] Nette code

[D2k]

Debuggen in PHP

Veel topics in /14 gaan over phpcode die errors geeft danwel niet werkt.
Hoe los je dit het snelste op?

Bouw je query's als volgt

PHP:

<?
$connect = mysql_connect($server,$usersql,$passwd)or die("Bad connect string: ".mysql_error());
mysql_select_db("$dbnaam",$connect)or die("Bad database change: ".mysql_error());

$sql222 = "SELECT * FROM blaat where id='$id'"; 
$q222 = mysql_query($sql222,$connect) or die(mysql_error());
?>

op deze wijze kan je dus dmv van een echo "$sql222"; de waarden van je query bekijken.
En dus direct zien of je wel de juiste dingen in je query hebt. In dit geval of id wel bestaat oid.

Code dus ook overzichtelijk.
Bekijk het verschil tussen de 2 onderstaande voorbeelden
• 1

PHP:

<?
if($blaatwat){
echo "blaat";
}else{
echo "niet blaat";}
?>

• 2

PHP:

<?
if($blaatwat)
{
    echo "blaat";
}
else    
{
    echo "niet blaat";
}
?>

zo krijg je dus geen (nou jah minder) fouten met haakjes.
En nee ik gebruik er niet te veel want dit zijn simpele voorbeeldjes

Verder kan je het beste

PHP:

<?
echo "<pre>";
print_r("$var");
echo "</pre>";
?>

gebruiken bij variabelen waar je aan twijfelt,
en dan in het bijzonder bij array's natuurlijk.

(zpel en tiepvautte voorbehauwe)

gaarne vragen opmerkingen kritiek via deze thread
D2k & ACM

[razor-x]

Handig hoor
Maar dit zal echt niet betekenen dat je nu minder topics krijgt ben ik bang

[D2k]

Op dinsdag 28 augustus 2001 19:45 schreef razor-x het volgende:
Handig hoor
Maar dit zal echt niet betekenen dat je nu minder topics krijgt ben ik bang

dat is ook niet zo erg
maar ik hoop dat er dan meer naar de eigen code wordt gekeken voor hier om hulp wordt geschreeuwd

[razor-x]

Op dinsdag 28 augustus 2001 19:46 schreef D2k het volgende:

[..]

dat is ook niet zo erg
maar ik hoop dat er dan meer naar de eigen code wordt gekeken voor hier om hulp wordt geschreeuwd

Maak hem sticky zou ik zeggen

[D2k]

Op dinsdag 28 augustus 2001 19:49 schreef razor-x het volgende:

[..]

Maak hem sticky zou ik zeggen

eerst moeten er nog opmerkingen/kritieken komen over mijn stukje
en die komen er vast wel

[razor-x]

Op dinsdag 28 augustus 2001 19:52 schreef D2k het volgende:

[..]

eerst moeten er nog opmerkingen/kritieken komen over mijn stukje
en die komen er vast wel

vooral kritiek

naja mijn bijdragen : (wat mij vaak overkomt)

PHP:

<?
if ($blaat)
{
       echo "Blaat";
}
else
} // kijk goed !!
       echo "niet blaat";
}
?>

als je goed kijkt zie je dat ik een haakje verkeertom heb gezet
dit is een fout die ik soms wel eens maak en dan word ik helemaal gek omdat ik het probleem niet kan vinden,
let daar dus ook op

edit:
Er is een hoog mario-icoon gehalte volgens mij

[Tim]

grootste deel van de debug vragen zijn hier simpel te oplossen door het vertalen van de foutmelding, en het gebruiken van een goede syntax-highlighting..

Het is zowiezo een goed idee om je code netjes te schrijven, in jouw geval schrijf ik meestal

PHP:

<?
if ($iets) // doe iets
else //doe iets
?>

dat vind ik zelf fijn, maar andere weer niet, heeft een beetje met smaak te maken..

Verder hebben PHP en MySQL prima foutmeldingen:
ERROR: Parse error on line 14
staat er neit voor niks, en je zou dus kunnen beginnen met zoeken op lijn 14, en langzaam omhoog werken..
meestal is dit gewoon het vergeten van een haakje..
Daarvoor is het inspringen zo belangrijk (standaard is 4 spaties geloof ik, maar een tab of 4 spaties word ook veel gebruikt)

ERROR: Supplied argument is not a valid MySQL result resource
betekend dat je iets fout doet met je query, zorg dat zo'n error word afgevangen..

PHP heeft prachtige ERROR handeling functies, kijk bevoorbeeld eens naar
error_reporting
set_error_handler

En voor mySQL fouten:
mysql_error

Als je dan na 30x kijken toch nog neit hebt gevonden wat de fout is en je het toch op GoT post, doe dat dan iig duidelijk.
Post het stukje code (dus niet de complete 62Kb) met de foutmelding, tussen php tags en GEEF AAN IN WELKE REGEL de fout zit.. Als iemand post dat er in regel 102 een fout zit, ga ik geen 102 regels tellen, en het schiet helemaal niet op als alleen regel 94 t/m 125 er staat..

[Bart Coppens]

Duidelijke variabelenamen kunnen ook helpen (had ik in het begin last mee ), zodat je ze moelijk kan omdraaien.

PHP:

<?
$connect = mysql_connect($server,$usersql,$passwd)or die("Bad connect string: ".mysql_error());
mysql_select_db("$dbnaam",$connect)or die("Bad database change: ".mysql_error());
$query = "SELECT * FROM blaat where id='$id'";
$sqlquery = mysql_query($query,$connect) or die(mysql_error());
$sqlquery = mysql_fetch_array($query); // !
?>

PHP:

<?
$connect = mysql_connect($server,$usersql,$passwd)or die("Bad connect string: ".mysql_error());
mysql_select_db("$dbnaam",$connect)or die("Bad database change: ".mysql_error());
$query_string = "SELECT * FROM blaat where id='$id'";
$query_result = mysql_query($query_string,$connect) or die(mysql_error());
$query_array = mysql_fetch_array($query_result);
?>

[drm]

tips

Leer je zelf om op deze manier codeblocks te tikken:
geldt voor Javascript en C en C++ en Java ook (mijn manier is natuurlijk niet de manier )


<sub>voorbeeldje "if":

eerst de if:
[code]if ( conditie )[/code]
dan de accollades:
[code]if ( conditie )
{
}[/code]
nog else? dan else en ook weer eerst accolades:
[code]if ( conditie )
{
}
else
{
}[/code]
Dan pas de code ertussen:
[code]if ( conditie )
{
code ();
}
else
{
meer code ();
}[/code]
Is de code 1 statement? (oftewel bevat het gedeelte tussen de { en } maar 1 punt-komma?) Haal dan de accollades weer weg:
[code]if ( conditie )
code ();
else
meercode ();[/code]</sub>



En dan heb ik nog een vraagje:

wat is gangbaar met de triary (.. ? .. : ..) expressie:

PHP:

<?
echo "Sjaak is " . $leeftijd > 18 ? "ouder" : "jonger" . " dan 18";
?>

of zo: (meestal doe ik het zo:)

PHP:

<?
echo "Sjaak is " 
     . ( $leeftijd > 18 )
         ? "ouder" 
         : "jonger" 
     . " dan 18";
?>

[D2k]

Op dinsdag 04 september 2001 16:14 schreef drm het volgende:
tips

Leer je zelf om op deze manier codeblocks te tikken:
geldt voor Javascript en C en C++ en Java ook (mijn manier is natuurlijk niet de manier )

dat zeg ik ook in de eerstepost

En dan heb ik nog een vraagje:

wat is gangbaar met de triary (.. ? .. : ..) expressie:

PHP:

<?
echo "Sjaak is " . $leeftijd > 18 ? "ouder" : "jonger" . " dan 18";
?>

of zo: (meestal doe ik het zo:)

PHP:

<?
echo "Sjaak is " 
     . ( $leeftijd > 18 )
         ? "ouder" 
         : "jonger" 
     . " dan 18";
?>

uhm voor beide is wat te zeggen
maar denk dat de 2e leesbaarder is? imho

[Anoniem: 24408]

Ik vind die triary expressie in zijn geheel onoverzichterlijk eigenlijk.

[D2k]

Op dinsdag 04 september 2001 16:28 schreef daniel_hoenderdos het volgende:
Ik vind die triary expressie in zijn geheel onoverzichterlijk eigenlijk.

ik zou hem zelf ook niet gebruiken maar toch als je het wil doen is de 2e duidelijker denk ik

[Anoniem: 24408]

En ik vind het ook prettig om in sommige gevallem met switch en break te werken. In de meeste gevallen voldoet if en else wel, maar switch is soms ideaal:

PHP:

<?
switch($bla) 
{
      case [case]:
             expr
      break;

      case [case]:
             expr
      break;
}
?>

[Janoz]

Op dinsdag 04 september 2001 16:14 schreef drm het volgende:
wat is gangbaar met de triary (.. ? .. : ..) expressie:

PHP:

<?
echo "Sjaak is " . $leeftijd > 18 ? "ouder" : "jonger" . " dan 18";
?>

of zo: (meestal doe ik het zo:)

PHP:

<?
echo "Sjaak is " 
     . ( $leeftijd > 18 )
         ? "ouder" 
         : "jonger" 
     . " dan 18";
?>

ik zou sowieso ff haakjes om de hele triary expressie heenzetten.. Op deze manier is niet zeker of voor de eerste expressie nu

code:

$leeftijd > 18

of

code:

 "Sjaak is " . $leeftijd > 18

moet worden genomen en of het antwoord bij een false test nu

code:

 "jonger"

of

code:

"jonger" . "dan 18"

is.

[drm]

D2k:
dat zeg ik ook in de eerstepost

Het ging mij vooral om eerst accollades te tikken. Dan vergeet je ze nooit en maak je ook nooit fouten zoals razor-x zei.

uhm voor beide is wat te zeggen
maar denk dat de 2e leesbaarder is? imho

daniel_hoenderdos:
Ik vind die triary expressie in zijn geheel onoverzichterlijk eigenlijk.

Ben ik het mee eens, maar in sommige gevallen zijn ze zo verrekte handig.

* drm stelt voor om voor GoT een nette-code-topic te openen
wat standaarden opstellen dmv discussie, om die vervolgens in de FAQ op te nemen.
Wat zeggen de mods er van?


_edit:

Op dinsdag 04 september 2001 16:38 deed Janoz een suggestie
ik zou sowieso ff haakjes om de hele triary expressie heenzetten..

Heb je gelijk in. Doe ik normaal gesproken ook, maar ik gebruik ze niet zo vaak dat het gewoonte was geworden

[D2k]

Op dinsdag 04 september 2001 16:39 schreef drm het volgende:
* drm stelt voor om voor GoT een nette-code-topic te openen
wat standaarden opstellen dmv discussie, om die vervolgens in de FAQ op te nemen.
Wat zeggen de mods er van?

daar was dit topic eik ook voor bedoeld
* D2k heeft nl een stukje aan ACM gestuurd dat tzt in de faq zal komen ( )
met de tips zoals die al in dit topic stonden tot jouw reply

ik zal hem zo wel ff posten dan kunnen we hem nog verder uitbreiden k?

[drm]

Op dinsdag 04 september 2001 16:41 schreef D2k het volgende:
daar was dit topic eik ook voor bedoeld
* D2k heeft nl een stukje aan ACM gestuurd dat tzt in de faq zal komen ( )
met de tips zoals die al in dit topic stonden tot jouw reply

ik zal hem zo wel ff posten dan kunnen we hem nog verder uitbreiden k?

Ja best . Vraag hem meteen de topicnaam te veranderen in iets van "[PHP, C, C++, Java] Nette code". Laat iedereen maar spuien, komen vast wel goede ideen voorbij. En de syntax van die talen lijkt zo op elkaar dat je daar best een universele regeling voor op kan stellen. (ik ben zelf niet zo weg van die van javasoft en php.net enzo...)

[D2k]

Op dinsdag 04 september 2001 16:47 schreef drm het volgende:

[..]

Ja best. Vraag hem meteen de topicnaam te veranderen in iets van "[PHP, C, C++, etc] Nette code".

ACM is er nu ff niet dat vrag ik hem vanaaf wel ff
maar de versie die ik nu heb is eik een beetje php only
dus niet zeuren "goh wel veel php" dat klopt
ik wil hem best gaan omschrijven

(o ja en onder deze reply komt ie dan )

[D2k]

Debuggen in PHP

Veel topics in /14 gaan over phpcode die errors geeft danwel niet werkt.
Hoe los je dit het snelste op?

Bouw je query's als volgt

PHP:

<?
$connect = mysql_connect($server,$usersql,$passwd)or die("Bad connect string: ".mysql_error());
mysql_select_db("$dbnaam",$connect)or die("Bad database change: ".mysql_error());

$sql222 = "SELECT * FROM blaat where id='$id'"; 
$q222 = mysql_query($sql222,$connect) or die(mysql_error());
?>

op deze wijze kan je dus dmv van een echo "$sql222"; de waarden van je query bekijken.
En dus direct zien of je wel de juiste dingen in je query hebt. In dit geval of id wel bestaat oid.

Code dus ook overzichtelijk.
Bekijk het verschil tussen de 2 onderstaande voorbeelden
• 1

PHP:

<?
if($blaatwat){
echo "blaat";
}else{
echo "niet blaat";}
?>

• 2

PHP:

<?
if($blaatwat)
{
    echo "blaat";
}
else    
{
    echo "niet blaat";
}
?>

zo krijg je dus geen (nou jah minder) fouten met haakjes.
En nee ik gebruik er niet te veel want dit zijn simpele voorbeeldjes

Verder kan je het beste

PHP:

<?
echo "<pre>";
print_r("$var");
echo "</pre>";
?>

gebruiken bij variabelen waar je aan twijfelt,
en dan in het bijzonder bij array's natuurlijk.

ook een redelijk vaak voorkomende fout is

PHP:

<?
if ($blaat)
{       
    echo "Blaat";
}
else
} // kijk goed !!       
    echo "niet blaat";
}
?>

het plaatsen van een verkeerd haakje.


Verder hebben PHP en MySQL prima foutmeldingen:
ERROR: Parse error on line 14
staat er neit voor niks, en je zou dus kunnen beginnen met zoeken op lijn 14, en langzaam omhoog werken..
meestal is dit gewoon het vergeten van een haakje, komma of aanhalingsteken..
Daarvoor is het inspringen zo belangrijk (standaard is 4 spaties geloof ik, maar een tab of 4 spaties word ook veel gebruikt)

ERROR: Supplied argument is not a valid MySQL result resource
betekend dat je iets fout doet met je query, zorg dat zo'n error word afgevangen..

PHP heeft prachtige ERROR handeling functies, kijk bevoorbeeld eens naar
error_reporting
set_error_handler

En voor mySQL fouten:
mysql_error

Als je dan na 30x kijken toch nog neit hebt gevonden wat de fout is en je het toch op GoT post, doe dat dan iig duidelijk.
Post het stukje code (dus niet de complete 62Kb) met de foutmelding, tussen php tags en GEEF AAN IN WELKE REGEL de fout zit.. Als iemand post dat er in regel 102 een fout zit, ga ik geen 102 regels tellen, en het schiet helemaal niet op als alleen regel 94 t/m 125 er staat..



Duidelijke variabelenamen kunnen ook helpen, zodat je ze moelijk kan omdraaien.
zo dus niet

PHP:

<?
$connect = mysql_connect($server,$usersql,$passwd)or die("Bad connect string: ".mysql_error());
mysql_select_db("$dbnaam",$connect)or die("Bad database change: ".mysql_error());
$query = "SELECT * FROM blaat where id='$id'";
$sqlquery = mysql_query($query,$connect) or die(mysql_error());
$sqlquery = mysql_fetch_array($query); 
// !
?>

maar

PHP:

<?
$connect = mysql_connect($server,$usersql,$passwd)or die("Bad connect string: ".mysql_error());
mysql_select_db("$dbnaam",$connect)or die("Bad database change: ".mysql_error());
$query_string = "SELECT * FROM blaat where id='$id'";
$query_result = mysql_query($query_string,$connect) or die(mysql_error());
$query_array = mysql_fetch_array($query_result);
?>

als afsluitende tip:
gebruik een editor met highlighting mogelijk heden. Dit voorkomt veel problemen omdat je dan aan de kleur van je code kan zien of het klopt.

vragen opmerkingen kritiek via icq #18966246
(zpel en tiepvautte voorbehauwe) D2k ©2001
tnx 2 ACM voor het corrigeren,razor-x,Timpie2000 en Bart Coppens voor het commentaar op de oorspronkelijke versie

[drm]

<sub>[flauwe modus][quote]
D2k:
(...)
ERROR: Supplied argument is not a valid MySQL result resource
betekend dat je iets fout doet met je query, zorg dat zo'n error word afgevangen..
(...)
(zpel en tiepvautte voorbehauwe)
(...)
[/quote]

betekent

[/flauwe modus]</sub>

[Anoniem: 24408]

Hee drm... Hoe was het voor die mier?
Verder vind ik dit een prima idee. Veel van de topics van GoT komen in de eerste plaats voort uit rommelige klote code.
Goed plan!

[D2k]

Op dinsdag 04 september 2001 17:22 schreef daniel_hoenderdos het volgende:
Hee drm... Hoe was het voor die mier?
Verder vind ik dit een prima idee. Veel van de topics van GoT komen in de eerste plaats voort uit rommelige klote code.
Goed plan!

kom maar met suggesties
* D2k verwerkt het wel

[Anoniem: 24408]

Wat mij (vroeger.. ) nog wel eens gebeurde waren fouten als images proberen te thumbnailen zonder een imagecreate opdracht... En ik maar zoeken.
Kortom: bij script fouten eerst kijken of het script uberhaupt wel klopt...

[ACM]

Op verzoek een nieuwe topictitel.

[Anoniem: 18091]

Meeste deed ik idd al maar die met die query's vindt ik wel een goeie, die ga ik zeker wel gebruiken..

[drZymo]

Ok zelf schrijf ik mijn acolades altijd op een iets andere manier. Zo vind ik het zelf altijd ook vrij duidelijk:

code:

if ( bla == 'blaat' ) {
    immers;
} else {
    daarentegen;
}

Maarja dit kan aan mij liggen.

Met HTML kan vaak ook de layout wat fijner. Vooral met tabellen. Mijn manier:

code:

<table parameters..>
<tr>
    <td>
      Een lap text :P
    </td>
    <td>
      En nog een lapje
    </td>
</tr>
<tr>
    <td colspan=2>
      Dus...
    </td>
</tr>
</table>

M.a.w. Inspringen rulez

[drm]

* drm post binnenkort een linkje naar zijn php en html-coding conventies

Verder ben ik van mening dat je je code ook verticaal zoveel mogelijk uit moet lijnen. Is in het begin misschien schraal, maar uiteindelijk een kwestie van jezelf een gewoonte aanleren. Wat bedoel ik:

niet:

code:

functie ( dit, dit, en, dat );
functie ( nuNogeenkeer, maar, dan, zo );
functieTwee ( En, nu, een, andere, functie );
functieTwee ( Met, ook, twee, aanroepen, dus );

maar:

code:

functie     ( dit,      dit,  en,  dat );
functie     ( nuNogeenkeer, maar, dan, zo  );
/* hier kun je een enter overwegen */
functieTwee ( En,  nu,  een,  andere,    functie );
functieTwee ( Met, ook, twee, aanroepen, dus     );

Dit geldt dan ook voor variabelen:
niet:

code:

var $var1="waarde1", $variable2="waarde2", $dingetje3="waarde3", $melp="waarde4";

maar:

code:

var   $var1 = "waarde1", 
    $variable2 = "waarde2", 
    $dingetje3 = "waarde3", 
    $melp   = "waarde4";

wordt een functieaanroep te lang, wees niet bang op een volgende regel verder te gaan. Lijn dan wel haakje openen, haakje sluiten verticaal goed uit:

niet:

code:

functieAanroep ( blablabla, blablabla2(melpje,lerpje,nogwatmeuk), ennogmeeronzin );

maar:

code:

functieAanroep ( 
   blablabla, 
   blablabla2 (
    melpje,
    lerpje,
    nogwatmeuk
   ), 
   ennogmeeronzin 
);

Kies uiteraard zelf wanneer dit echt van toepassing is.

Verder na *elke* komma een spatie. Om operators ook altijd spaties, en na en voor haakjes spaties:

niet:

code:

if(sjaak==melp)doedandit=dezewaardegeven;

maar:

code:

if ( sjaak == melp )
   doedandit = dezewaardegeven;

codeblokken:

niet:

code:

if(conditie)statement;
else(conditie){compoundstatement}

maar:

code:

if ( conditie )
   statement;
else
{
   compoundstatement;
}

Naamgeving variabelen, functies etc:
Niet te lang, geen underscores, alleen inner capitalization
niet:

code:

var  sjaakdebeverisgekomen;

function DITISEENFUNCTIE ()

class DItisEENCLASSEwaarikDitENDITMeeDOe

maar:

code:

var sjaakDeBeverIsGekomen;

function ditIsEenFunctie ()

class DitIsEenClass

tot slot:
indentering nooit met tabs, maar met spaties. Dan weet je zeker dat het er in elke editor/IDE hetzelfde uitziet.
Tab-grootte op 3 of 4 (wel consistent uiteraard )


Pff, 'tis wat. Ik vraag me af of iemand dit helemaal gaat lezen

[D2k]

Op dinsdag 04 september 2001 18:38 schreef drm het volgende:


Pff, 'tis wat. Ik vraag me af of iemand dit helemaal gaat lezen

* D2k heeft het gelezen
nuttige post tnx

geeft me wel een hoop werk extra voor in de faq

[Macros]

Wel toevallig dat dit nu wordt besproken aan het begin van het academische schooljaar. Al deze tips en conventies zijn bij ons in het eerste kwartaal van onze (informatica) studie met Java er al ingestampt.

Persoonlijk hou ik van:

code:

if($bla > 23){
    code(1);
}else(
    code(2);
}

En de ..?..:.. constructie gebruik ik alleen als je veel if then else achter elkaar hebt met allemaal ongeveer dezelfde korte code stukjes. Dat komt eigenlijk dus maar weinig voor

Ook een tipje. Definieer al je constanten aan het begin van je code voor je classes.
Becomentarieer al je classes en variabelen, vooral de constanten.

[wasigh]

als je veel if's en else gebruikt en het liefst genest is het altijd wel handig om bij het eind = } -je te zetten waar die ook alweer van was

code:

if
{ 
   for ()
   { 
    code
   } // end for
} end if

[whoami]

Heb hier al goeie gebruiken zien staan.

mijn if's doe ik ook altijd zo:

code:

if (expressie)
{
  code;
  functieaanroep(arg, arg, arg);
  functiaanroep(lange argument1,
            lang argument2);
}
else
{
  code
}

Ook het declareren van identifiers kun je best uitlijnen.

code:

int     intvariable;       // commentaar over var
float   fpvariable;     // commentaar over var

[mbravenboer]

Enkele (naar mijn mening) goede Java (en OO in algemeen) gebruiken:

1. Gebruik getypeerde enumeraties ipv integers.
2. Maak niet constante variabelen nooit public.
3. Geef een methode parameter nooit een nieuwe waarde.
4. Gebruik altijd code-blocks bij if, while, for etc.
5. Vermijd het gebruik van de ... ? ... : ... constructie.
6. Gebruik Engelse namen om de code er homogeen uit te laten zien in combinatie met standaard API gebruik.
7. Overweeg het gebruik van _ voor klasse variabelen, om een duidelijk onderscheid te maken tussen lokale en klasse variabelen.
8. Vermijd het gebruik van static.
9. Gebruik een Iterator ipv een Enumeration, ArrayList ipv Vector, HashMap ipv Hashtable
10. Gebruik een StringBuffer als je over meerdere statements een String moet opbouwen. Als je een String in 1 statement optelt, wordt dit automatisch gedaan.
11. Gebruik zoveel mogelijk maar 1 return statement in een methode.
12. Schrijf korte methoden. Als een methode duidelijk meerdere taken verricht, moet je overwegen om dit op te splitsen.
13. Eet je exceptions nooit op door ze simpel naar de System.out te schrijven. Gooi ze zover door als noodzakelijk is.
14. Roep altijd de super constructor aan.

Tja, kan nog wel ff doorgaan, maar dit komt het eerste in me op .

[D2k]

Op dinsdag 04 september 2001 22:22 schreef mbravenboer het volgende:

Tja, kan nog wel ff doorgaan, maar dit komt het eerste in me op .

"ga door geef alles " quote naar Bert Visscher

* D2k gaat een hoop werk krijgen binnenkort

[Anoniem: 13943]

In de php manual staat PEAR bescreven, is een manie rom php te schrijven, commenten etc.. zodat je makkelijk je dingetjes kan sharen met anderen.

Ik hou me er wel redelijk aan, maar let er niet speciaal op.
Meeste doe je automagisch.

[drm]

Op dinsdag 04 september 2001 18:57 schreef Macros het volgende:
Persoonlijk hou ik van:

code:

if($bla > 23){
    code(1);
}else(
    code(2);
}

Zit jij toevallig in Rotterdam? Dit lijkt verrekte veel op Blankert-code. Afgrijselijk lelijk en onleesbaar als je het mij vraagt

[Janoz]

Op woensdag 05 september 2001 09:07 schreef drm het volgende:

[..]

Zit jij toevallig in Rotterdam? Dit lijkt verrekte veel op Blankert-code. Afgrijselijk lelijk en onleesbaar als je het mij vraagt

Ikzelf ben wel voorstander van het 'open accolade achter statement' principe tegenover het 'open accolade op nieuwe regel' principe.

Zoals al eerder aangegeven is het met de laatste soms lastig te zien of er een open of sluiten accolade is, maar dat is eigenlijk niet zo'n sterk argument aangezien dit al snel duidelijk wordt door een parse error van de compiler.

De belangrijkste reden dat ik de eerste versie gebruik is omdat dat door de meeste editor's ook wordt ondersteund (noem me lui, maar werk maar eens met een fatsoenlijke editor die je code ook automatisch uitlijnt). Daarnaast vind ik het qua leesbaarheid weinig verschillen..

[stylee]

Mischien ook wel interessant, alhoewel dit meer een boek is voor wat gevorderde programmeurs (en de meeste voorbeelden zijn in C, d.w.n.z dat ze niet algemeen toepasbaar zijn):

Programmeren in de praktijk: Brian W. Kernighan, Rob Pike, Addison-Wesley Professional, ISBN: 90-430-0232-1

[drm]

Op woensdag 05 september 2001 10:38 schreef Janoz het volgende:

[..]

Ikzelf ben wel voorstander van het 'open accolade achter statement' principe tegenover het 'open accolade op nieuwe regel' principe.

Zoals al eerder aangegeven is het met de laatste soms lastig te zien of er een open of sluiten accolade is, maar dat is eigenlijk niet zo'n sterk argument aangezien dit al snel duidelijk wordt door een parse error van de compiler.

De belangrijkste reden dat ik de eerste versie gebruik is omdat dat door de meeste editor's ook wordt ondersteund (noem me lui, maar werk maar eens met een fatsoenlijke editor die je code ook automatisch uitlijnt). Daarnaast vind ik het qua leesbaarheid weinig verschillen..

het ging mij vooral om dit stukje:

code:

}else{

vind ik er gewoon niet uitzien, maar dat boeit opzich niet.
Het is in feite maar net wat je gewend bent. Ik ben gewend op een volgende regel te beginnen, wat overigens ook als oorzaak heeft dat wanneer ik er een extra statement tussenzet:

code:

if ( conditie )
   dit en dat;

code:

if ( conditie )
   dit en dat;
   zus en zo;

het een stuk makkelijker is om op dezelfde horizontale hoogte de accollades te zetten:

code:

if ( conditie )
{
   dit en dat;
   zus en zo;
}

Plus dat als mijn oog op de sluitaccolade zit en ik zoek naar de "matching brace" dat ik recht omhoog kan gaan, om de beginaccollade te vinden, ipv. te kijken of het nou een if, een else of for is. (beetje slap excuus, weet ik ).

tot slot omdat het selecteren van blokken (shift-pijltje omhoog, shift-pijltje omlaag, etc) zo een stuk makkelijker is, omdat editors vaak ook hele regels gaan selecteren.

En ik klop het liefst al mijn code zelf. Gaat ondertussen minstens zo snel, en parse errors kom ik nooit (afkloppen ) meer tegen

[Anoniem: 13700]

Hehehe, 1TBS versus Allman style indenting holy war in the make. Mijn ervaring leert dat de meeste bedrijven je een formatteringsstijl opleggen, je hebt dus niets te kiezen. Daarom zijn er tools als indent geschreven, die code probleemloos overzetten van de ene formatteringsstijl in de andere.

Laten we dus voor eens en voor altijd ophouden met argumentaties waarom de persoonlijke, subjectieve voorkeur voor een formatteringsstijl meteen ook objectief gezien het beste moet zijn. Er zijn namelijk tooltjes zat, waarmee je lappen code in een paar seconden in de door jouw gewenste stijl kunt formatteren. Er zijn dus geen rationele redenen om andere mensen jouw stijl op te leggen.

[drm]

mietje:
(...)
Er zijn dus geen rationele redenen om andere mensen jouw stijl op te leggen.

Klopt. Maar voorkeur is voorkeur. 't Gaat ook helemaal niet om die discussie. Het gaat er om dat iedereen leesbare code post.


zoals beloofd: mijn PHP coding conventies.
Het is een concept en voor alle kritiek, commentaar, etc ontvankelijk. Daarvoor kun je me mailen.

[D2k]

Op woensdag 05 september 2001 12:04 schreef drm het volgende:

[..]

Klopt. Maar voorkeur is voorkeur. 't Gaat ook helemaal niet om die discussie. Het gaat er om dat iedereen leesbare code post.


zoals beloofd: mijn PHP coding conventies.
Het is een concept en voor alle kritiek, commentaar, etc ontvankelijk. Daarvoor kun je me mailen.

ziet er netjes uit
* D2k denkt er wel een leuk docu'tje uit te kunnen halen met alle info tot nu toe voor in de faq

[RdeTuinman]

En het is nooit weg om voldoende commentaar te gebruiken. Gebruik het wel netjes door het bijvoorbeeld in blokken te zetten:

code:

//----------------------------------------------------------
// Functie Blaat(arg1, arg2)
//----------------------------------------------------------
//
// Input:
// arg1     : int aantal maal
// arg2     : *char[] weer te geven tekst
//----------------------------------------------------------
//
// Returns
// true     : gelukt
// false    : mislukt
//----------------------------------------------------------
bool Blaat(int,*char[])
{
   enz..

Zo kun je bijvoorbeeld snel zien hoe de functie aangeroepen moet worden.

Het is vaak zo (tenminste bij mij) dat je na een paar weken je code bekijkt en jezelf afvraagt: Waarom heb ik dat zo gedaan...
Dan had commentaar een uitkomst geweest.

[Anoniem: 13700]

Lees m'n commentaar nu nog eens door. Is het nu echt nodig dat je mensen verplicht tot Allman style? Ik begrijp dat jij liever accolades uitgelijnd ziet, maar is het daarom meteen voor iederen het beste?

Argumenten over het uitlijnen van variabelen kan ik begrijpen, en ook het indenten van code blocks. Maar zitten mieren*ken waar een accolade moet komen, vind ik toch echt wat ver gaan. Dat werkt volgens mij ook averrechts, omdat je op de vingers van een hand kunt aftellen dat er geflamed gaat worden over 1TBS.

Om het duidelijk te stellen: Ik vind juist 1TBS beter voor een forum, omdat je minder regels gebruikt en dus kortere posts krijgt.

[D2k]

Op woensdag 05 september 2001 12:23 schreef mietje het volgende:
Lees m'n commentaar nu nog eens door. Is het nu echt nodig dat je mensen verplicht tot Allman style? Ik begrijp dat jij liever accolades uitgelijnd ziet, maar is het daarom meteen voor iederen het beste?

Argumenten over het uitlijnen van variabelen kan ik begrijpen, en ook het indenten van code blocks. Maar zitten mieren*ken waar een accolade moet komen, vind ik toch echt wat ver gaan. Dat werkt volgens mij ook averrechts, omdat je op de vingers van een hand kunt aftellen dat er geflamed gaat worden over 1TBS.

Om het duidelijk te stellen: Ik vind juist 1TBS beter voor een forum, omdat je minder regels gebruikt en dus kortere posts krijgt.

uit zijn documentje

...
Met dit document bedoel ik niet dat mijn manier de manier is.
....

<ot>
Rob je heb ut toch niet over mijn IOS brouwsels hè?
</ot>

[RdeTuinman]

Op woensdag 05 september 2001 12:24 schreef D2k
<ot>
Rob je heb ut toch niet over mijn IOS brouwsels hè?
</ot>

Laat ik daar maar geen commentaar op geven

[drm]

Op woensdag 05 september 2001 12:23 schreef mietje het volgende:
Lees m'n commentaar nu nog eens door. Is het nu echt nodig dat je mensen verplicht tot Allman style? Ik begrijp dat jij liever accolades uitgelijnd ziet, maar is het daarom meteen voor iederen het beste?

Argumenten over het uitlijnen van variabelen kan ik begrijpen, en ook het indenten van code blocks. Maar zitten mieren*ken waar een accolade moet komen, vind ik toch echt wat ver gaan. Dat werkt volgens mij ook averrechts, omdat je op de vingers van een hand kunt aftellen dat er geflamed gaat worden over 1TBS.

Om het duidelijk te stellen: Ik vind juist 1TBS beter voor een forum, omdat je minder regels gebruikt en dus kortere posts krijgt.

Je begrijpt iets niet. Ik verplicht niemand tot iets. Ik beargumenteer mijn manier. Ik geef tips. En als je het liever anders doet, moet je dat wat mij betreft helemaal zelf weten.
Dit topic was om ideeen te spuien, en daar doe ik graag aan mee. En als ik dat beargumenteer, doe ik dat alleen om er een licht op te laten schijnen wat een ander misschien niet had gezien. Het gaat er niet om wat beter of slechter is. Net als dat jij hier jouw wijze beargumenteert:

Om het duidelijk te stellen: Ik vind juist 1TBS beter voor een forum, omdat je minder regels gebruikt en dus kortere posts krijgt.

prima toch? fijn.

[D2k]

en up
laatste mogelijkheid voor aanbevelingen/kritieken en lofzang

hierna als dit topic nu weer is afgezakt ga ik er een stukje van maken voor de faq

[Anoniem: 22295]

Hoe je stijl ook is, je stijl consequent blijven gebruiken. Klinkt misschien logisch maar ik zie vaak genoeg lui die 3 stijlen door elkaar gebruiken.

[Anoniem: 27563]

Misschien heb ik niet goed opgelet toen ik de posts aan het lezen was, maar ik mis nog een ontzettend belangrijk verhaal: commentaar.

Nog belangrijker dan proberen je te houden aan vorm-conventies (waar moet mijn accolade, hoe indenteer ik welke soort blokken, etc?) is ervoor te zorgen dat een collega een klein verhaaltje boven een functie ziet dat uitlegt wat de bedoeling ervan is...

[Martijn02]

Op dinsdag 04 september 2001 18:57 schreef Macros het volgende:

...

Persoonlijk hou ik van:

code:

if($bla > 23){
    code(1);
}else(  // <-- fout! ( ipv {
    code(2);
}

...

Persoonlijk hou ik er niet van, maar als je het wel wil doen, ga gerust je gang. Je zal alleen een parse error tegen komen omdat je ( gebruikt ipv { en die is niet naar mijn mening makkelijker te vinden in de allman style

Ik snap wel dat dit een zinloze discussie is, en dat iedereen moet doen wat hij zelf handig/leuk/lekker vind werken. al zou het wel handig zijn als iedereen hetzelfde zou gebruiken, maar ik kan allebei de varianten lezen, en schrijven dus ik maak me niet druk

[.oisyn]

nou, als iedereen coodde (is dat een woord ik code, jij code, wij coden, ik coodde, wij coodden) zoals ik, dan zou de wereld een betere plaats geweest zijn

[Anoniem: 29256]

Over die verschillende stijlen, is het misschien een idee om users hier in hun prefs in te laten stellen volgens welk format ze de code in [ code ] [ /code ] zouden willen zien (en dat dan dus via zo'n format-tooltje) ?

[Nikel]

Op maandag 10 september 2001 09:15 schreef Sneech het volgende:
Over die verschillende stijlen, is het misschien een idee om users hier in hun prefs in te laten stellen volgens welk format ze de code in [ code ] [ /code ] zouden willen zien (en dat dan dus via zo'n format-tooltje) ?

Nee, want dan komen newbe's er dus mee weg als ze geen nette code posten op got omdat niemand dan kan zien hoe het ge-format is .

Maar ook, er worden nooit zulke grote lappen code gepost op got dat de precieze format stijl van belang is, als het maar netjes is op _een_ manier.

[drm]

Aanbevelingen voor PHP-specifiek:


MySQL queries als volgt:

PHP:

<?
   $queryString =<<<SQL
      SELECT    t1.bla,
                t2.bla2
      FROM      tabel   as t1
                tabel2  as t2
      WHERE     (tabelrelaties)
                (condities in volgorde van prioriteit)
      GROUP BY  y
      ORDER BY  x
      LIMIT     o,l
SQL;
?>

over embedded HTML:

Toegestaan, echter alleen wanneer in dat specifieke PHP document de layout centraal staat (ivm modulair gebruik van PHP-documenten). Oftewel, je index.php ziet er zoiets uit:

PHP:

<?
include ( "preHTMLIncludesAndFunctions" );
include ( "header.inc.html" );
include ( "actions.inc.php" )
include ( "formatResults.inc.php" );
include ( "footer.inc.html" );
?>

Dan kan formatResults.inc.php allerlei embedded HTML bevatten, maar actions.inc.php juist weer niet. actions.inc.php bevat juist allerlei acties ( queries, db-bewerkingen, file-bewerkingen, etc ) en formatResults de manier om het te showen aan de gebruiker.

[Creepy]

Misschien nog een tip voor de vele SQLlers hiero

zo kan het

code:

SELECT w.naam. w.adres, w.woonplaats, w.blaat, a.naam FROM werknemers w, afdelingen a WHERE w.afdeling = a.id AND w.naam='Creepy'

Maar wat dacht je van zo:

code:

SELECT w.naam. w.adres, w.woonplaats, w.blaat, a.naam
FROM werknemers w, afdelingen
WHERE w.afdeling = a.id
 AND w.naam='Creepy';

In php kan je string over meerdere regels plaatsen zonder problemen die plakt ie dan zelf wel aan elkaar dus

code:

$query = "SELECT w.naam. w.adres, w.woonplaats, w.blaat, a.naam
FROM werknemers w, afdelingen
WHERE w.afdeling = a.id
 AND w.naak=\"Creepy\"";

is geen probleem in PHP.. maar wel een stuk overzichtelijker voor achter lange queries

edit:
Aarrgghh. denk ik met iets nieuws te komen, is drm me voor.... (sowwy drm)

[Nielsz]

Waarom de ene wel en de andere niet?

[drm]

Creepy:
(...)

edit:
Aarrgghh. denk ik met iets nieuws te komen, is DRM me voor....

zie m'n sig

Je kan niet altijd de eerste zijn

Nielsz:
Waarom de ene wel en de andere niet?

Wat bedoel je?
_{[hint] [/hint]}

[D2k]

mooi

ik brouw er een eind aan
ik ga aan de slag met alles wat er nu in staat

ik wil iedereen die tot nu toe heeft mee gewerkt bedanken
en jullie krijgen ook nog wel de tekst te lezen voor ik hem aan acm stuur
zodat er nog eventuele fouten en onjuistheden verwijderd kunnen worden

[drm]

Op maandag 10 september 2001 15:46 schreef D2k het volgende:
mooi

ik brouw er een eind aan
ik ga aan de slag met alles wat er nu in staat

ik wil iedereen die tot nu toe heeft mee gewerkt bedanken
en jullie krijgen ook nog wel de tekst te lezen voor ik hem aan acm stuur
zodat er nog eventuele fouten en onjuistheden verwijderd kunnen worden

cool ben wel benieuwd

[D2k]

Op maandag 10 september 2001 16:48 schreef drm het volgende:

[..]

cool ben wel benieuwd

ut gaat wel ff duren hoor denk ik
staat bizar veel info in in dit topic

[Nielsz]

Op maandag 10 september 2001 16:53 schreef D2k het volgende:

[..]

ut gaat wel ff duren hoor denk ik
staat bizar veel info in in dit topic

En je moet natuurlijk nog wat dingen met spoed voor mij doen (dat weet je nog niet, maar dat komt wel )

[Ericston]

Nog heel even over die curly braces:

Ik vind...

code:

main() {
    if ( foo ) {
      doStuff();
    }
}

...veel beter, het ziet er gewoon stukken strakker uit.

Dit...

code:

main()
{
    if ( foo )
    {
      doStuff();
    }
}

...daarentegen ziet eruit als een soort mislukte kapstok... met hier en daar wat dunne stokjes (curly braces) die de boel op de plaats houden.

Daarnaast zie ik de Allman style als een fossiel uit de tijd dat prototyping nog niet bestond en functies zo moesten worden geschreven:

code:

main( argc, argv)
int argc;
char **argv;
{
    doStuff();
}

Aangezien niemand hiermee overtuigd wordt, zal ik er toch mee moeten leven dat ik minder strakke code moet aanschouwen.

[drm]

Op maandag 10 september 2001 17:25 schreef Ericston het volgende:
Nog heel even over die curly braces:

^bla_bla^bla_bla^bla_bla^bla_bla^bla_bla^bla_bla

Daar is geen discussie meer over, dacht ik zo. Dat is namelijk ook een eindeloze discussie, en wat je nu zegt is een slap verhaal, zonder argumentatie (no offense meant ).

D2k >> Heb jij besloten wat er in komt te staan over accollades?

[Anoniem: 22001]

D2K heeft een en ander gecombineerd tot: [topic=225411/1/25] (voor degenen die het gemist hebben)

[D2k]

Op dinsdag 11 september 2001 09:42 schreef Zef het volgende:
D2K heeft een en ander gecombineerd tot: [topic=225411/1/25] (voor degenen die het gemist hebben)

tnx
had dit topic al niet meer gezien

ben inmiddels helemaal klaar
en het gaat in de faq

[ACM]

Zie de FAQ