[FAQ] De FAQ & Richtlijnen van P&W *updated 20-10

[ACM]

In het P&W forum zijn een aantal regels/richtlijnen van toepassing,
Lees deze voor je hier gaat posten!:


<hr>


• Voor je een topic plaatst

• Wat mag wel en wat mag niet?

• UTFS /RTFM slotje

• Over huiswerk

• Moderators

• Wat moet waar?

• Links

• Algemene info


• XML/ XSL/ SOAP

• Database indexing


<hr>


• <a name="1">Voor je een topic plaatst</a>
Iedereen is natuurlijk welkom, en er kunnen natuurlijk botsingen ontstaan tussen bezoekers met een verschillend niveau. Newbies die zich aan profs ergeren omdat die weigeren het op hun niveau uit te leggen, of profs die zich aan newbies ergeren omdat ze zelf geen moeite hebben gedaan.
Het is belangrijk dat je eerst even de volgende punten nagaat. Als je denkt dat alles goed is kun je je topic plaatsen en is de kans dat er een slotje opkomt nihil.


• Gebruik eerst de search om te kijken of je vraag niet al eerder is geweest!

• Ga vervolgens kijken of je het antwoord niet kan vinden in een manual of tutorial. Zie ook het links-overzicht onderaan. Simpele RTFM-vraagjes zijn niet welkom!

• Zorg dat je topic-title duidelijk is, maak een duidelijke omschrijving en zet vooraan tussen haakjes om welke taal het gaat (indien van toepassing).

• Maak een duidelijke omschrijving van je probleem:

• Vermeld om welke taal het gaat. [php][C/C++][JAVA] enz enz
• Geef aan wat er fout gaat, en eventueel wat voor foutmelding je te zien krijgt en op welke regel de fout staat.
• Copy/paste eventueel het script als dat nodig is voor het oplossen van het probleem. Bij PHP scripts kun je deze tussen [php]-tags parkeren zodat het beter leesbaar is. Overige scripts kunnen tussen [code]-tags.


• Lees voor je je topic gaat plaatsen eerst je bericht nog eens door.
Kijk ook of het geen klein foutje is zoals het vergeten van een ; aan het einde van een regel. Lees ook het stuk van D2k over code debuggen en netjes opmaken hieronder eens door


<hr>


• <a name="2">Wat mag wel en wat mag niet?</a>
Vooralsnog hebben wij niet echt regels in P&W. Het enige wat wij niet toestaan zijn RTFM-vraagjes en 'Ik-zoek-dit-script'-vraagjes of het wijzen hierop op kinderlijke wijze.
Zie oa. Policy mbt UTFS en RTFM.
Ook het zoeken naar personeel is niet toegestaan, daarvoor zijn sites als Monsterboard.nl.

Waar men hier ook niet bij wil helpen is het "vragen over dingen waar licenties mee gebroken worden", dit geld dus ook voor opensource (gpl'ed bijv.) software.
Ook voor "geleende" scripts (al dan niet met toestemming, voor zover nodig, van de maker) willen we graag dat je in eerste instantie contact opneemt met de maker van die software.
Over offtopic-gedrag kunnen wij ook simpel zijn: probeer het gewoon gezellig te houden, een keer offtopic praten kan best (heel de dag lullen over variabelen is ook niet echt alles ) maar ga niet met opzet serieuze threads offtopic helpen of kijken hoever je kunt gaan, dat gaat er bij ons niet in.


Policy mbt het omhoogschoppen van threads. Wacht minstens 24 uur voor je je topic omhoog schopt. Doe dit dan ook alleen met een zinnige opmerking en dus niet met "Waarom antwoord er nou niemand" nadat je 5 minuten geen antwoord hebt gehad. Sommigen van ons hebben een leven

Policy mbt decompilen en reverse engineren. Dit is in principe gewoon illegaal (net als cracks, passes, warez etc) en voor ons daarom niet/nauwelijks na te gaan of er wel of niet illegaal gedrag getoond wordt. Daarom hebben we besloten het als illegaal te beschouwen en zijn dit soort topics niet gewenst.


<hr>


• <a name='3'>UTFS /RTFM slotje</a>


• Waar gaat het nou om?
Lees eerst dit eens dan is je het eea. al duidelijk.
In /14 is er een periode geweest waar om de haverklap 'slotje!' en 'utfs!' werd geroepen. Dit is al flink verminderd maar de geschiedenis leert dat de geschiedenis zich herhaalt en ik weet uit ervaring dat /14 zeker geen uitzondering is

• Wat zijn de consequenties?
Bij herhaaldelijk UTFS en RTFM en Slotje roepen word je gewaarschuwd.
Eventueel word je post zelfs verwijderd. Bij de 2e waarschuwing volgen andere maatregelen - welke dat zijn hangen af van je gedrag.

Ik hoop samen met jullie dat dit zal leiden tot een positievere sfeer, en dat newbies zich nog welkomer zullen voelen.

• Laatste opmerking
Mogen mensen nu ongestoord domme vragen stellen? Nee, uiteraard niet. Als iets echt heel makkelijk te vinden is dan had die persoon even mogen zoeken. En als het echt zo makkelijk te vinden is dan kun je die link er ook even bijplaatsen met de opmerking dat hij/zij de volgende keer daar eens moet zoeken.


<hr>


• <a name='8'>Over huiswerk</a>


Het is vanaf nu (dus niet met terugwerkende kracht en daar wil ik ook geen gezeik over) toegestaan om huiswerk te plaatsen.
Mits het aan een aantal eisen voldoet.

• Je geeft duidelijk een beschrijving van je opdracht en je probleem.
• Je geeft ook duidelijk aan wat je al geprobeerd hebt.
• Je moet niet vergeten, dat je het huiswerk hoort te kunnen maken, met alleen je studiemateriaal en de eventuele hulp van docenten/assistenten en medestudenten.
• Zodra de vraag richting "maken jullie het dan even" gaat, dan gaat je topic zonder meer op slot.
• Verder gelden natuurlijk ook hiervoor de standaard voorwaarden uit de algemene en subforum faq.


Mocht je na dit alles er nog niet uitkomen en zeker weten dat men je hier kan helpen, dan kan je er een topic voor plaatsen.
Wees dan wel eerlijk en zet er gewoon bij dat het huiswerk is, dat maakt het een stuk makkelijker voor de mensen die je helpen om je "niveau in te schatten".

Verder, succes met school.
En laat het forum netjes


<hr>


• <a name="4">Moderators</a>
Momenteel lopen er een aantal moderators rond in de Devschuur/P&W die helpen om crap te closen. Natuurlijk zien wij ook niet alles en zijn er altijd users die het eerder zien dan wij. Hieronder een lijstje met moderators die in P&W rondlopen:

• ACM
ICQ: 37976900 | mail: [e-mail]
• chem
ICQ: 20710967/98343967 | mail: [e-mail]
• Tom
ICQ: 33401632
• wasigh
ICQ: 83548857 | mail: [e-mail]
• OzBoz
ICQ: 449804 | mail: [e-mail]
• McVirusS
ICQ: 19909059 | mail: [e-mail]


Voor vragen kun je eventueel ook terecht in:
[moderatie] Vragen aan de moderator


Zodra je iets tegenkomt wat in jouw ogen niet kan of tegen de richtlijnen is, kun je even een seintje geven aan een modje. Een andere mogelijkheid is een post te plaatsen in 'Stoute usertjes', daar kijken ook regelmatig moderators.


<hr>


• <a name="5">Wat moet waar?</a>

De scheiding tussen WD&G en P&W is eigenlijk:

• javascript/dhtml/flash etc -> WD&G
• asp/php/jsp etc -> P&W


Dit omdat je javascript primair gebruikt voor layout-technische dingen en asp/php/jsp voor inhoud-technische dingen.

Oftewel, dezelfde scheiding blijft eigenlijk gewoon van pas.
(webdesign/layouting naar WD&G, Webscripting (inhoudelijk dus) naar P&W)

En om de scheiding dan makkelijk aangeefbaar te houden, gaat liefst alle javascript naar WD&G.


Als je een echt zwaar programmeertechnisch iets hebt, dan is dat hier dus wel welkom.


<hr>


• <a name="6">Links</a>
Op internet is ontzettend veel kant-en-klare informatie te vinden. Hier alvast een opstapje om scripts, tutorials en manuals te vinden:


• Algemeen:

• Hoe groot is de database van tweakers.net
• http://www.hotscripts.com
• http://www.sourceforge.com
• http://www.programmersheaven.com
• http://www.w3schools.com
• http://www.irt.org
• http://www.developersdex.com
• http://www.pageresource.com
• http://hotwired.lycos.com/webmonkey
• http://www.programmingtutorials.com/main.asp
• Welke editor is het best?
• http://www.zdnet.com/developer/
• http://www.faqts.com/
• Uitleg over Greediness bij regexpen
• Lijst van de Internet standaarden (rfc) (onder andere tcp/ip, http etc)
• http://www.users.f2s.com/faq/htaccess.php3
• http://www.bruce-hamilton.com/tutorials/password.shtml#password

• VB/ASP:

• http://msdn.microsoft.com
• http://www.4guysfromrolla.com
• http://www.aspin.com
• http://www.asp101.com
• http://www.activeserverpages.com
• http://www.learnasp.com/learn/


• C:

• http://www.cm.cf.ac.uk/Dave/C/CE.html
• http://www.cprogramming.com
• http://www.howstuffworks.com/c.htm
• http://www.zib.de/Visual/people/mueller/Course/Tutorial/tutorial.html
• http://www.scorpioncity.com/djdirectxtut.html


• Perl (veel gebruikt voor CGI):

• http://urth.acsu.buffalo.edu/~pjg/perlcd/ (link is kapot? )
• http://www.perldoc.com
• http://www.cpan.org


• CGI (niet te verwarren met Perl, wat er wel veel voor wordt gebruikt):

• http://www.cgi-resources.com


• Javascript:

• http://javascript.internet.com


• PHP:

• http://www.php.net
• Functionaliteit van php
• http://www.zend.com
• http://www.weberdev.com
• http://www.phpbuilder.com
• http://www.phpwizard.net
• http://www.phpfreakz.com
• http://www.devshed.com
• http://sourceforge.net/projects/phptriad
• http://www.php.net/functienaam voor een snel overzicht
• http://www.phpdeveloper.org/
• http://www.newbienetwork.net/
• http://www.securereality.com.au/studyinscarlet.txt

Een aantal regexp sites

• Korte uitleg
• Leuke naslag
• http://ord.eecs.umich.edu/php/ref.pcre.html
• http://ssdd.conservatory.com/info/gawk.info.Regexp.html
• http://www.web-con.nl/index.php?id=114
• http://gathering.tweakers.net/forum/list_messages/161058
• http://zez.org/article/articleview/11/


• SQL:

• http://www.mysql.com
• www.postgresql.org
• SQLtutorial
• Normaliseren


• Java:

• http://www.javasoft.com
• http://java.sun.com/products/jdk/1.3/docs/api
• http://java.sun.com/docs/books/tutorial
• http://java.sun.com/docs/books/tutorial/java/concepts
• http://www.jguru.com/faq/
• http://www2.gol.com/users/tame


• Delphi:

• http://www.delphi3000.com
• http://www.torry.net
• http://www.delphipages.com
• http://community.borland.com/
• http://delphi.about.com/


• XML:

• http://dmoz.org/Computers/Data_Formats/Markup_Languages/XML/
• http://www.zvon.org/
• http://www.xfront.com/
• http://gathering.tweakers.net/forum/list_messages/232403/1?limit=25


• Misc.:

• YaBB.nl
• nieuwe PHPMyAdmin


<hr>


• <a name="7">Algemene info</a>

• <a name="71">XML/ XSL/ SOAP</a>


• XML:
XML stelt je in staat om gegevens heel gestructureerd vast te leggen. Daarbij gaat het puur om content, niet layout. De structuur beschermt je al een beetje tegen het fouten maken, en bovendien zijn er manieren om fouten te voorkomen via DTD of XML Schema's

Het prettige aan XML is dat je de stukken software om met XML te werken (maken, parsen, doorzoeken, etc) al voor vrijwel ieder platform hebt. Deze stukken software zitten soms in software ingebouwd of zijn als losse componenten met duidelijke API's beschikbaar.

Omdat XML een heel gestructureerde en op alle platformen beschikbare manier voor het vastleggen informatie is, is het uitermate geschikt voor koppelingen tussen systemen. Dat is mijns inziens dan ook de killer app voor XML.

• XSL:
XSL stelt je in staat om relatief eenvoudig de content in een XML document om te zetten in een andere, nuttige vorm. Je legt feitelijk regels vast voor wat je met ieder stukje uit een XML document wil doen, drukt op de knop en klaar is Kees (of hoe je ook heet ).

XSL wordt bijvoorbeeld gebruikt om XML documenten in HTML om te zetten, zodat het er in een browser mooi uit ziet. Je kan ook XML mbv XSL naar andere formaten veranderen zoals fixed text, SGML, WML of zelfs gewoon een ander XML document.

XSL is handig omdat je, zonder een XML document aan te passen, de informatie uit dat document in een voor jou nuttige vorm om kan zetten. Zo scheidt je de content van een document van de toepassing ervan (weergave in een browser, vastleggen in een logfile, doorgeven aan een ander systeem, etc.)

XSL ondersteuning is er ook op vrijwel alle platformen en in veel software, dus ook dat maakt het een krachtige tool.


• SOAP:
SOAP staat voor Simple Object Access Protocol, wat al aangeeft dat je met objecten gaat werken.

SOAP is een set met standaarden die gezamelijk tot doel hebben om objecten platformonafhankelijk over een TCP/IP netwerk (zoals het Internet) met elkaar te laten communiceren.


Dat wordt gedaan door gebruik te maken van een aantal bestaande standaarden:

• HTTP: HTTP is de manier waarop je webbrowser met een webserver communiceerd, maar het kan veel meer dan HTML heen en weer sturen.
HTTP biedt een manier om te communiceren tussen een server en een client die heel flexibel is (er zijn geen/weinig beperkingen aan de inhoud van de calls en responses), al goed werkt op de huidige TCP/IP infrastructuren (PC's, servers, routers, firewalls, etc) en ook op vrijwel alle platformen ondersteund wordt

• XML: de HTTP call bevat een XML document met de naam van het aan te roepen object, parameters met de datatypes etc. De HTTP response bevat een XML document met de output van het object

• Anders: ook andere standaard zaken zoals XML Schema's (waarmee afgedwongen kan worden dat een XML document aan vooraf gedefinieerde voorwaarden voldoet) worden gebruikt. Ik weet hier ook lang niet alles vanaf, dus misschien kunnen anderen hier iets meer over zeggen.


In de SOAP standaarden staat precies omschreven hoe objecten aangesproken moeten worden, en daarnaast wordt ook omschreven welke ondersteunende services er moeten zijn om SOAP compatible te zijn. Zo moet je bijvoorbeeld van een object via SOAP kunnen opvragen welke methodes en properties die ondersteunt, welke datatypes verwacht worden, wat voor data er terug komt, welke versie van het component gebruikt wordt, etc. Services zoals SDL, SCL en DISCO zijn gemaakt om dit soort zaken te fasciliteren.

Voordeel van deze afspraken is dat ze alleen maar omschrijven hoe gecommuniceerd gaat worden, niet hoe het geimplementeerd wordt. Zo kan je met PHP onder Apache op Linux een SOAP service maken, maar op Windows met Visual Studio.Net en IIS ook.

Uiteindelijk zullen er toolkits komen waardoor een groot deel van de technische complexiteit voor de developer wordt weggenomen en de developer zich kan concentreren op de functionaliteit van zijn software. Hoewel dat vast wel even wennen zal zijn en het soms wat beperkend zal aanvoelen, zal je er wel veel voordeel me kunnen behalen. Denk bijvoorbeeld aan hoe veel makkelijker mensen PHP leren en krachtige dingen kunnen maken, terwijl men vroeger nog in C++ een CGI programma schreef waarbij op veel meer dingen gelet moest worden en daardoor vaak complexer en tijdrovender was.


• <a name="72">Database indexing</a>

Indexes kunnen je systeem zowel sneller als langzamer maken. Een goeie strategie opzetten voor indexeren kan je behoorlijk wat performance schelen.
Een index kost performance in de volgende gevallen:

• inserts in een tabel waar 1 of meer indexen op staan
• deletes in een tabel waar 1 of meer indexen op staan
• updates van een waarde in een kolom van een tabel waar 1 of meer indexen op staan

Hierbij geldt dus: hoe meer indexen er door een actie aangepast moeten worden, hoe meer performance dat kost.

Een performance voordeel van indexen is te behalen op de volgende wijzen:

• als je op een bepaalde waarde in een kolom zoekt of ermee vergelijkt (WHERE kolom=value, WHERE kolom>value, WHERE kolom BETWEEN val1 AND val2, etc)
• als je gaat sorteren (ORDER BY kolom)
• als je gaat groeperen (GROUP BY kolom)
• als je joins gaat maken (FROM tabel1 JOIN tabel2 ON tabel1.kolom1=tabel2.kolom3)

Vooral bij hele grote tabellen kan het gebruik van een index je applicatie gigantisch veel sneller maken (1000 maal sneller en meer).

Ga nadenken over welke kolommen je in 1 van de bovengenoemde manieren gebruikt, en hoe vaak je dat doet, hoe veel gegevens er in de tabel staan, etc. Op basis daarvan neem je beslissingen op welke kolommen een index moet staan.

Goeie vuistregels zijn:

• 1) zet altijd indexen op de primairy key(s) van alle tabellen
• 2) zet altijd een index op foreign key kolommel in je tabellen, tenzij je een hele goeie reden hebt om dat niet te doen
• 3) zet indexen op de meest gebruikte kolommen van alle grote tabellen, tenzij je weet dat er heel veel updates/inserts/deletes gebeuren terwijl er niet zo veel in de tabel gezocht zal worden
• 4) maak rustig wat indexen op tabellen waarvan de inhoud niet al te vaak zal veranderen
• 5) denk na of je eventueel indexen wil leggen op de combinatie van kolommen asl deze kolommen vaak in combinatie gebruikt worden en er een performance bottleneck is
• 6) bedenk dat je altijd je indexen later kan tunen als je ziet waar de werkelijke bottlenecks bij gebruik zijn


met dank aan MrX voor de teksten over XML/XSL/SOAP en database indexing

<hr>


Deze FAQ/richtlijnen zijn vrij snel gemaakt.
Suggesties zijn daarom altijd welkom!

Groetjes/succes en laat iedereen in zijn/haar waarde

Tom Antonis

HGA Devschuur®


<hr>


Reposted & edited by ACM, chem , D2k

Laatste bewerking op: 20-10-2001, 00:12 door D2k en gepost door ACM
(faq herschreven/ geupdate)

* update 20-10-2001 : Reverse enginering en Decompilen toegevoegd.

[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.
Die discussie is geweest. Consequentie is belangrijker dan een de keuze maken tussen die paar manieren. Zie hier 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>

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 plaatjes!
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.
Dus dan kan je niet het voorbeeld zoals boven aanhouden!!!!!

Niet zo

code:

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

maar zo

code:

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

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
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 "$sql"; 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:

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;

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, blimmel,demonite en Nielsz voor het commentaar op de oorspronkelijke versie