[/14] nette code release versie *FAQ Update*

[D2k]

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

Veel topics in /14 gaan over code die errors geeft danwel niet werkt.
In deze post staan veel code dingen waarvan sommige niet werken in elke taal of gewoon helemaal niet werken.
Dat klopt dit is gewoon om te laten zien hoe het kan.

Hoe los je code problemen het snelste op? Beter nog hoe voorkom je ze.
Onderwerpen
• Overzichtelijk coden
• Controleer zelf je code
• Zet commentaar bij je code
• Taal specifiek : JAVA en ObjectOriented(algemeen)
• Taal specifiek :debuggen in PHP

--------------------------------------------------------------
--------------------------------------------------------------
--------------------------------------------------------------


• Overzichtelijk coden

Bekijk het verschil tussen de 2 onderstaande voorbeelden
• 1

code:

if(blaatwat){
echo "blaat";
}else{
echo "niet blaat";}

• 2

code:

if(blaatwat)
{
    echo "blaat";
}
else    
{
    echo "niet blaat";
}

Een switch statement bouw je zo:

code:

switch(bla) 
{   
    case [case]:         
        expr    
        break;  
    case [case]:         
        expr    
        break;
}

Let op niet iedereen is het eens met het bovenstaande.
Zie ook hier en hier.
Ik pretendeer niet gelijk te hebben maar weet wel uit ervaring, dat hier vaak fouten in ontstaan.

Nog een inspring voorbeeld

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>

nog wat voorbeelden

niet zo

code:

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

maar zo

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 zo

code:

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

maar zo

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 zo

code:

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

maar zo

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:

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

code:

var  sjaakdebeverisgekomen;
function DITISEENFUNCTIE ()

class DItisEENCLASSEwaarikDitENDITMeeDOe

maar zo

code:

var sjaakDeBeverIsGekomen;
function ditIsEenFunctie ()

class DitIsEenClass

• Controleer zelf je code

Bij script fouten eerst kijken of het script uberhaupt wel klopt.
Dus controleer op werking.
Het maken van een PSD/flowchart is echt geen doodszonde als je er niet meer uitkomt.
Je bent te laat met het maken van een PSD/flowchart deze moet je eerst maken maar als je je idee alsnog op papier zet kan je je code controleren.
En natuurlijk 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.

• Zet commentaar bij je code

code:

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

code:

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

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[])
{
//en verder met de functie

• Taal specifiek : JAVA en ObjectOriented(algemeen)
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.



• Taal specifiek :debuggen in PHP


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());

$sql = "SELECT * FROM blaat where id='$id'"; 
$query = mysql_query($sql,$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.

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

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";
}
?>

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 niet 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
betekent 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);
?>

of bij grotere query's is dit veel overzichtelijker:

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

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, Bart Coppens, drm,
RdeTuinman, mietje, stylee, Janoz,
mbravenboer, wasigh, whoami,Macros,
drZymo en Nielsz voor het commentaar op de oorspronkelijke versie


------------------------------------------
kritiek hier ajb

[razor-x]

Dit moet sticky zijn !

[Janoz]

Ik ga liever voor de

code:

if (conditie) {
  statements;
  .....
} else {
  statements;
  .....
}

variant. Deze wordt ook veel ondersteund door de 'automatisch uitlijnende editors'.

[D2k]

Op maandag 10 september 2001 22:09 schreef Janoz het volgende:
Ik ga liever voor de

code:

if (conditie) {
  statements;
  .....
} else {
  statements;
  .....
}

variant

*kuch*

Op maandag 10 september 2001 21:13 schreef D2k het volgende:
Let op niet iedereen is het eens met het bovenstaande.
Zie ook hier en hier.
Ik pretendeer niet gelijk te hebben maar weet wel uit ervaring, dat hier vaak fouten in ontstaan.

[Janoz]

Die discussies heb ik ook gevolgd, en ik wilde hem nog wel ff toevoegen aan dit topic ..

Zelf gebruikte ik eerst ook de '{ op volgende regel'-variant.. De reden waarom ik overgestapt ben is
1 - veel editors lijnen automatisch uit op de manier die ik net aangaf
2 - Je 'verspilt' geen regel.. Klinkt mischien raar, maar als je veel if-blokken onder elkaar hebt kun je meer code op het scherm zien..

Maar iedereen moet voor zichzelf beslissen welke variant ze gebruiken zolang ze maar goed inspringen .

[2]

Ik ben niet zo deskundig als de meesten hier maar ik denk dat er 2 dingen vooral belangrijk zijn:
1 - Dat je indents gebruikt op de 1||andere manier, of andere vormen van structuur aangeven in je code dmv lege ruimte (de voordelen blijken vanzelf wel wanneer je het probeert en lijken mij totaal niet ter discussie.)

2 - dat je er consequent in bent.

Maar verder maakt het niet zoveel uit hoe volgens mij.

Het is uiteindelijk een soort van handschrift, dus als iemand anders jouw code moet lezen en je structuur niet gewend is kan hij eraan wennen en leren wat je met wat bedoelt. Maar dan moet je het dus wel overal op dezelfde manier doen.

code:

if(voorwaarde){
         if(nogvoorwaarde)
{functie();
        }
elsif(blaat){ anderefunctie();
}else
     {
     noganderefunctie();}}
     else{if(nogvoorwaarde){functie();
}
elsif(blaat)
           {
anderefunctie();
}
           else
           {noganderefunctie();
       }
                     }

[Verwijderd]

Sti-cky! Sti-cky!

[ACM]

Leuk detail voor de Sun proggerts met C... // is daar geen geldig commentaar teken

Als ik dit sticky maak, wil ik dat de final versie van D2K 'goed gekeurd is'

Dan laat ik hem het wel in de "FAQ thread" posten... om nou nog een thread sticky te maken...

[Nielsz]

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

Denkut niet. Dat betekent dat er geen resultaten terug worden gestuurd. Dat is heel wat anders.

select * from blaat where id='X3q4A';

de query is goed, er komen waarschijnlijk geen resultaten terug...

[ACM]

Op dinsdag 11 september 2001 09:06 schreef Nielsz het volgende:
Denkut niet. Dat betekent dat er geen resultaten terug worden gestuurd. Dat is heel wat anders.

select * from blaat where id='X3q4A';

de query is goed, er komen waarschijnlijk geen resultaten terug...

Och, had je dat getest... dan wist je dat je onzin sprak

[Nielsz]

Op dinsdag 11 september 2001 09:10 schreef ACM het volgende:

[..]

Och, had je dat getest... dan wist je dat je onzin sprak

vertel maar mr wiseguy

[MrEdge_]

Op maandag 10 september 2001 22:14 schreef D2k het volgende:

[..]

*kuch*
[..]

D'r zijn ook zat editors waar je gewoon in kunt stellen hoe je je layout er uit wilt laten zien.

Persoonlijk vind ik de stijl met een nieuw regel voor elke bracket het meest overzichtelijk en geeft het imo minder kans op vergeten haakjes.

[drm]

Op dinsdag 11 september 2001 09:10 schreef ACM het volgende:

[..]

Och, had je dat getest... dan wist je dat je onzin sprak

hehehe


D2k >> Wat mij betreft heb je er een prachtverhaal van geschreven. sticky is the word

[ACM]

Op dinsdag 11 september 2001 09:15 schreef Nielsz het volgende:
vertel maar mr wiseguy

Een lege resultset is nog steeds een resultset... Need more info?

[drm]

Op dinsdag 11 september 2001 09:16 schreef Mr Edge het volgende:

[..]

D'r zijn ook zat editors waar je gewoon in kunt stellen hoe je je layout er uit wilt laten zien.

Persoonlijk vind ik de stijl met een nieuw regel voor elke bracket het meest overzichtelijk en geeft het imo minder kans op vergeten haakjes.

Die discussie is geweest. Consequentie is belangrijker dan een de keuze maken tussen die paar manieren

D2k >> zag toch een paar puntjes

code:

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

// voor end if

code:

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

Uitlijning klopte niet helemaal....

[Verwijderd]

Op dinsdag 11 september 2001 08:59 schreef ACM het volgende:
Dan laat ik hem het wel in de "FAQ thread" posten... om nou nog een thread sticky te maken...

"P&W is niet meer wat het geweest is, je moet eerst 3 pagina's aan sticky topics door worstelen voor je bij de echt topics aan komt!"

[Verwijderd]

Ja das wel kut, alles gaat nou over php of mysql, en doe mij maar een topic over het diehard programmeren

[Verwijderd]

Op dinsdag 11 september 2001 09:49 schreef ceidhof het volgende:
Ja das wel kut, alles gaat nou over php of mysql, en doe mij maar een topic over het diehard programmeren

Da's discriminatie Hoezo kun je met PHP niet diehard programmen?

[ACM]

Op dinsdag 11 september 2001 09:49 schreef ceidhof het volgende:
Ja das wel kut, alles gaat nou over php of mysql, en doe mij maar een topic over het diehard programmeren

Voor diehard programming, moet je deze kennis toch ook wel hebben...

Maar het is gewoon niet te doen, om dat in een postinkje uit te leggen.

[blimmel]

Op maandag 10 september 2001 21:13 schreef D2k het volgende:
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());

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

op deze wijze kan je dus dmv van een echo "$sql222"; de waarden van je query bekijken.

moet je wel $sql222 wel als variable gebruiken... anders doet een echo niet zo veel

[Verwijderd]

Vinden jullie het erg als ik me niet aan jullie standaarden houdt? GoT is voor mij nog altijd iets dat ik vrijwillig doe, en ik ga mezelf niet dwingen tot een coding style die ik newbie-achtig en oerlelijk vindt. Als dit een verplichting wordt, zal ik dus geen code meer posten. (Uitlijnen van functieparameters, get a life. Ik wil programmeren, niet code-calligraferen).

Het lijkt me trouwens, dat jullie coding style enorm lange postings gaat veroorzaken, die meestal de layout van de pagina's zullen slopen.

Dit is niet bedoeld als flame, ik wil alleen laten zien dat er ook mensen zijn die het niet met jullie beslissingen eens zijn. Als deze beslissingen verplichtingen worden, zullen die mensen daar hun consequenties uit trekken.

[JapJap]

Wie gaat er nu de Jindent property files maken voor C, Java, etc... ?

[ACM]

Op dinsdag 11 september 2001 11:12 schreef mietje het volgende:
Vinden jullie het erg als ik me niet aan jullie standaarden houdt? GoT is voor mij nog altijd iets dat ik vrijwillig doe, en ik ga mezelf niet dwingen tot een coding style die ik newbie-achtig en oerlelijk vindt. Als dit een verplichting wordt, zal ik dus geen code meer posten.

Tuurlijk niet, de eerste (en elke andere ook) die je dat verplicht krijgt van mij een waarschuwing!
Het is meer als aanrader voor degenen die alle code in een ranzige "niet consequente methode" neerpoten.
En nog hopen dat wij er wijs uit worden ook.

(Uitlijnen van functieparameters, get a life. Ik wil programmeren, niet code-calligraferen).

Mja, code schrijven zul je duidelijk en consequent in een bepaalde vorm moeten doen.

Dat jij voorkeur voor een bepaalde stijl hebt maakt niks uit.

Maar het is wel raadzaam om je code, ten allen tijden, duidelijk te schrijven, al is het alleen maar dat je het zelf na 4 maanden nog snapt
En als je met anderen samen werkt, is het zeker raadzaam de code "overdreven duidelijk" te maken.

[demonite]

Op maandag 10 september 2001 21:13 schreef D2k het volgende:
[Nog een inspring voorbeeld

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>

------------------------------------------
kritiek hier ajb

Coding standards zijn in principe goed om je aan te houden... maar niet 100%.. er zijn meerdere wegen die naar rome leiden, zoals je zelf ook al aangaf.

Ik wel nog even zeggen dat bovenstaand HTML voorbeeld wat je gegeven hebt FOUT is.
Door die TD's op een andere regel te zetten als de content wordt er automatisch een spatie ingevoegd, wat op zich niet erg is met tekst, maar wel met GFX!

probeer maar eens 2 plaatjes naadloos op elkaar aan te laten sluiten .. dan zul je zien dat je die IMG tag ook naadloos moet omsluiten met TD tags.

code:

<td>[img]""></td[/img]

en niet

code:

<td>
   [img]"">
</td[/img]

want dat gaat geheid fout!

[Verwijderd]

Op dinsdag 11 september 2001 11:21 schreef ACM het volgende:
Mja, code schrijven zul je duidelijk en consequent in een bepaalde vorm moeten doen.

Ik heb het dus over dingen als:

code:

x = EenOfAndereFunc   (EenOfAndereParam  , NogEenParam);
y = WeerEenAndereFunc (WeerEenAndereParam, EenOfAndereParam);

Als je dit soort dingen consequent over enkele pagina's code wilt volhouden, ben je op het einde meer spaties aan het tellen dan code aan het schrijven. Dat vind ik contra-productief en noem ik code-calligrafie.

Ik heb geen problemen met het uitlijnen van accolades, inspringingsregels enz., desnoods laat ik m'n source door indent lopen. Maar er is naar mijn weten geen enkele formatting tool die dingen als het bovenstaande voorbeeld aankan.

[Crazy D]

Op dinsdag 11 september 2001 11:57 schreef mietje het volgende:
Ik heb geen problemen met het uitlijnen van accolades, inspringingsregels enz., desnoods laat ik m'n source door indent lopen. Maar er is naar mijn weten geen enkele formatting tool die dingen als het bovenstaande voorbeeld aankan.

Ik denk dat indent en uitlijnen ook het belangrijkste is. En 't is een lijdraad (?) voor de wat minder ervaren coder die nu een beetje aanklungelt met verschillende stijlen door elkaar. Er is niet 1 ideale style (ja die van mij natuurlijk ) maar feit is wel dat een hoop fouten voorkomen hadden kunnen worden door gewoon de code netjes neer te zetten. Netjes, zodat je het zelf snapt, je dingen in 1 oogopslag kan zien i.p.v. dat je bv moet gaan tellen hoeveel 'open' accolades je hebt gehad, om er genoeg te sluiten en zo, over 2 maanden de code ook nog snapt, en erg belangrijk voor hier, dat de mensen die je willen helpen geen moeite hoeven doen de code leesbaar te formatteren.

Kwee nie hoe het met anderen zit, maar ik sluit genoeg topic-vensters alleen maar omdat ik 50 regels ongeformatteerde code zie. Ik wil best wel ff kijken naar code om te zien of ik toevallig het probleem er uit kan halen, maar ik wil geen moeite doen om de code eerst leesbaar te maken.

[drm]

CrazyD_at_work:
lijdraad (?)

vandale.nl:
Žlei·draad (de ~ (m.))

1 richtsnoer
2 beknopte handleiding

Op dinsdag 11 september 2001 11:57 schreef mietje het volgende:

[..]

Ik heb het dus over dingen als:

code:

x = EenOfAndereFunc   (EenOfAndereParam  , NogEenParam);
y = WeerEenAndereFunc (WeerEenAndereParam, EenOfAndereParam);

Als je dit soort dingen consequent over enkele pagina's code wilt volhouden, ben je op het einde meer spaties aan het tellen dan code aan het schrijven. Dat vind ik contra-productief en noem ik code-calligrafie.

Ik heb geen problemen met het uitlijnen van accolades, inspringingsregels enz., desnoods laat ik m'n source door indent lopen. Maar er is naar mijn weten geen enkele formatting tool die dingen als het bovenstaande voorbeeld aankan.

Het gaat er maar om dat het hier op GoT leesbaar is. Zo leesbaar mogelijk. En ik vind *persoonlijk* dat dat daar aan bijdraagt. Dat was het initiatief.

Hoe het er op jouw pc uitziet zal me een worst wezen, en niemand verplicht je ergens toe (kan het niet vaak genoeg zeggen, kennelijk ), maar plak-code willen wij (en daar hoor jij zelf vast ook bij) hier allemaal voorkomen. En dan kunnen we daar best een beetje overdreven in zijn.

[Verwijderd]

Lijkt me een duidelijke versie van wat we hadden.
ACM, haal even de niet interesante replies (zoals deze dus) eruit en maak hem ff sticky svp.

[D2k]

Op dinsdag 11 september 2001 14:01 schreef daniel_hoenderdos het volgende:
Lijkt me een duidelijke versie van wat we hadden.
ACM, haal even de niet interesante replies (zoals deze dus) eruit en maak hem ff sticky svp.

nee ik zorg er wel voor dat het goed komt
nu ff replyen op alles wat er tot nu toe is gebeurd en dan lever ik de laatste versie aan acm
(je kijkt ff niet en er zijn 20 reply's )

[D2k]

Op dinsdag 11 september 2001 09:30 schreef drm het volgende:

[..]

Die discussie is geweest. Consequentie is belangrijker dan een de keuze maken tussen die paar manieren

D2k >> zag toch een paar puntjes

code:

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

// voor end if

done

code:

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

Uitlijning klopte niet helemaal....

vreemd ik zie hem hier lokaal wel met indent?

test
ik neem de jouwe wel

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

hmmz de phptags verneuken um??
ik herschrijf um wel gewoon

test2

code:

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

[D2k]

Op dinsdag 11 september 2001 10:12 schreef blimmel het volgende:

[..]

moet je wel $sql222 wel als variable gebruiken... anders doet een echo niet zo veel

oops
done

ff vergeten dacht dat ik ze wel allemaal had

laatste visualcheck is geweest

[D2k]

Op dinsdag 11 september 2001 11:40 schreef demonite het volgende:

[..]

Coding standards zijn in principe goed om je aan te houden... maar niet 100%.. er zijn meerdere wegen die naar rome leiden, zoals je zelf ook al aangaf.

Ik wel nog even zeggen dat bovenstaand HTML voorbeeld wat je gegeven hebt FOUT is.
Door die TD's op een andere regel te zetten als de content wordt er automatisch een spatie ingevoegd, wat op zich niet erg is met tekst, maar wel met GFX!

probeer maar eens 2 plaatjes naadloos op elkaar aan te laten sluiten .. dan zul je zien dat je die IMG tag ook naadloos moet omsluiten met TD tags.

code:

<td>[img]""></td[/img]

en niet

code:

<td>
   [img]"">
</td[/img]

want dat gaat geheid fout!

done
tnx

[Apache]

deze zou idd sticky moeten zijn, zodat er niet meer zoveel 'proza' geprogged word

[D2k]

Op woensdag 12 september 2001 08:41 schreef Apache het volgende:
deze zou idd sticky moeten zijn, zodat er niet meer zoveel 'proza' geprogged word

um voor 1 keer mag het

READ THE FAQ

daar staat ie nl al in
deze draad blijft open voor eventuele opmerkingen achteraf
en aanvullingen enzo

[Scorpion]

ff opmerking, voor commentaar bij java-code is er een standaard voor javadoc (om hieruit automatische documententatie te laten rollen (API docs)).

[Verwijderd]

Good point - javadoc is belangrijk. Ik heb al eerder lopen zemelen over code van commentaar voorzien - dat is en blijft een must als je met meerdere mensen programmeert...

[Scare360]

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



ZOIETS HEET EEN PRE EN POST CONDITIE... jij wil mij/ons uitleggen hoe het moet met je input returns kwats...

[drm]

Op woensdag 12 september 2001 14:15 schreef paulgielens het volgende:
//----------------------------------------------------------
// Functie Blaat(arg1, arg2)
//----------------------------------------------------------
//
// Input:
// arg1 : int aantal maal
// arg2 : *char[] weer te geven tekst
//----------------------------------------------------------
//
// Returns
// true : gelukt
// false : mislukt
//----------------------------------------------------------
bool Blaat(int,*char[])
{
//en verder met de functie



ZOIETS HEET EEN PRE EN POST CONDITIE... jij wil mij/ons uitleggen hoe het moet met je input returns kwats...

ZOIETS bewoordt men doorgaans anders. 'anders' as in 'vriendelijker'.

[D2k]

Op woensdag 12 september 2001 14:15 schreef paulgielens het volgende:
//----------------------------------------------------------
// Functie Blaat(arg1, arg2)
//----------------------------------------------------------
//
// Input:
// arg1 : int aantal maal
// arg2 : *char[] weer te geven tekst
//----------------------------------------------------------
//
// Returns
// true : gelukt
// false : mislukt
//----------------------------------------------------------
bool Blaat(int,*char[])
{
//en verder met de functie



ZOIETS HEET EEN PRE EN POST CONDITIE... jij wil mij/ons uitleggen hoe het moet met je input returns kwats...

ook een goeden middag
Wenst meneer dit gewijzigd te zien?
Dan mag meneer in normale bewoordingen een wijziging voorstellen.

[RdeTuinman]

Op woensdag 12 september 2001 14:15 schreef paulgielens het volgende:
//----------------------------------------------------------
// Functie Blaat(arg1, arg2)
//----------------------------------------------------------
//
// Input:
// arg1 : int aantal maal
// arg2 : *char[] weer te geven tekst
//----------------------------------------------------------
//
// Returns
// true : gelukt
// false : mislukt
//----------------------------------------------------------
bool Blaat(int,*char[])
{
//en verder met de functie



ZOIETS HEET EEN PRE EN POST CONDITIE... jij wil mij/ons uitleggen hoe het moet met je input returns kwats...

Ik geloof dat ik degene was die dit id naar voren bracht. Had je toen ook al commentaar? Geloof het niet. En ik schrijf het gewoon in het Hollands op!

Ik wil graag dat iedereen het begrijpt, dat is uiteindelijk ook de bedoeling

[D2k]

Op woensdag 12 september 2001 15:13 schreef RdeTuinman het volgende:

[..]

Ik geloof dat ik degene was die dit id naar voren bracht. Had je toen ook al commentaar? Geloof het niet. En ik schrijf het gewoon in het Hollands op!

Ik wil graag dat iedereen het begrijpt, dat is uiteindelijk ook de bedoeling

Robert laat maar gaan joh
we zien wel of ie nog een verbetering wil aandragen
zo nee negeren we het gewoon

[mbravenboer]

Ik had nog niet gezien dat je mijn lijstje zo over had genomen in de tekst. Misschien is het handig als ik de punten nog even iets beter uitleg of illustreer met code? Dit kan erg onduidelijk overkomen (zeker voor diegene die de voordelen ervan niet inzien, en dat is juist de doelgroep ).

[Scare360]

Op woensdag 12 september 2001 15:17 schreef D2k het volgende:

[..]

Robert laat maar gaan joh
we zien wel of ie nog een verbetering wil aandragen
zo nee negeren we het gewoon

Iedereen heeft gelukkig zijn eigen manier van coderen... en iedereen prefereert zijn eigen layout... daarom excuseer ik mij graag voor mijn bovenstaande opmerking!

Als reactie D2K:

C++ :

/////////////////////////////
// Class beschrijving
////////////////////

////////////////////
// Main procs
//////////

/* hulp procedures/functies */

// comments die in final builds weggehaald worden

inspring van regels bedraagt altijd 2 harde spaties bv:

for(int i=0;i<ittr;i++) {
tempI=i;
if (tempI=5) {
tempK=i;
tempL=(tempK+i)*5;
}
}

void main(void) {
/*
pre : pre-condities
post: post-condities
result: result-textuele beschrijving resultaat procedure
*/


}

,MAAR TIS MAAR EEN MANIER... normaal gesproken wordt de syntax met een tooltje gestructureerd iig in een team-project.

edit:
ik zie dat die spaties hier niet lekker weergegeven worden...foutje

[mbravenboer]

Het is totaal niet zinvol om 'de' standaard manier van commentaar en documentatie te beschrijven. Over het algemeen heeft elke taal daarvoor zijn eigen standaard. Je zou wel gek zijn als je in Java iets anders gebruikt dan de Javadoc standaard. In C# zou je wel gek zijn als je daar niet de xml variant van javadoc gaat gebruiken. De compiler zal er in dit laatste geval zelfs over waarschuwen.

Het is voor zulke zaken denk ik beter om te linken naar bestaande bronnen die de standaarden voor de diverse platformen beschrijven.

[Crazy D]

Op donderdag 13 september 2001 00:35 schreef mbravenboer het volgende:
Het is totaal niet zinvol om 'de' standaard manier van commentaar en documentatie te beschrijven.

Behalve dat er idd. geen "de" standaart is, denk ik dat het er voornamelijk om ging om proberen duidelijk te maken dat goed duidelijk commentaar erbij zetten belangrijk is. En hoe het in de betreffende taal "normaal" is, is weer iets anders. Maar ik denk dat voor iedere taal het er wel zo'n beetje op neerkomt dat je bv bij een functie kort omschrijft wat de functie doet, en de input en output paraqms beschrijft. En dan is het formaat waarin dat gebeurt niet zo heel boeiend.

[D2k]

Op woensdag 12 september 2001 23:58 schreef paulgielens het volgende:

[..]

Iedereen heeft gelukkig zijn eigen manier van coderen... en iedereen prefereert zijn eigen layout... daarom excuseer ik mij graag voor mijn bovenstaande opmerking!

excuses geacepteerd
no hard feelings maar ik zeg ook in het stuk dat het niet naar de zin van iederaan zal zijn
dus als je kritiek hebt onderbouw het gewoon dan kan ik het voor een volgende versie erin zetten

Als reactie D2K:

tnx daar kan ik wat mee voor een volgende versie

edit:
ik zie dat die spaties hier niet lekker weergegeven worden...foutje

gebruik daar voor de [.code] en [./code] zonder puntjes
dan blijven de spaties/tabs wel intact

[wasigh]

Op woensdag 12 september 2001 23:58 schreef paulgielens het volgende:



/////////////////////////////
// Class beschrijving
////////////////////

////////////////////
// Main procs
//////////

Dit soort commentaar kan ik echt niet tegen. Voegt niets toe. is onduidelijk, tijdrovend en pagina vervuilend..

[whoami]

Heb nog een tip voor als je functies (of procedures, methods.. what's in a name) met veel variablen hebt. Die kan je dan op die manier gaan schrijven:

code:

void  MyFunction(int    i_arg,     // var info
             float  f_arg,     // var info
             float  f_arg2,   // var info
             char*  str_arg);   // var info

Dit geeft een veel overzichtelijker beeld van die functie dan dat je het op onderstaande manier zou doen (vind ik...)

code:

void  MyFunction(int i_arg, float f_arg, float f_arg2, char* str_arg);

Maar, iedereen doet het natuurlijk op zijn manier, het zijn maar tips die hier aangebracht worden...

[D2k]

Op donderdag 13 september 2001 21:07 schreef whoami het volgende:
Heb nog een tip voor als je functies (of procedures, methods.. what's in a name) met veel variablen hebt. Die kan je dan op die manier gaan schrijven:

code:

void  MyFunction(int    i_arg,     // var info
             float  f_arg,     // var info
             float  f_arg2,   // var info
             char*  str_arg);   // var info

Dit geeft een veel overzichtelijker beeld van die functie dan dat je het op onderstaande manier zou doen (vind ik...)

code:

void  MyFunction(int i_arg, float f_arg, float f_arg2, char* str_arg);

Maar, iedereen doet het natuurlijk op zijn manier, het zijn maar tips die hier aangebracht worden...

zoiets staat er wel in maar dit is wel een duidelijk voorbeeld
genoteerd voor de volgende versie
tnx

[Verwijderd]

Wat ik mis is standaarden voor het becomentarieren van functies, variabelen en classen.
Bekijk het volgende voorbeeld:

<?php
/**
* deze functie berekent x tot de macht y van een getal
*
* @param int getal + evt toelichting
* @param int pow + evt toelichting
* @return int result + evt toelichting
* @access public ( kan ook zijn: private protected...)
*/
function power($getal, $pow) {
...
}
?>

Deze functie voldoet aan de phpdoc standaard. Commentaar plaatsen volgens een standaard zorgt ervoor dat het leesbaar wordt voor anderen. Bovendien kan er nu documentatie worden gegenereerd. Een voorbeeld van de genereerde documentatie: http://www.achievo.org/docs/atk/

Standaardisatie commentaar voor PHP: www.phpdoc.org
Standaardisatie commentaar voor java: http://java.sun.com/j2se/javadoc/

[D2k]

Verwijderd schreef op 08 november 2002 @ 09:04:
Wat ik mis is standaarden voor het becomentarieren van functies, variabelen en classen.
Bekijk het volgende voorbeeld:

<?php
/**
* deze functie berekent x tot de macht y van een getal
*
* @param int getal + evt toelichting
* @param int pow + evt toelichting
* @return int result + evt toelichting
* @access public ( kan ook zijn: private protected...)
*/
function power($getal, $pow) {
...
}
?>

Deze functie voldoet aan de phpdoc standaard. Commentaar plaatsen volgens een standaard zorgt ervoor dat het leesbaar wordt voor anderen. Bovendien kan er nu documentatie worden gegenereerd. Een voorbeeld van de genereerde documentatie: http://www.achievo.org/docs/atk/

Standaardisatie commentaar voor PHP: www.phpdoc.org
Standaardisatie commentaar voor java: http://java.sun.com/j2se/javadoc/

hmmz kan er idd ook nog wel in
als ik weer eens een updateronde doe zal ik het meenemen
tnx

[whoami]

Tja, duidelijk commentaar is wel een must.
In .NET heb je 'XML-commentaar':
///<summary></summary>
///<param name="paramname"></param>
etc...

Als je in VS.NET /// typed, dan wordt die gehele structuur door VS.NET opgemaakt, en dan kan je html - docs laten genereren.

Wat je ook nog kunt doen is voor iedere source-file een soort header maken, met daarin wie de file gecreeerd heeft, een history, etc...

[Alarmnummer]

D2k schreef op 10 september 2001 @ 21:13:

• Taal specifiek : JAVA en ObjectOriented(algemeen)
1. Gebruik getypeerde enumeraties ipv integers.

Aangezien java geen enumeratie type heeft, kan deze consrtructie daarvoor gebruikt worden.

Java:

class Type{
   public final static Type STRING = new Type();
   public final static Type INT = new Type();
   public final static Type REAL = new Type();
   
   private Type(){}
}

3. Geef een methode parameter nooit een nieuwe waarde.

Ze hadden automatisch final moeten zijn

5. Vermijd het gebruik van de ... ? ... : ... constructie.

Ik gebruik hem intussen ook, het is een stuk korter dan de iflus variant.

7. Overweeg het gebruik van _ voor klasse variabelen, om een duidelijk onderscheid te maken tussen lokale en klasse variabelen.

En verder gebruik ik s_ als prefix voor niet final static velden

8. Vermijd het gebruik van static.

Wat is er mis met static?? Het is een heel ander type dan de 'instance' variable, maar is erg nuttig.

9. Gebruik een Iterator ipv een Enumeration, ArrayList ipv Vector, HashMap ipv Hashtable

Als je een gesynchroniseerde structuur nodig hebt, dan is een Vector of een Hashtable interessanter dan een ArrayList of Hashmap omdat de laatsten niet gesynchroniseerd zijn. Je kan trouwens wel een gesynchroniseerde versie van de laatste 2 maken, door ze in een sychronized wrapper te plaatsen. Zie hiervoor de Collections class.

11. Gebruik zoveel mogelijk maar 1 return statement in een methode.

Soms vind ik het handig om zo vroeg mogelijk uit mijn methodes te springen. Ik weet dat een aantal mensen willen dat er maar een exit point is maar dan moet je weer zo idioot ver gaan inspringen en dat maakt de leesbaarheid zeker niet beter. Je zou hier eventueel wel een jump statements voor kunne gebruiken

13. Eet je exceptions nooit op door ze simpel naar de System.out te schrijven. Gooi ze zover door als noodzakelijk is.

Je eet hem niet op door hem in de out te gooien hoor. Wat jij bedoelt is dit:

Java:

try{
    doHeleEngeDingen();
catch(EngeException e){
}

Als er nu een fout optreed, dan zal je dat nooit te weten komen omdat je dus niets met die exception doet (dat is veel erger dan hem in de out te gooien, want dan weet je tenminste nog van het bestaan af). De boven genoemde constructie mag je alleen gebruiken als je zeker weet dat het geen kwaad kan + je moet als commentaar toevoegen waarom hij niet afgevangen hoeft te worden

14. Roep altijd de super constructor aan.

Gebeurt al automatisch hoor als je super constructor argumentloos is

[D2k]

Alarmnummer schreef op 08 november 2002 @ 09:20:
[...]

Aangezien java geen enumeratie type heeft, kan deze consrtructie daarvoor gebruikt worden.

Java:

class Type{
   public final static Type STRING = new Type();
   public final static Type INT = new Type();
   public final static Type REAL = new Type();
   
   private Type(){}
}

[...]

Ze hadden automatisch final moeten zijn


[...]

Ik gebruik hem intussen ook, het is een stuk korter dan de iflus variant.


[...]

En verder gebruik ik s_ als prefix voor niet final static velden


[...]

Wat is er mis met static?? Het is een heel ander type dan de 'instance' variable, maar is erg nuttig.


[...]

Als je een gesynchroniseerde structuur nodig hebt, dan is een Vector of een Hashtable interessanter dan een ArrayList of Hashmap omdat de laatsten niet gesynchroniseerd zijn. Je kan trouwens wel een gesynchroniseerde versie van de laatste 2 maken, door ze in een sychronized wrapper te plaatsen. Zie hiervoor de Collections class.


[...]

Soms vind ik het handig om zo vroeg mogelijk uit mijn methodes te springen. Ik weet dat een aantal mensen willen dat er maar een exit point is maar dan moet je weer zo idioot ver gaan inspringen en dat maakt de leesbaarheid zeker niet beter. Je zou hier eventueel wel een jump statements voor kunne gebruiken


[...]

Je eet hem niet op door hem in de out te gooien hoor. Wat jij bedoelt is dit:

Java:

try{
    doHeleEngeDingen();
catch(EngeException e){
}

Als er nu een fout optreed, dan zal je dat nooit te weten komen omdat je dus niets met die exception doet (dat is veel erger dan hem in de out te gooien, want dan weet je tenminste nog van het bestaan af). De boven genoemde constructie mag je alleen gebruiken als je zeker weet dat het geen kwaad kan + je moet als commentaar toevoegen waarom hij niet afgevangen hoeft te worden


[...]

Gebeurt al automatisch hoor als je super constructor argumentloos is

durf jij de grote mbravenboer tegen te spreken?? [rml]mbravenboer in "[ /14] [ PHP, C, C++, JAVA, etc] Nette co"[/rml]

[whoami]

Ik zie eigenlijk ook niet in waarom static variablen moeten vermeden worden, ik zie het gebruik van statics niet echt als 'bad programming practice'. In het Singleton design pattern kan je zelfs niet zonder static. En ook voor andere dingen kunnen ze zeer handig zijn.
Als je bv een class hebt die passwoorden ofzo gaat gaan kontroleren, dan kan je toch makkelijk een static gebruiken voor een variable als "maximum_paswoord_lengte". oid.

De ternary operator ( ( ... ) ? ... : ... ; is misschien voor de beginnende programmeur niet zo duidelijk, maar in bepaalde gevallen gebruik ik hem toch ook wel.

Statics met een s_ prefix laten beginnen is wel een goed idee, op dit moment gebruik ik altijd m_ als prefix voor members (zowel instance variablen als static).

D2k schreef op 08 november 2002 @ 09:23:
[nohtml]
[...]
[/nohtml]
durf jij de grote mbravenboer tegen te spreken?? [rml]mbravenboer in "[ /14] [ PHP, C, C++, JAVA, etc] Nette co"[/rml]

Noem het een revolutie, een opstand....

[gorgi_19]

Als we het toch ook over debuggen hebben, met ASP.Net vind ik het gebruik van Tracing erg makkelijk bij het debuggen...

ASP:

' *******************************************
'
' LittleValidation Function
'
' Tries a little validation of a given value
' *******************************************
Public Function LittleValidation(iNumber1, iNumber2) as Boolean
    HttpContext.Current.Trace.Write("Validation", "Started with validation")
    If iNumber1 > iNumber2 Then
        return false
    End if
    return true
End Function

Op deze manier hoef je niet alles naar je scherm te zetten (maar kan je het opvragen bij http://<applicationroot>/trace.axd, mits je deze in je config.web hebt aangezet.

code:

HttpContext.Current.Trace.Write("Validation", "Started with validation")

Is verantwoordelijk hiervoor; validation is de categorie, Started with validation de omschrijving.

[Glimi]

D2k schreef op 10 September 2001 @ 21:13:
Naamgeving variabelen, functies etc:
Niet te lang, geen underscores, alleen inner capitalization

Maak ze gewoon zo lang als dat ze nodig zijn. Te kort zou ik eerder willen voorkomen.

• Taal specifiek : JAVA en ObjectOriented(algemeen)
2. Maak niet constante variabelen nooit public.

En geef ze altijd een setter/getter. Zo kun je de business logica altijd nog wijzigen en ervoor zorgen dat er altijd een geldige waarde in die param zit, zonder die checks op 6 plekken te hoeven hebben.

dus niet:

Java:

public class Flerps {

        private int _age;
        
        public Flerps( int age ) {
        
                //age must be > 10 otherwise it can't be a Flerps
                //
                if( age < 10 )
                        throw new IllegalArgumentException( "age must be > 10" );
                        
                _age = age;
        }

        public void doCoolStuff( int amount ) {

                // Multiply the age by 30 and substract 4000 then add 99
                // finaly substract the parameter amount
                // because then the Flerps is in super mode!
                
                int tempage = _age;
                tempage = (tempage * 30) - 4000 + 99 - amount;
                
                if( tempage < 10 )
                        throw new IllegalArgumentException( "tempage is to large and brings age < 10" );
                        
                _age = tempage;
        }  
}

In deze code staat de controle op _age 2x. Het zou dus beter zo kunnen:

Java:

public class Flerps {

        private int _age;
        
        public Flerps( int age ) {
        
                setAge( age );
        }

        private void setAge( int age ) {
        
                if( age < 10 )
                        throw new IllegalArgumentException( " age > 10" );
                        
                _age = age;
        }
        
        public int getAge( ) {
        
                return _age;
        }
        
        public void doCoolStuff( int amount ) {

                // Multiply the age by 30 and substract 4000 then add 99
                // finaly substract the parameter amount
                // because then the Flerps is in super mode!
                
                
                setAge( (getAge() * 30) - 4000 + 99 - amount);
        }  
}   

Dit doe ik eigenlijk altijd voor elke private variabele ik heb in een classe. Zelfs al mag de variabele elke waarde aannemen. Reden hiervoor is dat deze variabele later wel makkelijk beperkt kan worden dan.

4. Gebruik altijd code-blocks bij if, while, for etc.

Tja, zoals je boven ziet, heb ik echt geen zin om al die haken neer te gaan donderen bij zo'n domme if( bla > 10 ) of een if( bla == null) check. Zeker aangezien ik na het openen van een blok ook weer een enter geef, neemt zo'n ifcheck 4 regels in beslag (met commentaar 6)

6. Gebruik Engelse namen om de code er homogeen uit te laten zien in combinatie met standaard API gebruik.

Dan moet je wel goed engels kunnen, anders wordt de code juist alleen maar onduidelijker! Je moet juist afwegen of je het de moeite waardt vindt om dit te doen, maar ik zou het niet als een echt tip neerzetten. Vaak is het wel verplicht op je werk though

8. Vermijd het gebruik van static.

Kan dit veranderen in : vermijd het gebruik van non final static variabelen (constanten) Hoewel ze soms nuttig zijn (Singleton bijv) is er een reden voor het vermijden, nl. overerving. Een static method/variabele hoort bij de class. Als hij wordt overgeërft, komt de static method/var niet mee.

9. Gebruik een Iterator ipv een Enumeration, ArrayList ipv Vector, HashMap ipv Hashtable

Is dit nog relevant? De Map en Vector niet imho. Die zitten nu ook in collections, enige verschil is dat ze syncronized zijn en ArrayList dus niet, maarja die keuze moet je dus laten afhangen aan de hand van je programma ontwerp, iig niet ten allen tijden vermijden.

11. Gebruik zoveel mogelijk maar 1 return statement in een methode.

Als een if check failt als precondion, dan ben ik echt wel weg met het gooien van een exception. Midden in een methode wegrennen (dus na de precondions) vind ik ook een beetje raar, maar is soms hard nodig.

13. Eet je exceptions nooit op door ze simpel naar de System.out te schrijven. Gooi ze zover door als noodzakelijk is.

Hoezo? Als je ze niet opeet gaan ze toch ook gewoon naar System.out Als je de exception maar weet. Gewoon verteren (catch(Exception e) { } ) vindt ik veel enger.

14. Roep altijd de super constructor aan.

Alleen als het nodig is, zou ik dat doen.

whoami schreef op 08 november 2002 @ 09:27:
Ik zie eigenlijk ook niet in waarom static variablen moeten vermeden worden, ik zie het gebruik van statics niet echt als 'bad programming practice'. In het Singleton design pattern kan je zelfs niet zonder static. En ook voor andere dingen kunnen ze zeer handig zijn.
Als je bv een class hebt die passwoorden ofzo gaat gaan kontroleren, dan kan je toch makkelijk een static gebruiken voor een variable als "maximum_paswoord_lengte". oid.

Nou noem je net 2 dingen waarvoor ze handig zijn:
• Constanten
• Het kunnen garanderen dat er 1 is.
Echter bedenk je wel een static var/method bij een klasse hoort. Ga je hem overerven, dan heeft de nieuwe classe _geen_ beschikking over die methodes/variabeles.

De ternary operator ( ( ... ) ? ... : ... ; is misschien voor de beginnende programmeur niet zo duidelijk, maar in bepaalde gevallen gebruik ik hem toch ook wel.

Als er meer dan 1 check en meer dan 1 statement in de if of else moet komen, dan haak ik ermee af.

Statics met een s_ prefix laten beginnen is wel een goed idee, op dit moment gebruik ik altijd m_ als prefix voor members (zowel instance variablen als static).

Noem het een revolutie, een opstand....

Ik zie niet zo het belang om statics anders te gaan bekijken als een member

edit:
Ik zit wel lekker dicht bij Alarmnummer in de buurt met m'n mening. Je kan wel zien wie mijn docent geweest is

[Nielsz]

D2k schreef op 08 November 2002 @ 09:23:

[...]

durf jij de grote mbravenboer tegen te spreken?? [rml]mbravenboer in "[ /14] [ PHP, C, C++, JAVA, etc] Nette co"[/rml]

*proest*
Iedereen denkt: "ah, D2k zegt wat, snel afzeiken", blijkt dat hij het gewoon gec/p'ed heeft hehehehe

[curry684]

Voorbeeldje over hoe je ook complexe C++ code nog duidelijk op kunt kalken mbv scope prefixes: [rml]curry684 in "[ alg] waarom i als in i++"[/rml]

[Verwijderd]

Voor degene die geinteresseerd zijn om zicht te verdiepen in gestructureerd en netjes programmeren, raad ik het boek Code Complete van Steve McConnell aan. Dit is echt HET boek over dit onderwerp, er staan veel voorbeelden in over hoe het wel/niet moet in verschillende talen.

[whoami]

Verwijderd schreef op 08 November 2002 @ 11:56:
Voor degene die geinteresseerd zijn om zicht te verdiepen in gestructureerd en netjes programmeren, raad ik het boek Code Complete van Steve McConnell aan. Dit is echt HET boek over dit onderwerp, er staan veel voorbeelden in over hoe het wel/niet moet in verschillende talen.

Post misschien alle gegevens van dat boek ff in die boekenthread.

[mbravenboer]

Nielsz: *proest*

Dit is inderdaad wel grappig . Ik denk dat er wat genuanceerder (dus niet percee gelijk volledig anders ) gereageerd was als ze geweten hadden dat ik achter dat lijstje zat .

Het probleem met het lijstje wat ik ooit eens neergekwakt heb, is dat de context volledig onbreekt. Bij alle punten hoort een redenering en in ieder geval een omschrijving van de situaties waarin je op dit punt zou moeten leggen. Ik zal proberen om die als nog te te geven .

mbravenboer: 5. Vermijd het gebruik van de ... ? ... : ... constructie.
Alarmnummer: Ik gebruik hem intussen ook, het is een stuk korter dan de iflus variant.
whoami: De ternary operator ( ( ... ) ? ... : ... ; is misschien voor de beginnende programmeur niet zo duidelijk, maar in bepaalde gevallen gebruik ik hem toch ook wel.

Met het afraden van de "expr ? expr : expr" constructie, wil ik absoluut niet het nut van een conditionele expressie bestrijden. Dat nut is er zeker. De syntax die hier voor is gekozen past echter niet in een taal als Java. Het zorgt voor vrijwel de meeste obscure expressies door de plaatsing van het vraagteken achter de eerste expressie en de niet opvallende : tussen de twee mogelijke waarden. Deze onduidelijke syntax zorgt ervoor dat veel mensen het gebruiken van de conditionele expressie afraden, hoe makkelijk deze inderdaad ook is.

Als dit maar genoeg gedaan wordt, komt er misschien iemand langs die zich niet laat meeslepen door de keuzen die gemaakt zijn in klassieke talen. Er is geen enkele reden waarom niet de normale if-then-else syntax gebruikt zou kunnen worden voor conditionele expressies, net zoals deze dus al wordt gebruikt bij conditionele statements.

Hierbij moet ik nog opmerken dat het in het bijzonder gaat om deze syntax in de taal Java: in andere talen zou deze syntax wellicht heel goed passen. In Stratego is er bijvoorbeeld ook een syntax voor conditionele toepassing van een herschrijving: "cs < s1 + s2". Zoals je ziet is het vraagteken hier dus de < en de : de +. Hier zijn redenen voor: Stratego is een heel andere taal is dan de bekende imperatieve talen. Het punt is echter dat ik in Stratego deze constructie niet als obscuur beschouw: hij past goed binnen de andere constructies in Stratego. Bij de ?: in Java ligt dat heel anders, maar ik moet toegeven dat dit allemaal nogal subjectief is.

mbravenboer: 8. Vermijd het gebruik van static.
Alarmnummer: Wat is er mis met static?? Het is een heel ander type dan de 'instance' variable, maar is erg nuttig.
whoami: Ik zie eigenlijk ook niet in waarom static variablen moeten vermeden worden, ik zie het gebruik van statics niet echt als 'bad programming practice'. In het Singleton design pattern kan je zelfs niet zonder static. En ook voor andere dingen kunnen ze zeer handig zijn.

Het commentaar op het gebruik van static is gericht op twee doelgroepen: beginnende programmeurs en gevorderde programmeurs.

Bij beginnende Java programmeurs zie je vaak een worsteling met het OO paradigma. Static methoden en variabelen kunnen dan relatief eenvoudig overkomen, waardoor ze in de verkeerde situaties gebruikt worden. Allemaal heel begrijpelijk en iedereen zal het er ook wel mee eens zijn dat in deze gevallen het gebruik van static methoden afgeleerd moet worden. De opmerking slaat daarom ook eigenlijk niet op deze doelgroep.

Door gevorderde programmeurs worden static constructies over het algemeen gebruikt voor verschillende zaken. Het eerste gebruik zie je bijvoorbeeld in de getypeerde enumeraties zoals Alarmnummer die liet zien. Hier is helemaal niets mis mee, sterker nog: knappe vent die dit anders kan oplossen .

Het tweede gebruik zijn de typische tool methoden zoals je die bijvoorbeeld ziet in java.util.Collections, java.util.Arrays, javax.swing.SwingUtilities. Het gebruik van dergelijke tool methoden is op zich prima, maar ik zou hier al wel iets kritischer tegenover staan: houd goed in de gaten of je met een object georienteerde oplossing wellicht geen beter herbruikbare en aanpasbare code krijgt.

Het derde gebruik zijn de zaken waar je vanuit alle onderdelen van je applicatie snel bij wilt kunnen. Ik zie dit zelf graag als een soort 'environment': je creeert een omgeving voor je applicatie waarin je diverse onderdelen van de applicatie snel kan benaderen. Soms zie je dit terug in de vorm van fraaie geprogrammeerde Singletons, soms in een wat primitievere vorm. Met deze situaties is vaak ook niets mis, maar soms schuilt er toch wel een addertje onder het gras: is een Singleton wel echt een Singleton? Ben je er wel zo zeker van dat er altijd maar 1 instantie van deze klasse in een VM zal moeten draaien? Het probleem is hier dat Singletons vaak voorkomen in eind-applicaties en niet in componenten: bij het maken van een applicatie ga je er vanuit dat deze in 1 JVM draait en dat er geen andere instantanties van deze applicaties in deze JVM draaien. Is dat wel altijd zo?

Je zou dit laatste gebruik van static variabelen en methoden (eventueel in een Singleton ontwerp) kunnen vervangen door het gebruik van een 'environment' klasse. Deze environment kan je meegeven aan alle onderdelen van de applicatie waar deze environment noodzakelijk is en zo kan je altijd overal bij. Dit heeft zo zijn voordelen, in het bijzonder dat je er bij de implementatie van 'algemeen benaderbare functionaliteit' geen rekening mee hoeft te houden of er altijd maar 1 'algemeen benaderbare functionaliteit' in een JVM is.

Tot slot is het stukje wat Glimi schreef zeer juist:

Glimi: Kan dit veranderen in : vermijd het gebruik van non final static variabelen (constanten) Hoewel ze soms nuttig zijn (Singleton bijv) is er een reden voor het vermijden, nl. overerving. Een static method/variabele hoort bij de class. Als hij wordt overgeërft, komt de static method/var niet mee.

mbravenboer: 9. Gebruik een Iterator ipv een Enumeration, ArrayList ipv Vector, HashMap ipv Hashtable
Alarmnummer: Als je een gesynchroniseerde structuur nodig hebt, dan is een Vector of een Hashtable interessanter dan een ArrayList of Hashmap omdat de laatsten niet gesynchroniseerd zijn. Je kan trouwens wel een gesynchroniseerde versie van de laatste 2 maken, door ze in een sychronized wrapper te plaatsen. Zie hiervoor de Collections class.

Het wrapper ontwerp vindt ik aantrekkelijker omdat je zo vanuit jouw oogpunt maar met 1 implementatie voor lijsten te maken hebt. Op dit moment zijn er twee verschillende implementaties voor de verschillende typen verzamelingen: de oude en de nieuwe. De oude implementaties zouden er nooit geweest zijn als de Java Collections al gelijk geintroduceerd waren.

Overigens speelt dit probleem eigenlijk helemaal niet als je gewoon zoveel mogelijk gebruik maakt van de interfaces voor de verschillende typen verzamelingen (List, Map en dergelijke). De tip had daarmee zeker aangevuld moeten zijn, omdat dat in feite het belangrijkste punt is.

mbravenboer: 13. Eet je exceptions nooit op door ze simpel naar de System.out te schrijven. Gooi ze zover door als noodzakelijk is.
Alarmnummer: Je eet hem niet op door hem in de out te gooien hoor. Wat jij bedoelt is dit: ...

Ik drukte me inderdaad wat ongelukkig uit omdat onder het opeten van exceptions vaak (zoals je zelf al aangaf) afvangen zonder enig side-effect wordt verstaan. Dit bedoelde ik echter niet met deze tip: veel mensen hebben de neiging om exceptions te snel af te handelen. Vaak loopt dit erop uit dat je eigenlijk niet weet wat je met de exception moet doen en hem dus maar op System.out neerkwakt. Dit zou je een minder ernstige vorm van opeten kunnen noemen. Het is goed om na te blijven denken over de exceptions en ze niet direct bij het gebruik van de library op te willen vangen: zou de methode de exception niet gewoon door kunnen gooien? Je moet dus goed nadenken over de plek waarop je de exception uiteindelijk af wilt vangen en dit is vaak de plaats waar je er ook wat zinnigs mee kan doen.

mbravenboer: 14. Roep altijd de super constructor aan.
Alarmnummer: Gebeurt al automatisch hoor als je super constructor argumentloos is.

Met deze tip probeer ik mensen ertoe te bewegen om na te denken over de constructie van objecten. Juist het feit wat jij aangeeft (automatische creatie van constructor aanroep) zorgt ervoor dat er verwarring ontstaat rond het aanroepen van constructorern. Door de expliciete super constructor aanroep besef je altijd dat deze constructor eerst wordt aangeroepen. Er zijn helaas veel mensen die denken dat die constructor niet aangeroepen wordt als er geen super aanroep staat!

-----------

Eigenlijk zouden dus alle punten toegelicht moet worden, maar het is wel een uitdaging om zo'n toelichting nog inzichtelijk te houden voor de doelgroepen van de handleiding: beginnende programmeurs. De uitleg is helaas vaak gebaseerd op ervaringen en redereringen over termen die een beginnende programmeur nog niet kent.

-----------
PS: ik kan helaas niet in discussie gaan, dat laat mijn strenge internet-regime ivm telefoonkosten niet toe . Ik probeerde in deze reply het een en ander duidelijk te maken omdat ik duidelijk onduidelijk was .

[Verwijderd]

Het kan aan mij liggen maar wordt de hungarian notation of zoiets dergelijks helemaal vergeten in dit topic ?
Dus

code:

String strStringNaam = new String();
int intGetalWaarde = 0;

bij mij op het werk is deze notatie in java gegroeid omdat we eerst met VB bezig waren.

zie : http://support.microsoft....px?scid=KB;EN-US;Q173738&

meer over hungarian notation op google :
http://www.google.nl/sear...=UTF-8&oe=UTF-8&hl=nl&lr=
En natuurlijk met de prefixes (hoewel ik die niet echt noodzakelijk vindt (maar dat komt meer doordat ik gewoon veel op JBuilder's "explorer" leun om te zien wat voor variabele is (static member, public etc etc)

[indekmode]
Maar dat ik het over het hoofd heb gezien kan natuurlijk ook
[/indekmode]

Voor de rest vindt ik het top dat er aandacht wordt besteed aan de structuur en bouw van je eigen code ... ik zie vaak genoeg te veel spagettie code
(kun je nagaan hoe vaak de FAQ gelezen wordt als ik het nog veel zie

[D2k]

Verwijderd schreef op 08 november 2002 @ 16:39:
Het kan aan mij liggen maar wordt de hungarian notation of zoiets dergelijks helemaal vergeten in dit topic ?

zoek er eens een mooi linkje bij

Voor de rest vindt ik het top dat er aandacht wordt besteed aan de structuur en bouw van je eigen code ... ik zie vaak genoeg te veel spagettie code

staat al eeuwen in de faq


* D2k zal binnenkort wel eens gaan re-writen

[whoami]

[nohtml]

Verwijderd schreef op 08 november 2002 @ 16:39:
Het kan aan mij liggen maar wordt de hungarian notation of zoiets dergelijks helemaal vergeten in dit topic ?

Tja, hierover verschillen de meningen nogal 'grondig'. Sommigen vinden hungarian notation handig, anderen vinden het overbodig en vinden dat het leidt tot onduidelijke variable namen. Ik reken mezelf tot de laatste groep.
Ik ben van mening dat je maar goeie variablenamen moet kiezen, dan is de nood aan 'Hungarian notation' imho overbodig. Een variable 'KlantNaam' zal wel een string zijn en geen integer, een variable 'Afgewerkt' zal wel een boolean zijn, ....
Ook MS is ondertussen van de hungarion notation afgestapt in hun .NET verhaal.
Zie ook dit topic :
[rml][ ALG] .NET: Geen Hungarian Coding meer! *sniff*[/rml]

[maikel]

In C# gebruik ik ook altijd de 'regions':

code:

#region Public Methods
public void Method1(string blabla, int val)
{
}
#endregion

#region Private Methods
private int ReturnSum(int val1, int val2)
{
      return val1 + val2;
}
#endregion

Voordeel hiervan is dat je verschillende blokken in je code krijgt met: public methods, private methods, properties, etc.
Tevens zijn die blokken (in VS.Net) in te klappen zodat er een deel van je code niet zichtbaar is. Dit kan erg handig zijn als je met andere delen van de class bezig bent omdat het een stuk overzichtelijker is en een (in verhouding) stuk kortere file.

Overigens is het wel jammer dat je in het typen van een post geen tabs kunt gebruiken. Ik heb al een aantal keer gehad dat ik wat code wilde posten die halverwege een method staat. Dan begin je hier dus al met bijv. 4 tabs inspringen. Mocht je er dan een teveel weghalen (zodat een regel niet meer in ingesproken tov de regel er voor), moet je een tab gaan copy/paste'en.

[Glimi]

maikel schreef op 09 november 2002 @ 13:52:
In C# gebruik ik ook altijd de 'regions':

Ik zie er het nut niet zo van in.
• In VS.NET heb je toch al de mogelijkheid om direct naar je methodes te springen (in elke fatsoenlijke ide eigenlijk )
• In editors die het niet onderstuenen heb je ook niets aan zo'n region
• Ik probeer m'n classes altijd zo klein mogelijk te houden en methodes die bewerkingen doen in Visitors te zetten. Hierdoor heb ik vaak iets van 2* aantal vars + 5 methodes ( constructor, hashcode(), equals(), toString(), accepts() ) in een class
• Mensen lezen eigenlijk nooit m'n classes Daar heb ik documentatie voor, dus voor die mensen hoef ik het ook niet te doen

[whoami]

Eigenlijk is het wel handig hoor, die regions. In VS.NET kun je zelfs niet alleen die 'regions' collapsen, maar ook de functiedefinities, zodat je enkel de functie-signature ziet.
Dat bevordert de duidelijkheid/overzichtbaarheid behoorlijk!
Eens je ze gewend bent, kun je niet meer zonder.

[Glimi]

whoami schreef op 09 November 2002 @ 14:24:
Eigenlijk is het wel handig hoor, die regions. In VS.NET kun je zelfs niet alleen die 'regions' collapsen, maar ook de functiedefinities, zodat je enkel de functie-signature ziet.
Dat bevordert de duidelijkheid/overzichtbaarheid behoorlijk!
Eens je ze gewend bent, kun je niet meer zonder.

Ook dat kan elke fatsoenlijke IDE (idea bijv )

[Verwijderd]

Zie sig voor mijn coding guidelines . Deze zijn voor een klein deel op die van GoT gebaseerd, maar richten zich alleen op C#. Verder worden ook een aantal samenhangende punten behandeld, zoals commentaar etc.

[eamelink]

mysql_select_db("$dbnaam",$connect)
echo "$sql222";
print_r("$var");

Waarom al die quotes om de variabelen heen?
Bij die eerste geef je toch gewoon die variabele door, het is al een string.
2e ook.
Die derde is zelfs gewoon fout, want je weet niet of $var wel een string is. Als hij het zeker weten is, dan kan je gewoon print doen.

[D2k]

*kick*
nog opmerkingen die nog verwerkt moeten worden?
ik wil dit weekend eraan gaan beginnen namelijk

opm van woudloper:

[offline] Hey D2k, ik zat ff de FAQ van P&W te lezen (moet je eens in de zoveel tijd weer eens doen) en daar constateerde ik dat een reeks van de PHP tags niet werkte....

Ik weet niet of je er tijd voor hebt om het aan te passen, maar zou wel handig zijn!? Wanneer wordt overigens het gebruik van de CODE tag (met verschillende talen) toegevoegd? Nu syntax highlighting werkt voor meerdere talen is dat wellicht handig

[whoami]

D2k schreef op 28 november 2002 @ 10:28:
*kick*
nog opmerkingen die nog verwerkt moeten worden?
ik wil dit weekend eraan gaan beginnen namelijk

opm van woudloper:

[...]

Ehm, niet direct van mijnentwege. Mocht er nog iets zijn, dan laat ik het je wel weten, dan kan je het nog eens aanpassen.

[drm]

Ik denk dat het sowieso niet verkeerd is om de FAQ anders in te delen.

Ik keek vorige week eens in Technische PMG FAQ en ik moet zeggen dat ik daar wel een beetje jaloers op was (complimenten aan de mods daar )

Onze FAQ daarentegen is 1 grote zwik aan tekst etc, waar eigenlijk heel slecht doorheen te navigeren is. Is het wat om er sowieso een RFC over te openen, en de FAQ compleet te herindelen?

Neem even een kijkje door die PMG faq, en dan snap je wel ongeveer wat ik bedoel.

[D2k]

drm schreef op 28 november 2002 @ 10:32:
Ik denk dat het sowieso niet verkeerd is om de FAQ anders in te delen.

Ik keek vorige week eens in [NOHTML]Technische PMG FAQ[/NOHTML] en ik moet zeggen dat ik daar wel een beetje jaloers op was (complimenten aan de mods daar )

Onze FAQ daarentegen is 1 grote zwik aan tekst etc, waar eigenlijk heel slecht doorheen te navigeren is. Is het wat om er sowieso een RFC over te openen, en de FAQ compleet te herindelen?

Neem even een kijkje door die PMG faq, en dan snap je wel ongeveer wat ik bedoel.

hmmz op zich wel een idee
ik zal er eens over denken om het in die vorm te gieten

[drZymo]

Goed topic. Ik heb niet alle replies helemaal doorgelezen, omdat ik toch mijn eigen stijl houd en die niet echt veel ga aanpassen. Maar mischien heb ik nog wat tips voor de C(++) proggelaars onder ons.

1) Probeer alle expressie met zoveel mogelijk haken te schrijven. Ook al heb je geleerd dat bepaalde haken weg mogen vanwege de hierarchie, het kan de duidelijkheid goed bevorderen. In plaats van a || b && c is a || (b && c) iets duidelijker (IMHO).

2) Schrijf alle types die je introduceert met hoofdletters. En definieer gelijk een pointer van die type (die punt 3).
Dus:

C++:

typedef struct _MYSTRUCT {
    int i;
    float f;
    bool b;
} MYSTRUCT, *LPMYSTRUCT;

Hierdoor is goed te zien wat types zijn en wat variabelen zijn.

3) Gebruik vooraf gedefinieerde pointer types. Dit kan de duidelijkheid in de declaraties wat bevorderen en ben je gelijk van de discussie af waar het *'tje hoort .

C++:

// dus niet zo
char *mystring, *again;

// maar zo
typedef char* LPCHAR;
LPCHAR mystring, again;

Uhm ja en dat waren ze eventjes, mochten er meer binnen schieten dan laat ik ze wel weten. Het gaat allemaal nog niet zo snel zo voor 12u .

Let op dit zijn mijn tips, geen verplichtingen natuurlijk.

[whoami]

drZymo schreef op 28 november 2002 @ 11:03:
Goed topic. Ik heb niet alle replies helemaal doorgelezen, omdat ik toch mijn eigen stijl houd en die niet echt veel ga aanpassen. Maar mischien heb ik nog wat tips voor de C(++) proggelaars onder ons.

1) Probeer alle expressie met zoveel mogelijk haken te schrijven. Ook al heb je geleerd dat bepaalde haken weg mogen vanwege de hierarchie, het kan de duidelijkheid goed bevorderen. In plaats van a || b && c is a || (b && c) iets duidelijker (IMHO).

*Eensch is*

2) Schrijf alle types die je introduceert met hoofdletters. En definieer gelijk een pointer van die type (die punt 3).
Dus:

C++:

typedef struct _MYSTRUCT {
    int i;
    float f;
    bool b;
} MYSTRUCT, *LPMYSTRUCT;

Hierdoor is goed te zien wat types zijn en wat variabelen zijn.

Hier zie ik het nut niet van in... Waarom declareer je direct ook een pointer naar dat type? Dan heb je een globale variable toch? (Afhankelijk van de plaats waar je die struct definieert dan.
De naamgeving en het gebruik van hoofd-kleine letters, is ook wel afhankelijk van de taal die je gebruikt. Ik zie dat jij je types volledig in hoofdletters schrijft, en de namen van je variablen ook. Dat is imho dan, niet echt leesbaar.
Ik gebruik meestal pascal-casing:

code:

class MyClass
{
    int         _a;
    int         _b;
}

MyClass myObject;

3) Gebruik vooraf gedefinieerde pointer types. Dit kan de duidelijkheid in de declaraties wat bevorderen en ben je gelijk van de discussie af waar het *'tje hoort .

C++:

// dus niet zo
char *mystring, *again;

// maar zo
typedef char* LPCHAR;
LPCHAR mystring, again;

Hmm, ,ja, dat kun je zo doen (als de taal het toelaat), maar ik vind het zowiezo duidelijker als je slechts 1 variable op een regel declareerd:

code:

char* mystring;
char* again;

Let op dit zijn mijn tips, geen verplichtingen natuurlijk.

Dit geldt natuurlijk voor alle opmerkingen in dit topic.

[drm]

mja, je kunt er hoog en laag over discussieren, maar dat laatste met die gedefinieerde types, daar ben ik het dus helemaaal niet mee eens. Je haalt eigenlijk een beetje de syntax van de taal onderuit, als je dat soort dingen gaat doen.

En ja, ik ben ook iemand die een hekel heeft aan macro's

edit:

Oh en dat eerste puntje over die haken daar was ik 't trouwens wel mee eens, dus.

[ Voor 14% gewijzigd door drm op 28-11-2002 11:25 ]

[D2k]

drm schreef op 28 november 2002 @ 11:11:
mja, je kunt er hoog en laag over discussieren, maar dat laatste met die gedefinieerde types, daar ben ik het dus helemaaal niet mee eens. Je haalt eigenlijk een beetje de syntax van de taal onderuit, als je dat soort dingen gaat doen.

En ja, ik ben ook iemand die een hekel heeft aan macro's

*aansluit*

[Alarmnummer]

drm schreef op 28 november 2002 @ 11:11:
En ja, ik ben ook iemand die een hekel heeft aan macro's

Ik vind macro`s eigelijk wel oke. Er zijn veel taal 'constructies' waar ik voorheen een hekel aan had, zoals oa pointers. Maar de meeste technieken zijn wel handig, alleen moet je wel weten wanneer je ze goed gaat inzetten. Als je een taal allerlei features moet verwijderen omdat de gemiddelde gebruiker ze niet correct kan inzetten, wil niets zeggen over de features maar eerder over de gebruiker. Hetzelfde geld voor macro`s. Je kan ze idd helemaal verkeerd inzetten en de leesbaarheid volledig onderuit halen, maar je kan ze ook perfect gebruiken om bv debug code in te bakken.

[Woudloper]

D2k, mooi dat je er dit weekeind aan gaat beginnen en grappig dat je mijn icq'te had gequote. En zoals ik al gezegd had, heb het redelijk druk dus dit topic was mij weer voorbij geschoten.

Wat drm zeg is ok wel waar! Die faq van hun ziet er erg goed en gestructureerd uit. Dat kan voor de nieuwelingen erg handig zijn al zeg ik hetzelf. Je houdt zo de verschillende onderdelen compact en gegroepeerd bij elkaar!

Overigens heb ik er vrij weinig aan toe te voegen. Wel moet het zo zijn dat het niet een handleiding moet gaan worden, maar echt iets in de trant van een FAQ, daarbij rekening houdend dat wanneer er (toch) vragen gesteld gaan worden door de nieuwelingen wij (als ouderen) hun code's moeten lezen en gaan snappen wat zij willen. Dus goed gebruik makend van de code tags, inspringen e.d. zodat wij snel zien wat er (al dan niet) mis is met de code.

[D2k]

ow ik zoek nog mensen die alle linkjes gaan proberen
dan kunnen we wat ook opschonen

[Vaudtje]

Wat ik erg irritant vind aan de PMG FAQ is dat elke link waar ik op klik meteen een venter opent. Ik ga ervanuit dat dit komt doordat Topix React alle links in een nieuw venster opent, maar voor links binnen GoT doet 'ie dat toch niet?
Als ik een nieuw venster wil voor en link binnen de FAQ, hab ik altijd mijn shift-toets nog.

[ Voor 4% gewijzigd door Vaudtje op 28-11-2002 12:29 . Reden: met dank aan CowMike ]

[Woudloper]

D2k schreef op 28 november 2002 @ 11:40:
ow ik zoek nog mensen die alle linkjes gaan proberen
dan kunnen we wat ook opschonen

Da's makkelijk! Er zijn namelijk ook gewoon 'online link checkers'. Wellicht hebben deze geen access tot P&W, maar dan kan je gewoon de pagina even saven as html en ergens anders neer zetten....

Eenvoudig toch

edit:
en wat Vaudje zegt, daar ben ik het ook meer eens Liever gewoon alles in dezelfde browser houden. Ik geloof overigens dat je via Mozilla (Lite, weet de naar even iet) een soort van extra feature kan toevoegen dat er altijd het huidige window wordt gebruike

[ Voor 28% gewijzigd door Woudloper op 28-11-2002 11:59 ]

[Verwijderd]

Als ik dit allemaal zo lees, heeft iedereen zo zijn eigen style. Het belangrijkste vind ik toch wel dat het overzichtelijk moet zijn zodat het te lezen is. Een Newbie heeft veel aan deze topic omdat die vaak moeilijk te helpen zijn. Hun code is namelijk vaak een zootje.

[Verwijderd]

Vaudtje schreef op 28 November 2002 @ 11:57:
Wat ik erg irritant vind aan de PMG FAQ is dat elke link waar ik op klik meteen een venter opent. Ik ga ervanuit dat dit komt doordat Topix alle links in een nieuw venster opent, maar voor links binnen GoT doet 'ie dat toch niet?
Als ik een nieuw venster wil voor en link binnen de FAQ, hab ik altijd mijn shift-toets nog.

Topix? React zul je bedoelen

D2k: ik wil wel helpen met het doorlopen van de linkjes...

[D2k]

Verwijderd schreef op 28 november 2002 @ 11:58:
[...]


Topix? React zul je bedoelen

D2k: ik wil wel helpen met het doorlopen van de linkjes...

linkjes niet in een nieuw venster openen kan wel, en dat ga ik ook proberen (kijk maar naar de huidige faq, de linkjes met een #iets blijven in hetzelfde venster)

Cowmike: is goed, zal ik je de lijst mailen?
(vanavond dan)

[Vaudtje]

Verwijderd schreef op 28 november 2002 @ 11:58:
Topix? React zul je bedoelen

Oeps...idd

[ Voor 17% gewijzigd door Vaudtje op 28-11-2002 12:30 . Reden: edit knop is weer verschenen ]

[Woudloper]

ff wat pauze tijd over.... Zie hieronder de opmerkingen over het eerste stukje...

Opmerkingen betreffende de links:

• Onder het kopje [url= Welkom in P&W (FAQ-19/02/2003)] Wat moet ik weten voor ik een topic plaats?
• [/url] de volgende constateringen: [list]
• de link naar de search werkt niet.
• de link naar het profiel van D2k is nog van de topix tijd
• [/list]
• Onder het kopje [url= Welkom in P&W (FAQ-19/02/2003)] Wat mag wel en wat mag niet?
• [/url] is de verwijzing naar [i] Policy mbt UTFS en RTFM[/i] wel goed, maar dat topic moet nog even een html conversie krijgen.
• Onder het kopje Ik wil graag ff die exe openmaken mag dat? werkt de link naar cutter niet.
• Onder het kopje UTFS /RTFM slotje roepen? is de link naar dit topic goed, maar het topic moet nog worden aangepast in html.
• Onder het kopje Wie zijn hier de Moderators? kloppen de links naar de user profiles van de mods niet meer.

[drm]

* drm is iig sterk voor een scheiding inhoudelijke en policy FAQ
2 topics, dus.

Alarmnummer:
Ik vind macro`s eigelijk wel oke. Er zijn veel taal 'constructies' waar ik voorheen een hekel aan had, zoals oa pointers. Maar de meeste technieken zijn wel handig, alleen moet je wel weten wanneer je ze goed gaat inzetten. Als je een taal allerlei features moet verwijderen omdat de gemiddelde gebruiker ze niet correct kan inzetten, wil niets zeggen over de features maar eerder over de gebruiker. Hetzelfde geld voor macro`s. Je kan ze idd helemaal verkeerd inzetten en de leesbaarheid volledig onderuit halen, maar je kan ze ook perfect gebruiken om bv debug code in te bakken.

Da's waar

[Verwijderd]

/me is 't met de meeste voorbeelden van overzichtelijk coden eens
En zoals door iedereen beaamt wordt, is 't toch vooral (voor de gevorderde progger) een kwestie van aanleren, gewenning en eigen inzicht.

maikel schreef op 09 november 2002 @ 13:52:
In C# gebruik ik ook altijd de 'regions'

Ja, ideaal die regions!
Ik ben er voor om je classes en methods zo compact mogelijk te houden en dan is 't idd zo da t je in VS.NET die al in kunt klappen, maar voor bijvoorbeeld een for-lus, voor een if- of switch-constructie, gebruik ik op zeker die #region

drm schreef op 28 November 2002 @ 12:29:
/me is iig sterk voor een scheiding inhoudelijke en policy FAQ
2 topics, dus.

Mee eens, maar misschien zelfs wel meer dan 2 sticky topics:
- quick start
- policy faq
- code guidelines
- handige links
- goede boeken (het boekentopic is inmiddels zo onoverzichtelijk geworden )
...

[D2k]

nee das teveel sticky
we gaan trug naar minder
* D2k zal wel eens nadenken over het eea

[whoami]

Verwijderd schreef op 28 November 2002 @ 18:23:
/me is 't met de meeste voorbeelden van overzichtelijk coden eens
En zoals door iedereen beaamt wordt, is 't toch vooral (voor de gevorderde progger) een kwestie van aanleren, gewenning en eigen inzicht.

[...]

Ja, ideaal die regions!
Ik ben er voor om je classes en methods zo compact mogelijk te houden en dan is 't idd zo da t je in VS.NET die al in kunt klappen, maar voor bijvoorbeeld een for-lus, voor een if- of switch-constructie, gebruik ik op zeker die #region

Ownee, dat vind ik niet. Die regions zijn prachtig, maar je mag er niet mee overdrijven. Een if of een lus oid inklapbaar maken vind ik not done eigenlijk. Ik gebruik die regions wel altijd om 'secties' in m'n code te maken.
Zo bv:

code:

class MyClass
{

    #region Constants
    private const string EenConstanteString = "blaat";
    #endregion

    #region Attributes
    private int      _id;
    private string _naam;
    #endregion

    #region Properties
    public int id
    ....
    #endregion

    #region Private methods
    #endregion
   
    #region Public Methods
    #endregion

}

Echt, code (zoals de code binnen een if ) binnen een region steken, vind ik niet zo goed. Je leest er makkelijk over.

- quick start
- policy faq
- code guidelines
- handige links
- goede boeken (het boekentopic is inmiddels zo onoverzichtelijk geworden )
...

Eensch is. Nouja, gedeeltelijk dan.
Goede boeken kan in een sticky, waar de meeste titels uit dat boekentopic met wat extra info enzo opgenomen worden + een linkje naar dat topic.
De quick start en de policy FAQ kunnen misschien samengevoegd worden, en dan maak je nog een inhoudelijke FAQ met daarin de items zoals de coding guidelines, handige links, goede boeken.

[Woudloper]

* Woudloper vindt meer dan twee (2) sticky's wel erg veel. Liever houdt ik het op een max. van 2.

Overigens D2k, de eerste opzet ziet er goed uit

[D2k]

mjah die opzet wordt het niet nog

gisteravond zijn * drm en * D2k aan het brainstormen geweest

wat ik wel weet is dat het niet op 1 dag klaar zal zijn, daarvoor is het teveel werk

[D2k]

goed, drm had dit als voorstel
maar dan moeten we dus mensen hebben die kleine stukjes aan gaan leveren over de talen
dus ik zou zeggen: Leef jullie uit (per mail svp)

drm schreef op 28 November 2002 @ 20:50:

edit:

En om de spirit er alvast goed in te gooien:
<style>ul, li { list-style-type:circle; margin-top:0; margin-bottom:0; padding-top:0; padding-bottom:0; line-height:13px; }</style>
<ul><li>FAQ<ul><li>Hoe gebruik ik de FAQ?</li><li>Quickstart<ul><li>Hoe start ik een topic?</li><li>Wanneer open ik een topic?</li><li>Sfeerbepalers</li></ul></li><li>Inhoudelijk<ul><li>Taal a<ul><li>Wat is het voor taal? (stukje geschiedenis?)</li><li>Waar gebruikt men het voor?</li><li>Handige links<ul><li>handig linkje 1</li><li>handig linkje 2</li></ul></li><li>Wat zijn goede boeken?<ul><li>boek 1 + isbn</li><li>boek 1 + isbn</li></ul></li></ul></li><li>Taal b, etc...</li><li>C :+</li></ul></li><li>Beleid<ul><li>Wat is toegestaan?</li><li>Wat moet je echt niet flikken?</li><li>Mods hebben 't laatste woord :P</li></ul></li></ul></li></ul>

Dit was zo'n beetje mijn idee van de structuur in de FAQ... Commentaar hier posten, dus

Toelichting: niveau 1 vindt men op elke FAQ topic terug (soort nav), niveau 2 zijn dus allemaal aparte topics, met een korte toelichting en een overzicht van de inhoud van dat topic, met anchor points (#) naar de lagere niveau's.

zoiets dus.

[whoami]

Hmmm.
Ik denk dat die 'taal-secties' die FAQ onnodig groot gaan maken. 't is hier Tweakers, dus denk ik wel dat we er mogen vanuitgaan dat de meeste mensen wel eea weten over de taal die zij gebruiken en de andere talen die beschikbaar zijn. En als dat niet het geval is, heb je nog altijd Google ed.

[drm]

Wat is er op tegen om een uitgebreide FAQ te hebben? Hoe meer "faq"'s beantwoord worden inde FAQ, hoe beter, lijkt mij... toch?

[Verwijderd]

Talen / platformen
- PHP
- Java
- Perl
- XML/XSL(T)/X...
- .Net (incl ASP.Net, ADO.Net, C# en VB.Net)
- ASP (VBscript / JScript / ADO)
- Visual Basic (pre .Net, ADO verwijzing naar ASP)
- SQL (incl. database specifieke stukken)

Wat ik nog wel mis is een stukje over algemene zaken zoals:
- OO (incl patterns)
- good practices (taal onafhankelijk)
- software design

[D2k]

Verwijderd schreef op 29 november 2002 @ 13:47:
Talen / platformen
- PHP
- Java
- Perl
- XML/XSL(T)/X...
- .Net (incl ASP.Net, ADO.Net, C# en VB.Net)
- ASP (VBscript / JScript / ADO)
- Visual Basic (pre .Net, ADO verwijzing naar ASP)
- SQL (incl. database specifieke stukken)

juist datte

Wat ik nog wel mis is een stukje over algemene zaken zoals:
- OO (incl patterns)
- good practices (taal onafhankelijk)
- software design

staat er idd niet in vermeld (foei drm ) maar het netcoden enzo komen ook weer trug (en jouw SOAP/XML verhaal enzo)