[DISC] Wat is jouw codeer stijl?

[Reveller]

Ik programmeer in PHP, en ben al meerdere keren van "stijl" verwisseld. Het feit of je wel of geen matching brackets gebruikt, welke kleurcode je gebruikt etc. bepalen voor een groot deel of je overzichtelijk kunt werken. Ik heb dit topic geopend om misschien nog wat tips te krijgen van meer ervaren programmeurs over wat, ook op lange termijn, een goede manier van coden is. Het is namelijk zo, dat ik er na lange tijd ineens achter kom dat ik dit of dat beter anders had kunnen doen, zoals bijvoorbeeld geen # gebruiken voor je commentaar omdat dat door sommige machines niet goed verwerkt wordt.

PHP:

/*
** Voorbeeld commentaar
** Tweede regel van het commentaar
*/

function voorbeeld()
{
  global $variabele;

  if ($dit_topic == 'goed')
  {
    echo 'ik lever ook commentaar!';
  }
}

Wat valt er op aan dit voorbeeld:
• mijn tabs zijn 2 spaties breed
• ik gebruik matching brackets
• na het declareren van globals sla ik een regel over
• ik gebruik enkele quotjes bij strings
• (natuurlijk niet te zien hier, maar toch -) ik gebruik dezelfde kleurcode als GoT (hopelijk is die niet gecopyright, want dan heb ik nu een probleem

Ik heb nog een aantal vragen:
• breken jullie lange tekst (bijvoorbeeld lange regel HTML) af na bv. 80 tekens of laat je dat op 1 regel staan?
• hoe verwerk je een blok HTML in je PHP? Ik doe het nu zo (eingelijk doe ik maar een beetje, heb geen vaste regels), maar denk niet dat het erg netjes is:

PHP:

$output.= '<table>'.
          '<tr><td colspan="2">dit is cel 1</td></tr>'.
          '<tr><td>cel 2</td><td>cel 3</td></tr>'.
          '</table>';

• Ik zie vaak de volgende stijl van commentaar geven. Wat is het voordeel hiervan dan?

PHP:

/**
* Commentaar
*/

Ik hoop op positieve reakties op deze post. Op GoT worden veelal programmeerproblemen besproken, en dit is er denk ik zeker ook een. Ik wil zo professioneel mogelijk coden, maar zou graag eens een overzicht van voor -en nadelen van verschillende manieren lezen

[ Voor 10% gewijzigd door Reveller op 24-10-2004 12:02 ]

[Verwijderd]

Ik ben dan geen PHP programmeur maar toch heb ik een tip voor je. Gebruik geen shorttags, op veel servers wordt dit niet ondersteund. Beter dus <?php gebruiken.

[Erkens]

Reveller schreef op 24 oktober 2004 @ 11:43:
• mijn tabs zijn 2 spaties breed

maar gebruik je wel tabs?
zelf heb ik een hekel aan tabs omdat het er anders uit kan zien met een andere editor. Zelf zet ik altijd 2 spaties, want door het gebruik van spaties ipv tabs blijft de uitlijning goed

Verwijderd schreef op 24 oktober 2004 @ 11:51:
Ik ben dan geen PHP programmeur maar toch heb ik een tip voor je. Gebruik geen shorttags, op veel servers wordt dit niet ondersteund. Beter dus <?php gebruiken.

vaak staat dit juist wel aan om de template kracht van PHP tot zijn recht te laten komen:

PHP:

<b>Test:</b> <?=$var?><br/>

[ Voor 37% gewijzigd door Erkens op 24-10-2004 11:56 ]

[ripexx]

Reveller schreef op 24 oktober 2004 @ 11:43:
• breken jullie lange tekst (bijvoorbeeld lange regel HTML) af na bv. 80 tekens of laat je dat op 1 regel staan?
• hoe verwerk je een blok HTML in je PHP? Ik doe het nu zo (eingelijk doe ik maar een beetje, heb geen vaste regels), maar denk niet dat het erg netjes is:

PHP:

$output.= '<table>'.
          '<tr><td colspan="2">dit is cel 1</td></tr>'.
          '<tr><td>cel 2</td><td>cel 3</td></tr>'.
          '</table>';

Niet ik gebruik PHP in mijn HTML

• Ik zie vaak de volgende stijl van commentaar geven. Wat is het voordeel hiervan dan?

PHP:

/**
* Commentaar
*/

In welke context bedoel je dit? In een ontwikel fase gebruik ik relatief veel html commentaar in de output. Welk stuk komt waar etc, code die alleen voor een programmeur van belang is staat in het serverside code deel. Eindgebruikers hoeven dat niet te zien.

[Genoil]

een voorbeeld van mijn huidge coding-style:

PHP:

    /** 
    * @return DomElement
    */
    protected function getHook($xpath_expression) {
        if($this->xp == null) $this->setXPath();
        
        $dom_node_list = $this->xp->query($xpath_expression);
        if($dom_node_list->length > 0) {
            return $dom_node_list->item(0);
        }
        else {
            throw new TemplateException("Template hook not found.");
        }   
    }

om maar even het vergelijk met jouw punten te geven:
• ik gebruik 4 spaties per "insprong"
• ik heb geen idee wat matching brackets zijn
• ik sla regels over op basis van wat functioneel gezien gescheiden moet zijn
• ik gebruik zoveel mogelijk double quotes bij strings
• ik laat lange regels vaak toch op 1 regel staan, zeker strings (ivm parsers die whitespace niet ignoren)
• ik verwerk geen blokken html in m'n PHP, zoals je ziet werk ik met de PHP5 DOM en daarnaast met XSLT.
• de commentaar-stijl is voor het automagisch genereren van documentatie uit je source code. In PHP kan dat met PhpDocumentor. Binnen die blokken zie je ook dingen als @var en @return. Daarmee kun je op hele compacte en krachtige manier aangeven wat je code eigenlijk doet.
• verder ben ik dus helemaal 'om' qua OOP in PHP5, het is geweldig!
• en ik zet met {altijd op dezelfde regel. vroeger trouwens niet...
• ik deed vroeger ook hongaarse notatie, maar met PhpDocumentor erbij is dat niet echt heel erg nodig meer.
• ik doe nu al m'n ClassNamesOpDezeWijze::deMethodCallsZo($en_variabelen_op_deze_manier)
• ik smijt tegenwoordig met Exceptions ipv dat ik null of errorstrings return

[Verwijderd]

Reveller schreef op 24 oktober 2004 @ 11:43:

PHP:

/*
** Voorbeeld commentaar
** Tweede regel van het commentaar
*/

function voorbeeld()
{
  global $variabele;

  if ($dit_topic == 'goed')
  {
    echo 'ik lever ook commentaar!';
  }
}

Persoonlijk zet ik liever de { op dezelfde regel als de if/functie/etc om het aantal bijna-lege regels te beperken, bv:

PHP:

if( 1 == 2 ) {
  foo();
} else {
  bar();
}

Dit is vooral een kwestie van smaak natuurlijk

Ik heb nog een aantal vragen:
• breken jullie lange tekst (bijvoorbeeld lange regel HTML) af na bv. 80 tekens of laat je dat op 1 regel staan?

Ja! Horizontaal heen en weer moeten scrollen is een nachtmerrie als je de code wilt begrijpen. Als je regel zo lang is kandie altijd wel ergens logisch opgebroken worden zodat de lezer niet 80+ karakters in 1x hoeft te ontleden om te begrijpen wat er staat.

• hoe verwerk je een blok HTML in je PHP? Ik doe het nu zo (eingelijk doe ik maar een beetje, heb geen vaste regels), maar denk niet dat het erg netjes is:

PHP:

$output.= '<table>'.
          '<tr><td colspan="2">dit is cel 1</td></tr>'.
          '<tr><td>cel 2</td><td>cel 3</td></tr>'.
          '</table>';

Is opzich niets mis mee toch? Wat ook kan is gewoon enters in je string stoppen:

PHP:

$output.='
<table>
  <tr><td colspan="2">dit is cel 1</td></tr>
  <tr><td>cel 2</td><td>cel 3</td></tr>
</table>
';

of iets dergelijks.

• Ik zie vaak de volgende stijl van commentaar geven. Wat is het voordeel hiervan dan?

PHP:

/**
* Commentaar
*/

Het voordeel is (mijnsinziens) dat het mooi oogt en duidelijk commentaar van omringende code scheidt (de bovenste en onderste commentaarregels worden niet gebruikt).

Zoals je waarschijnlijk al weet is leesbaarheid is een van de belangrijkste eigenschappen van code (zo niet het belangrijkste). Een van de dingen om goede leesbaarheid te bereiken is gewoon consistent te zijn in je aanpak. Veel van bovengenoemd commentaar is verder voornamelijk een kwestie van smaak en ook gewoonte. De voorbeelden die je zelf liet zien zijn niet inferieur.

[Reveller]

@Genoil - matching brackets betekent niets meer dan wat jij vroeger deed (en ik nu ipv vroeger):

PHP:

if (dit)
{
  if (dat)
  {
    echo 'het is dit en dat!';
  }
}

in plaats van

PHP:

if (dit) {
  if (dat) {
    echo 'het is dit en dat!';
  }
}

• Ik vind dat uiteindelijk toch overzichtelijker, ondanks dat je je code "uit elkaar trekt"
• Ik gebruik enkele quotes omdat ik gelezen heb dat PHP binnen strings met dubbele quotes op zoek gaat naar variabelen: "Mijn naam is $naam".

[ Voor 6% gewijzigd door Reveller op 24-10-2004 12:20 ]

[Genoil]

Verwijderd schreef op 24 oktober 2004 @ 12:16:

Het voordeel is (mijnsinziens) dat het mooi oogt en duidelijk commentaar van omringende code scheidt (de bovenste en onderste commentaarregels worden niet gebruikt).

het is niet alleen mooi, maar zoals ik al zei is die stijl 'herkenbaar' door PhpDocumentor. die kijkt alleen in multiline comments die beginnen met /**. ook kent PhpDocumentor constructies voor "comment-templates" zoals dit:

PHP:

    /**#@+
    * Getter method for Template.
    * @return string
    * @see Template 
    */      
    public function getDir()  { return $this->dir; }
    public function getFile() { return $this->file; }       
    public function getStyle() { return $this->style; } 
    /**#@+*/

Dit genereert voor drie methods hetzelfde brokje documentatie.

--edit--

een aardig voorbeeld van wat er met PhpDocumentor kan:
http://propel.phpdb.org/docs/api/phpdoc/
propel heb ik dus zelf niet gemaakt he, maar ik gebruik het wel, niet in het minst vanwege de handige docs

[ Voor 17% gewijzigd door Genoil op 24-10-2004 12:29 ]

[Harm]

Reveller schreef op 24 oktober 2004 @ 12:20:
• Ik gebruik enkele quotes omdat ik gelezen heb dat PHP binnen strings met dubbele quotes op zoek gaat naar variabelen: "Mijn naam is $naam".

Daarom kun je dat ook beter schrijven als "Mijn naam is " . $naam . " en ik doe een konijn na."

[Genoil]

Harm schreef op 24 oktober 2004 @ 12:33:
[...]

Daarom kun je dat ook beter schrijven als "Mijn naam is " . $naam . " en ik doe een konijn na."

Dat zier er zeker fraaier uit (helemaal met code-highlighting), maar het schijnt wel trager te zijn dan de methode van Reveller.

[Erkens]

Genoil schreef op 24 oktober 2004 @ 12:35:
maar het schijnt wel trager te zijn dan de methode van Reveller.

idd, een paar microseconden maakt echt uit

[Genoil]

Erkens schreef op 24 oktober 2004 @ 12:55:
[...]

idd, een paar microseconden maakt echt uit

sommige mensen vinden dat toch belangrijker dan de overzichtelijkheid van hun code. ik ben zelf trouwens ook een concatenator hoor, als ik om microseconden zou geven zou ik geen DOM/XSLT gebruiken

[Verwijderd]

Reveller schreef op 24 oktober 2004 @ 12:20:
@Genoil - matching brackets betekent niets meer dan wat jij vroeger deed (en ik nu ipv vroeger):

PHP:

...

in plaats van

PHP:

...

• Ik vind dat uiteindelijk toch overzichtelijker, ondanks dat je je code "uit elkaar trekt"
• Ik gebruik enkele quotes omdat ik gelezen heb dat PHP binnen strings met dubbele quotes op zoek gaat naar variabelen: "Mijn naam is $naam".

Ik vind die manier ook makkelijker, als je ze niet matcht dan komt het heel rommelig over, imho .

[Gummbahla]

Wat ik nog wel eens gebruik om lange stukken HTML in een variabele te proppen, is de volgende methode:

PHP:

output .= <<<OUTPUTTEXT
          <table> 
            <tr><td colspan="2">dit is cel 1</td></tr> 
            <tr><td>cel 2</td><td>cel 3</td></tr> 
          </table>
          OUTPUTTEXT;

Op deze manier hoef je niet moeilijk te doen met aanhalingstekens en kun je mooi je HTML code schrijven op de manier zoals je dat buiten PHP om ook zou doen.

[ Voor 16% gewijzigd door Gummbahla op 24-10-2004 13:05 ]

[LauPro]

Mijn code wil ik altijd zo compact mogelijk opstellen; dat komt neer op hetvolgende:

PHP:

<?php
$I = 0; $Y = 0; $X = 0;
 while($blaat = functie(10)) {
    echo '<p>'.$blaat.'</p>';
 }
 
function blaat($iVar) {
    global $x; $y;
    if ($X == $iVar) {
        $y*= 10;
    }else{
        $y = false;
    }
    return $y;
}

switch($x) {
    case 10: echo 'ok'; break;
    default: echo 'nf';
}
?>

De reden waarom ik het zo compact heb is als volgt. Ik heb scripts die vaak met deze mannier van werken nu al over de 2000 regels gaan. Mocht ik veel extra whitespacing gaan gebruiken dan wordt de code imo onnodig lang en moet de parser onnodig veel whitespacing negeren (dat kost ook tijd.)

Ik gebruik altijd tabs en geen spaties (nu even wel omdat React ze anders niet goed weergeeft.) In een normale editor kan je instellen hoeveel 'spaties' een tab moet zijn. En dit zet ik meestal op 4.

[alienfruit]

Voorbeeld van mijn php meuk:

PHP:

/**
 *
 *  @@file              class.quiz.controller.inc.php
 *  @@project           QuizRecordset
 *  @@author            
 *  @@created           13th of October 2004
 *  @@description       Main QuizRecordset impl. for accessing quiz data in the database,
 *                               using the DAL.
 *
 **/
class QuizRecordset {
    var $db_connection; // instance or reference to a Database-object

    var $questions;
    var $question_no;       // current selected question number
    var $quiz_id;
    
    function QuizRecordset( &$db, $quiz_id ) {
        //
        if ( !isset( $db_connection ) or
              empty( $db_connection ) ) {
            $this->db_connnection =& $db;
        }
        
        // initiate variables
        $this->quiz_id          = $quiz_id;
        $this->question_no  = 0;
        $this->questions      = $this->getRecordset();
    }

hanging { } voor de leesbaarheid
gebruik van // voor commentaar regels
gebruik van tab2spatie functie
Uitlijnen van variabelen
Spaties tussen elke ( ), { } etc. voor de leesbaarheid
/** / voor het gebruik in mijn auto-doc die vervolgens er een yellow helpbestand uitspuugt;

[ Voor 95% gewijzigd door alienfruit op 24-10-2004 13:26 ]

[Erkens]

LauPro schreef op 24 oktober 2004 @ 13:13:
De reden waarom ik het zo compact heb is als volgt. Ik heb scripts die vaak met deze mannier van werken nu al over de 2000 regels gaan. Mocht ik veel extra whitespacing gaan gebruiken dan wordt de code imo onnodig lang en moet de parser onnodig veel whitespacing negeren (dat kost ook tijd.)

Ik gebruik altijd tabs en geen spaties (nu even wel omdat React ze anders niet goed weergeeft.) In een normale editor kan je instellen hoeveel 'spaties' een tab moet zijn. En dit zet ik meestal op 4.

vind ik een slechte reden om compacte code te hebben, als je echt denkt daar veel tijd mee te besparen dan denk ik dat het makkelijker is om te investeren in een server upgrade of een licentie voor de zend encoder ofzo

overzicht gaat voor mij als eerste, daarna ga ik pas kijken of er optimalisatie nodig zijn waarbij je de meeste tijd altijd kwijt bent met de communicatie met de database.

[Creepy]

LauPro schreef op 24 oktober 2004 @ 13:13:
De reden waarom ik het zo compact heb is als volgt. Ik heb scripts die vaak met deze mannier van werken nu al over de 2000 regels gaan. Mocht ik veel extra whitespacing gaan gebruiken dan wordt de code imo onnodig lang en moet de parser onnodig veel whitespacing negeren (dat kost ook tijd.)

Ik gebruik altijd tabs en geen spaties (nu even wel omdat React ze anders niet goed weergeeft.) In een normale editor kan je instellen hoeveel 'spaties' een tab moet zijn. En dit zet ik meestal op 4.

Zolang je script logisch is ingedeeld in classes of functie maakt de lengte van de extra regels echt niet zoveel uit. De lengte van een script is mijn inziens echt geen excuus om een compactere (en mijn inziens ook minder leerbare) coding stijl te gaan gebruiken. Hierbij heb ik het dus niet alleen over de braces, maar ook over de break op dezelfde regel, meerdere variabele declaraties op 1 regel etc.

Ik plaats elke declaratie op een eigen regel. Voor block statement (if, case, while etc) zet ik altijd een lege regel. Dit zodat niet alles 1 grote lap tekst wordt maar zelf binnen een functie/method ook nog is ingedeelt in logische blokjes.

Ik gebruik altijd tabs om te coden. Echter gebruik ik een editor die de tabs automatisch omzet naar echte spaties. Zo ziet de code er in elke andere editor er ook precies hetzelfde uit.

[ Voor 10% gewijzigd door Creepy op 24-10-2004 13:22 ]

[Verwijderd]

Ik tab sowieso in wanneer ik een nieuwe if / while / whatever open, maar wat ik ook veel doe is aangeven waarbij een bepaald iets hoort, bv:

PHP:

if ( blabla) {


} //endif

Zo kan ik makkelijker mijn code aanpassen wanneer ik iets niet meer nodig heb of wil wijzigen.

[LauPro]

Erkens schreef op 24 oktober 2004 @ 13:18:
[...]
vind ik een slechte reden om compacte code te hebben, als je echt denkt daar veel tijd mee te besparen dan denk ik dat het makkelijker is om te investeren in een server upgrade of een licentie voor de zend encoder ofzo

overzicht gaat voor mij als eerste, daarna ga ik pas kijken of er optimalisatie nodig zijn waarbij je de meeste tijd altijd kwijt bent met de communicatie met de database.

Ik ben absoluut een fel tegenstander van 'gemak voor de programmeur'. En daarmee bedoel ik allerlei stufjes die misschien technisch gezien heel interessant zijn; maar waar de gebruiker niets aan heeft of dingen die veel overhead geven (bijvoorbeeld alles (en dan bedoel ik echt alles) in klassen stoppen.)

Om code compact te maken is niet de enige reden. Het is ook vooral om de zaken overzichtelijk te houden. Als ik bij alles veel whitespacing toe zou passen dan zouden bepaalde functies niet meer op mijn scherm kunnen (gebruik normaal resolutie van 1600x1200 met lettergrootte van 12pt.) Dat vind ik niet wenselijk. Vandaar dus compacte code; die overzichtlijk is.

[ Voor 3% gewijzigd door LauPro op 24-10-2004 13:27 ]

[Creepy]

LauPro schreef op 24 oktober 2004 @ 13:23:
[...]
Ik ben absoluut een fel tegenstander van 'gemak voor de programmeur'. En daarmee bedoel ik allerlei stufjes die misschien technisch gezien heel interessant zijn; maar waar de gebruiker niets aan heeft of dingen die veel overhead geven (bijvoorbeeld alles (en dan bedoel ik echt alles) in klassen stoppen.)

Om code compact te maken is niet de enige reden. Het is ook vooral om de zaken overzichtelijk te houden. Als ik bij alles veel whitespacing toe zou passen dan zouden bepaalde functies niet meer op mijn scherm kunnen (gebruik normaal resolutie van 1600x1200.) Dat vind ik niet wenselijk. Vandaar dus compacte code; die overzichtlijk is.

En als ik het zo zie ook wat minder leesbaar Beter leesbaar = gemak voor de programmeur. Sneller kunnen ontwikkelen = gemak voor de programmeur. Hierdoor gaat de ontwikkel en debug tijd omlaat = gemak voor de klant (die betaald minder!).

Je laat het nu op mij overkomen dat je zo compact mogelijk code wilt hebben om alles in 1 opslag te kunnen zien. Die betekent niet dat je code automatisch leesbaarder is. Deel je code op in logische blokken en maak hier procedures en functies van (of classes met hun bijbehorende methods). Daardoor worden je functies waarin de echte logica zit stukken korter (je roept alleen die methods/functies aan) en daarbij ook een stuk leesbaarder. Dit debugt ook een stuk makkelijker. Gemakt voor de programmeur EN de klant.

Dit indelen lijkt in het begin wat meer tijd te kosten, maar die tijd win je aan het einde makkelijk terug omdat het nu veel makkelijker is om een kleine wijziging door te voeren, aangezien het nu makkelijk terug te vinden is wat je waar hebt gedaan i.p.v. een lap code van 2000 regels door te lezen. Daarnaast is het ook makkelijker te onderhouden door een ander.

[ Voor 12% gewijzigd door Creepy op 24-10-2004 13:30 ]

[Erkens]

LauPro schreef op 24 oktober 2004 @ 13:23:
[...]
Ik ben absoluut een fel tegenstander van 'gemak voor de programmeur'. En daarmee bedoel ik allerlei stufjes die misschien technisch gezien heel interessant zijn; maar waar de gebruiker niets aan heeft of dingen die veel overhead geven (bijvoorbeeld alles (en dan bedoel ik echt alles) in klassen stoppen.)

Waarom zou je het jezelf moeilijker maken dan het is, wat is er tegen op code die hergebruikt kan worden, wat is er op tegen om overzichtelijke code te hebben
Wat ben blij dat ik niet met jou hoef samen te werken en hopelijk nooit te maken krijg met jouw code

[Reveller]

Mijn editor (TextPad) ondersteunt idd ook tab -> spaties en ik heb hem ingesteld op 2. Ik ben hiertoe gekomen omdat ik veel open source projecten (GeekLog, Drupal, etc.) met 2 spaties zag indenten en dat zag er overzichtelijk uit. Dat maakt verder toch niet uit als ik later nog eens phpDoc zou gaan gebruiken, toch?

[Verwijderd]

LauPro schreef op 24 oktober 2004 @ 13:13:
Mijn code wil ik altijd zo compact mogelijk opstellen; dat komt neer op hetvolgende:

PHP:

<?php
$I = 0; $Y = 0; $X = 0;
 while($blaat = functie(10)) {
    echo '<p>'.$blaat.'</p>';
 }
 
function blaat($iVar) {
    global $x; $y;
    if ($X == $iVar) {
        $y*= 10;
    }else{
        $y = false;
    }
    return $y;
}

switch($x) {
    case 10: echo 'ok'; break;
    default: echo 'nf';
}
?>

De reden waarom ik het zo compact heb is als volgt. Ik heb scripts die vaak met deze mannier van werken nu al over de 2000 regels gaan. Mocht ik veel extra whitespacing gaan gebruiken dan wordt de code imo onnodig lang en moet de parser onnodig veel whitespacing negeren (dat kost ook tijd.)

Ik gebruik altijd tabs en geen spaties (nu even wel omdat React ze anders niet goed weergeeft.) In een normale editor kan je instellen hoeveel 'spaties' een tab moet zijn. En dit zet ik meestal op 4.

Sorry hoor, maar als je code zoals deze over een jaar (als vb.) moet aanpassen, en je hebt 'em niet goed gedocumenteerd, dan wens ik je veel sterkte.

Op deze manier spaar je misschien "regels" code, maar dan ben je weer veel tijd kwijt aan het ontcijferen van je code, mocht je iets willen toevoegen/veranderen.

[Equator]

ik ben geen echte php devver, veel meer een VBscript devver. (En dan alleen maar om mijn leven als admin makkelijker te maken.)

Echter ik probeer mijn script's altijd zo overzichtelijk mogelijk te maken. Niet allen voor ijzelf, maar ook voor anderen die mijn code lezen. Ik wil dat het voor iedereen goed leesbaar moet zijn.

En wat betreft classes en function's. Als ik meer dan 3 keer in een script een bepaalde actie moet uitvoeren, dan schrijf ik daar een function voor. (Bijvoorbeeld een functie voor het schrijven van een logfile in een groot script.)

Zo ben ik begonnen om een class te schrijven om info van systemen uit te lezen. Daar je dan gebruik moet maken van zowel network gerelateerde zaken, als wmi, systeem zaken wil ik daar een class voor maken. Zodat mijn collega's hier ook gebruik van kunnen maken.

Classes & Functions maken het leven veel overzichtelijker.

[LauPro]

Ik denk dat het begrip 'leesbaar' erg relatief is. Imo is de code zoals ik die nu heb heel leesbaar; van code met onnodig veel whitespacing krijg ik vaak de kriebels. Met name als je ergens 3 'pagina`s' verderop een sluitingsbracket ziet staan. Dat heeft imo geen overzichtelijkheid. Hoe overzichtelijker; hoe sneller je 'ter plaatse' bent waar je moet zijn.

Overigens ben ik geen tegenstander van klassen; ik gebruik ze zelf ook volop. Echter zijn er situaties denkbaar waarin je teveel kan doorschieten. Als er behoefte aan is kan ik zo'n voorbeeld wel posten.

Over dat samenwerken; er werd gevraagd naar mijn codeer stijl; niet de codeerpolicy bij een project waar je met meerdere mensen iets maakt. En idd ik besef me dat de code in deze staat voor anderen lastig kan zijn. Maar mocht er behoefte zijn aan whitespacing dan valt er denk ik makkelijk een parser te maken die deze toevoegd.

@slindenau: de code die ik als voorbeeld gaf is natuurlijk totale bull. Het gaat slechts om de structuur. En de praktijk staat er heus wel wat commentaar bij en duidelijkere (inhoudelijkere) namen.

[ Voor 16% gewijzigd door LauPro op 24-10-2004 13:40 ]

[Verwijderd]

Erkens schreef op 24 oktober 2004 @ 13:30:
[...]

Waarom zou je het jezelf moeilijker maken dan het is, wat is er tegen op code die hergebruikt kan worden, wat is er op tegen om overzichtelijke code te hebben
Wat ben blij dat ik niet met jou hoef samen te werken en hopelijk nooit te maken krijg met jouw code

Hoeveel hergebruik je nou werkelijk in andere projecten, op wat generieke zelfgemaakte basisklassen/functies na? Het grootste gedeelte van de klassen/functies is specifiek, niet generiek.

En waarom moet alles in klassen zitten om hergebruikt te worden? Klassen helpen om 'namespaces' te creeeren en data en functies bij elkaar te houden, dat wel. Maar dat is lang niet altijd nodig.

wat meer on-topic:

Overzicht voor alles, daar ben ik ook een voorstander van. Als je 'snelheidswinst' denkt te halen door minder spaties te gebruiken en je dat ook boeit, moet je C gaan programmeren ipv PHP. PHP is geintrepreteerd dus per definitie (relatief) traag. Een paar spaties extra inlezen ga je echt niet merken.

Te vroege optimalisatie is de bron van al het kwaad, is het toch? Schrijf duidelijke, nette code; test het en optimaliseer /waar nodig/. Dit zal meestal in de communicatie met de database, of in de gebruikte algoritmes liggen. Maar niet in het feit dat je extra spaties gebruikt of '$a=$a+1;' schrijft ipv '$a++;'.

Edit: oh en dit betekent ook dat je gerust functies mag opsplitsen in meer, doch kleinere, functies om de leesbaarheid te verbeteren. Het parsen en de extra functiecalls doen kost nauwelijks tijd. Als dit kritiek is merk je het bij het testen wel, maar het is naief om bij het coden al te weten waar de bottlenecks liggen.

[ Voor 12% gewijzigd door Verwijderd op 24-10-2004 13:43 ]

[alienfruit]

Compact misschien, maar om nou te zeggen dat het beter leesbaar is Niet echt, imho.

Ach, codeerstyl in pascal is weer wat anders bij mij:

Delphi:

namespace ChromeThreadParamsEx;

interface

uses System.Threading;

type
  ConsoleApp = class
  public
     { Public declarations }
     class method Main;
  end;

implementation

class method ConsoleApp.Main;
begin
  with tr := new Thread do
  begin
      tr.ThreadProc('Hello', 10);
      Console.WriteLine('Play that funky music white boy!');
  end;
end;

method ConsoleApp.CalculateNumeric(aValue: Double):Double;
require
  aValue >= 0;
begin
   // calculate something ;)
end;

end.

[ Voor 78% gewijzigd door alienfruit op 24-10-2004 13:47 ]

[Genoil]

Wat Creepy zegt, plus het feit dat het zomaar eens zou kunnen gebeuren dat er niet 1 , maar 2 of meer programmeurs zijn. Dan kun je je maar beter aan een of andere (defacto) coding standaard gehouden hebben en de zaken strak gedocumenteerd, wil je een beetje lekker kunnen samenwerken.

-iets anders-

heeft op zich niet heel veel met coding style te maken, maar ik maak tegenwoordig ook gebruik van packages. heel normaal in de Java wereld, maar ondanks het feit dat het in PHP niet letterlijk wordt ondersteund, toch heel bruikbaar:

PHP:

/** 
* @package nl.shapers.survey 
*/
import("propel.Propel");
import("nl.shapers.Page");
import("nl.shapers.survey.SurveyException");
import("nl.shapers.survey.db.Moderator");
import("nl.shapers.survey.db.Participator");

/** 
* 
*/
abstract class SurveyPage extends Page {
..
}

Wanneer je de punten in de import() vervangt door "/", krijg je de directorystructuur van m'n PHP bestanden, die exact dezelfde naam hebben (plus ".php"). Voor al je projecten heb je 1 "classes" directory waar je naar believen classes uit hergebruikt en extend. Wanneer je je project gaat deployen, kopieer je alleen dat wat je app nodig heeft naar de productie-server.

[ Voor 10% gewijzigd door Genoil op 24-10-2004 13:48 ]

[Verwijderd]

Even over die witregels / performance: Waar hebben we het over, microseconden? Komop zeg

Als het later weer makkelijk te begrijpen is dankzij wat extra commentaren, dan is dat imo veel meer waard dan die 0,001 seconden die je wint. Mijn P133 voert een script van 50 regels met 10 queries op zijn eigen dbase (onbelast weliswaar, maar toch een leuk voorbeeldje) in 0,02 seconde uit

edit: desnoods gooi ik er 1000 witregels in om te testen, wil het best wel eens benchmarken

[ Voor 12% gewijzigd door Verwijderd op 24-10-2004 13:50 ]

[Creepy]

Verwijderd schreef op 24 oktober 2004 @ 13:40:
[...]
wat meer on-topic:

Overzicht voor alles, daar ben ik ook een voorstander van. Als je 'snelheidswinst' denkt te halen door minder spaties te gebruiken en je dat ook boeit, moet je C gaan programmeren ipv PHP. PHP is geintrepreteerd dus per definitie (relatief) traag. Een paar spaties extra inlezen ga je echt niet merken.

Te vroege optimalisatie is de bron van al het kwaad, is het toch? Schrijf duidelijke, nette code; test het en optimaliseer /waar nodig/. Dit zal meestal in de communicatie met de database, of in de gebruikte algoritmes liggen. Maar niet in het feit dat je extra spaties gebruikt of '$a=$a+1;' schrijft ipv '$a++;'.

Edit: oh en dit betekent ook dat je gerust functies mag opsplitsen in meer, doch kleinere, functies om de leesbaarheid te verbeteren. Het parsen en de extra functiecalls doen kost nauwelijks tijd. Als dit kritiek is merk je het bij het testen wel, maar het is naief om bij het coden al te weten waar de bottlenecks liggen.

[LauPro]

Verwijderd schreef op 24 oktober 2004 @ 13:40:
Edit: oh en dit betekent ook dat je gerust functies mag opsplitsen in meer, doch kleinere, functies om de leesbaarheid te verbeteren. Het parsen en de extra functiecalls doen kost nauwelijks tijd. Als dit kritiek is merk je het bij het testen wel, maar het is naief om bij het coden al te weten waar de bottlenecks liggen.

Dat denk ik niet. Op het moment dat je een klasse hebt die je aanroept. En bij dat aanroepen wordt er allerlei informatie opgehaald die je in je code verder niet gebruikt; dan kan je bij voorbaat al zeggen dat die code traag zal worden. Of bijvoorbeeld userinput die eerst om wordt gezet naar XML en daarna in een array en daarna naar de database.

Denk bijvoorbeeld aan java waar in het begin bij het aanroepen van een bepaalde functie zoveel andere functies werden aangeroepen dat alles zo groot en log werd dat het niet meer vooruit te branden was. Ik geloof dat de mensen van Wordperfect eens een java-versie hadden gemaakt waarmee ze waren gestopt omdat tijdens het typen het soms meer dan 1 seconde duurde voordat een letter op het scherm kwam.

Ik wil iig voorkomen dat dergelijke tafarelen ook in php gaan gebeuren. Dus je roept 1 functie aan; als programmeur kan je dan gemakkelijk bij andere informatie. Maar er zit ook veel informatie tussen die je niet nodig hebt - natuurlijk hebben we het niet dan ook niet over ene goede implementatie.

Als programmeur zijnde kan je imo best voorspellen hoe snel een bepaald stuk code is. Als dat niet zo is dan weet je denk ik niet waarmee je bezig bent. En zeker als het gaat om PHP-script heb je een beperkte tijd waarin je script mag worden uitgevoerd (de gebruiker zal het niet fijn vinden als het opbouwen van een pagina 1 seconde duurt.) Dan moet je dus niet met constructies aankomen die technisch gezien interessant zijn, maar wel relatief traag.

Een mooi voorbeeld is door middel van XML HTML genereren. Dit is technisch gezien hoogstaand; echter praktisch gezien niet echt optimaal omdat het ten opzichte van het huidige model (direct HTML genereren) veel vertraging met zich meebrengt.

Mijn voorbeeld over de parse-time van de whitespacing is overigens gebaseerd op de parser van de editor. Ik was hier niet helemaal duidelijk bij. Ik heb gemerkt dat een P3 450 Mhz de grootste moeite heeft om de realtime highlighting te doen van 2000 regels. Mogelijk dat mijn editor niet efficiënt is; maar in dat opzicht vond ik het dus wel een belang hebben. Het gaat mij er iig om dat je als programmeur bewust bent wat er met je code gebeurd.

[ Voor 17% gewijzigd door LauPro op 24-10-2004 14:08 ]

[pjonk]

Verwijderd schreef op 24 oktober 2004 @ 13:40:
[...]
Overzicht voor alles, daar ben ik ook een voorstander van. Als je 'snelheidswinst' denkt te halen door minder spaties te gebruiken en je dat ook boeit, moet je C gaan programmeren ipv PHP.

Even mierenneuken bij gecompileerde talen zoals C maken spaties en comments al helemaal niets uit aangezien deze bij het compilatie proces al genegeerd worden.

Maar zoals al eerder gezegd het is nogal onzin om te gaan mierenneuken om spaties en comments in je PHP scripts. Daarbij zijn er voldoende tools beschikbaar die dit eruit kunnen filteren zoals de Zend encoder of PHP script Obfuscators.
Bij HTML output is het bekend dat de spaties/tabs en enters extra bandbreedte kosten, maar daar hebben ze weer HTTP compressie voor uitgevonden.

[Genoil]

LauPro schreef op 24 oktober 2004 @ 14:05:
[...]
Dat denk ik niet. Op het moment dat je een klasse hebt die je aanroept. En bij dat aanroepen wordt er allerlei informatie opgehaald die je in je code verder niet gebruikt; dan kan je bij voorbaat al zeggen dat die code traag zal worden.

Nooit van inheritance gehoord? Als jij bij het laden van een klasse naar eigen mening teveel ongebruikte code laadt, is dat geen fout van het OO principe, het is een fout in jouw class tree.

Ik wil iig voorkomen dat dergelijke tafarelen ook in php gaan gebeuren. Dus je roept 1 functie aan; als programmeur kan je dan gemakkelijk bij andere informatie. Maar er zit ook veel informatie tussen die je niet nodig hebt - natuurlijk hebben we het niet dan ook niet over ene goede implementatie.

dus vanuit een functie kun je wel overal goed bij en vanuit een object-instance of static-class method niet? je bedoelt vast iest anders, want dit hangt wederom af van je ontwerp.

Als programmeur zijnde kan je imo best voorspellen hoe snel een bepaald stuk code is. Als dat niet zo is dan weet je denk ik niet waarmee je bezig bent. En zeker als het gaat om PHP-script heb je een beperkte tijd waarin je script mag worden uitgevoerd (de gebruiker zal het niet fijn vinden als het opbouwen van een pagina 1 seconde duurt.) Dan moet je dus niet met constructies aankomen die technisch gezien interessant zijn, maar wel relatief traag.

ik heb liever een rock-solid, uitbreidbare en beheersbare OO app die er 1 seconde over doet dan een verzameling functies die het in de helft van de tijd doen, maar da's een kwestie van smaak.

Een mooi voorbeeld is door middel van XML HTML genereren. Dit is technisch gezien hoogstaand; echter praktisch gezien niet echt optimaal omdat het ten opzichte van het huidige model (direct HTML genereren) veel vertraging met zich meebrengt.

Hier over de schutting bij /14 is de algemene opvating tegenwoordig toch wel dat opmaak van inhoud wordt gescheiden. Het lijkt me niet meer dan normaal dat het scheiden van business logic en inhoud het allereerste is, wil je iets aan je coding-style verbeteren. Schijt aan performance, computers worden toch wel sneller. Wat ik wel probeer, is zoveel mogelijk proberen m'n inhoudelijke zaken in XHTML op te slaan ipv e.o.a. proprietary formaat. Dat scheelt dure XSLT transforms.

Mijn voorbeeld over de parse-time van de whitespacing is overigens gebaseerd op de parser van de editor. Ik was hier niet helemaal duidelijk bij. Ik heb gemerkt dat een P3 450 Mhz de grootste moeite heeft om de realtime highlighting te doen van 2000 regels. Mogelijk dat mijn editor niet efficiënt is; maar in dat opzicht vond ik het dus wel een belang hebben. Het gaat mij er iig om dat je als programmeur bewust bent wat er met je code gebeurd.

Hmm..jij hebt source-files van 2000 regels? Wat bedoel je dan met "niet teveel dingen inladen die je niet nodig hebt"?

[alienfruit]

Nou files van 2000regels vind ik maar weinig hoor
Mijn editor heeft alleen al rond 35.000 regels waarbij er twe bestanden zijn met rond de 10.000 regels en de rest is verdeeld over kleinere bestanden voor undo, painting, parser/compiler e.d. (geschreven door MartinW zodat ie bloedsnel is ) Mijn editor heeft echt geen moeite met 2000 regels te syntax highlighten, is het misschien een editor die de RichEdit control gebruikt ofzo

[ Voor 20% gewijzigd door alienfruit op 24-10-2004 14:43 ]

[RSpliet]

* RSpliet gooit ook maar eens even met zijn stijl:

PHP:

<?php
/* Meerregelig commentaar
 * Staat zo het netst als je t mij vraagt, als de spatie voor
 * het sterretje werd weergegeven althans
 */

if(is_array($_POST)) {
      // Eenregelig commentaar, inspringen dmv een tab, haakje openen naast de if of else.
      // Oja, en een spatie na //
      doe_rommel(); // underscores in functies, aangezien spaties niet mogen
} else {
       echo "PIE!";
} // vroegah had ik altijd een ; achter mijn laatste }, heb ik mezelf afgeleerd!
?>

En voor de fans van short open tags:

Steph Fox:

---

Short_open_tag ... nyaaargh... Normally I'd have had short_open_tag = Off
in my php.ini, as would the majority of the judges. That means we get to
see a bunch of code on first opening the app, and error messages like "I
dont know What you did, or how you did it, but somehow
we have received to many post variables."!

I had a huge argument with Zeev over this when we were judging the
finalists - mainly because of MyObjects, which is a brilliant project in
many ways. The thing is, I did the initial evaluations and so have 152 PHP
5 applications behind me, which Zeev does not. I don't feel that his
argument about xml compatibility holds weight, as many of the xml-based apps
didn't work around short open tags, meaning I had to switch the ini setting
a _lot_ - I shouldn't need to do that, he agrees, but we disagree on _why_ I
had to do that. I just think (along with half the PHP core dev team) that
nobody should use <? in PHP 5. It's still under the microscope, it's a
contentious issue. But I'd have marked you down for that alone. And Zeev
will end up agreeing with me when I prove to him that the way people use xml
in PHP is not the way he expected them to use it.

En voor wie het niet weet: "Steph Fox - Zend's new DevZone Editor. Steph is well known in the PHP community, and is largely responsible for the PHP-GTK manual."

[ Voor 39% gewijzigd door RSpliet op 24-10-2004 14:57 ]

[chris]

LauPro schreef op 24 oktober 2004 @ 13:13:

PHP:

    echo '<p>'.$blaat.'</p>';

Zo deed ik het ook. Maar dan met dubbele quotes. In php kan het echter véél mooier:

PHP:

  echo "<p>{$blaat}</p>";

Dat is toch veel eleganter, niet?

[simon]

chris schreef op 24 oktober 2004 @ 15:35:
[...]


Zo deed ik het ook. Maar dan met dubbele quotes. In php kan het echter véél mooier:

PHP:

  echo "<p>{$blaat}</p>";

Dat is toch veel eleganter, niet?

Gebruik je hier niet een variabele variabele? Dat vind ik veel minder elegant...

[kmf]

Na een jaar gestoeid te hebben heb ik toch zo'n beetje deze stijl ontwikkeld:

Ik hou niet van in en uit php-mode te springen, dus gebruik ik vrijwel altijd print/echo voor html-code

PHP:

//let op dat je NIETS achter de <<<IETS tikt behalve een newline, anders krijg je onzichtbare syntaxfouten
print <<<HTML
<table>
    <tr>
         <td>
               $blaat
         </td>
    </tr>
</table>
HTML;
//let op dat je NIETS achter de ; doet, anders krijg je onzichtbare syntaxfouten

//of voor 1-zin code

echo "<td>$row</td>";

if (1=1)
{
    echo "$blaat";
}

//brackets altijd onder elkaar, veel makkelijker debuggen vind ik

//voor commentaar

//minder dan 3 regels gebruik ik //


/*
meer
dan
3
regels
gebruik
ik
*
/
*/

chris schreef op 24 oktober 2004 @ 15:35:
[...]


Zo deed ik het ook. Maar dan met dubbele quotes. In php kan het echter véél mooier:

PHP:

  echo "<p>{$blaat}</p>";

Dat is toch veel eleganter, niet?

ik vind

PHP:

 echo "<p>$blaat</p>";

Eleganter en zeker minder RSI-bevorderend. Teveel shiften is niet goed

[ Voor 36% gewijzigd door kmf op 24-10-2004 15:44 ]

[Verwijderd]

zo wie zo zou je je html van je php moeten scheiden : ) met bijvoorbeeld smarty : ) super libary

[Cavorka]

alienfruit schreef op 24 oktober 2004 @ 14:42:
Nou files van 2000regels vind ik maar weinig hoor
Mijn editor heeft alleen al rond 35.000 regels waarbij er twe bestanden zijn met rond de 10.000 regels en de rest is verdeeld over kleinere bestanden voor undo, painting, parser/compiler e.d. (geschreven door MartinW zodat ie bloedsnel is ) Mijn editor heeft echt geen moeite met 2000 regels te syntax highlighten, is het misschien een editor die de RichEdit control gebruikt ofzo

Het gaat niet om de editor, het gaat om het parsen. Doh! Elke fatsoenlijke editor kan bestanden van een paar Gig openen...

Wat betreft die whitespace in bestanden. Volgens mij kan je gewoon zelf een soort 'compiler/parser' schrijven in PHP, die je files parst en dan alle whitespace eruit stript op het moment dat je het in productie zet. Maarja, dat is dus echt alleen als je zou denken dat het uitmaakt: benchmark anyone?

Dingen die ik gebruik:
- altijd dubbel quotes om strings (als je eventueel nog HTML in je code zou hebben staan, wat ik al een tijd niet meer heb, omdat ik een Template parser heb gemaakt, is dat wel handig want dan hoef je niet alle single quotes te gaan escapen die om je properties van je HTML tags staan)
- nooit quotes om floats/ints
- commentaar altijd // en voor meerregelig /* (...) */, ik gebruik (nog!) geen phpDocumenter, misschien toch maar eens naar kijken.
- einde van lange if's, for's, functies en classes aangeven:

PHP:

// Do some funky condition checking here
if($condition) {
    // A lof of stuff
}   // End of funky condition checking

function Foo($bar) {
    return $bar ;
}    // EoF: Foo

class Bla extends Bloep {

   function Bla() {
     // initiate the mofo
    } // EoF: Bla

}    // EoC: Bla

Met: EoF = End of Function, ik gebruik toch nooit end of file.
EoC = End of Class

Voor de rest: ik gebruik ook tabs om in te springen, ik werk altijd aan eigen code, niet aan andermans code. En met UltraEdit is het omzetten naar spaties ook een druk op de knop.

[ Voor 24% gewijzigd door Cavorka op 24-10-2004 15:51 ]

[kmf]

Verwijderd schreef op 24 oktober 2004 @ 15:43:
zo wie zo zou je je html van je php moeten scheiden : ) met bijvoorbeeld smarty : ) super libary

Niets moet, alles mag

Soms is de flow van een scriptje leesbaarder als de html code ingebakken zit.


Voor tableheaders, footers, pageheaders, footers gebruik ik meestal een functie.

[kmf]

alienfruit schreef op 24 oktober 2004 @ 14:42:
Nou files van 2000regels vind ik maar weinig hoor
Mijn editor heeft alleen al rond 35.000 regels waarbij er twe bestanden zijn met rond de 10.000 regels en de rest is verdeeld over kleinere bestanden voor undo, painting, parser/compiler e.d. (geschreven door MartinW zodat ie bloedsnel is ) Mijn editor heeft echt geen moeite met 2000 regels te syntax highlighten, is het misschien een editor die de RichEdit control gebruikt ofzo

Als het niet 1 klasse is dat in die bestand zit, heb ik liever meerdere kleinere bestanden. Onderhoud gaat sneller. Hoef ik ook niet door al die code te worstelen.

Nadat een klasse is afgerond, ga ik de functies hierin meestal ook nog ordenen op volgorde en de mate hoe de functies met elkaar samen hangen, puur om de onderhoudbaarheid te vergroten.

[PrisonerOfPain]

Simon schreef op 24 oktober 2004 @ 15:36:
Gebruik je hier niet een variabele variabele? Dat vind ik veel minder elegant...

Nee, variabele variabele duid je in PHP aan met een extra $ dus $$var. {} Is de 'complex syntax'. Waar je een hoop meer mee kan als met "foo$bar foo"

[alienfruit]

Het is een klasse verdeelde over meerdere bestanden
Het schrijven van een snelle parser is nog altijd niet makkelijk hoor, ik heb een hele tijd maar een 20-30mb/s kunnen halen qua parsen e.d. Dat is natuurlijk zo traag als de stront van de makke beer ik zit nu op het dubbele dat is vaak snel genoeg. Misschien ook wel meer hij parsed een Delphi en/of C# bestand 1KB in 0,00026seconden. Lijkt mij snel genoeg

[ Voor 86% gewijzigd door alienfruit op 24-10-2004 16:30 ]

[crisp]

even over single en doublequotes ism HTML-output: singlequotes gebruiken om HTML-attributen is niet handig:

PHP:

$value = "Mijn hobby's";
echo "<input type='text' value='" . htmlspecialchars($value) . "' />";

Je bent nu dus verplicht ENT_QUOTES in htmlspecialchars te gaan gebruiken, anders gaat dit fout. Ik ben een groot voorstander van het gebruik van double quotes in HTML en single quotes in scripting (denk ook aan JS in een eventhandler). De minimieme snelheidswinst die je daarmee krijgt in PHP neem ik wel op de koop toe

[ Voor 4% gewijzigd door crisp op 24-10-2004 16:29 ]

[Orphix]

Trouwens even over het commentaar. Als je al je aanpassingsdatum verwerkt in je code bestanden, gebruik dan de volle naam van een maand (bv October). Niks vervelender dan een bestand waarin staat:

code:

Date last modified: 10/01/2004

waarbij je geen idee hebt of dit nou 10 januari of 1 oktober moet voorstellen.

[Erkens]

Orphix schreef op 24 oktober 2004 @ 17:06:
Trouwens even over het commentaar. Als je al je aanpassingsdatum verwerkt in je code bestanden, gebruik dan de volle naam van een maand (bv October). Niks vervelender dan een bestand waarin staat:

code:

Date last modified: 10/01/2004

waarbij je geen idee hebt of dit nou 10 januari of 1 oktober moet voorstellen.

buiten het feit dat de datum bij mij automagisch gaat door het CVS, gebruik ik altijd de notatie YYYY/MM/DD zodat het altijd duidelijk is

[Cavorka]

(...)

Hier stond onzin, htmlspecialchars converteert dubbele quotes dus wel automatisch, en enkele niet.

Hm, maar om dus toch nog even terug te komen op het geen wat jullie nu niet meer kunnen zien omdat ik het heb weggehaald ():
stel je zet dus dubbele quotes om al je HTML-attributes, en voor de value's gebruik ja dan dus htmlspecialchars. Is het dan niet een miljoen keer makkelijker om dan even in die functie aanroep die parameter mee te geven, dan bij al je HTML-attributes je dubbele quotes te gaan escapen?
Alleen als je hele website uit forms bestaat misschien niet, maar als je een gewoon website hebt, lijkt het me handiger, overzichtelijker en mooier (* Cavorka is fan van single quotes) om dus single quotes te gebruiken.

edit:
-

Damn, ik ben niet wakker. Dat is dus weer alleen een probleem als je strings als volgt gebruikt:

PHP:

$string = "HOEI1!!" ;

en niet als

PHP:

$string = 'HOEI1!!' ;

[ Voor 187% gewijzigd door Cavorka op 24-10-2004 17:49 ]

[MisterData]

Cavorka schreef op 24 oktober 2004 @ 17:42:
(...)
(* Cavorka is fan van single quotes) om dus single quotes te gebruiken.

Ik denk dat veel mensen die meerdere talen gebruiken eerder de dubbele quotes gebruiken dan de enkele, omdat in bijvoorbeeld C(++) een single quote een character opgeeft ('abc' mag daar niet)

[pierre-oord]

crisp schreef op 24 oktober 2004 @ 16:27:
even over single en doublequotes ism HTML-output: singlequotes gebruiken om HTML-attributen is niet handig:

PHP:

$value = "Mijn hobby's";
echo "<input type='text' value='" . htmlspecialchars($value) . "' />";

Je bent nu dus verplicht ENT_QUOTES in htmlspecialchars te gaan gebruiken, anders gaat dit fout. Ik ben een groot voorstander van het gebruik van double quotes in HTML en single quotes in scripting (denk ook aan JS in een eventhandler). De minimieme snelheidswinst die je daarmee krijgt in PHP neem ik wel op de koop toe

Ik geloof dat single quotes in HTML niet thuishoren.

Daarom gebruik ik altijd single quote's om het aan te geven, want anders krijg je dit:

PHP:

echo "<input type=\"text\" value=\"".$value."\">";

Dat schiet niet echt op.
Doe mij dan maar:

PHP:

echo '<input type="text" value='.$value.'>';

En als je het goed script, zorg je dat iedere value die door een form binnennkomt, altijd met addslashed whatever wordt gedaan in het begin (toch?)

[ Voor 11% gewijzigd door pierre-oord op 24-10-2004 22:16 ]

[crisp]

Escapen is eigenlijk alleen maar van belang op het moment dat je bepaalde waarden weg wilt schrijven naar een externe source (bv een database of file). Voor mySQL kan je dan het beste mysql_(real_)escape_string gebruiken. addslashes en stripslashes zijn onhandig en meestal ook overbodig. Met name de magic_quotes functionaliteit in PHP is uiteindelijk een real pain-in-the-but en mag er wmb subiet uitgesloopt worden.
Voor het terugschrijven van waarden naar HTML-attributen dien je dus htmlspecialchars of htmlentities te gebruiken, en de doublequote liefhebbers (in PHP) dienen er daarbij dus aan te denken dat ze dan ook ENT_QUOTES gebruiken

[ Voor 12% gewijzigd door crisp op 24-10-2004 22:18 ]

[jvdmeer]

athlonkmf schreef op 24 oktober 2004 @ 15:42:

PHP:

 echo "<p>$blaat</p>";

Eleganter en zeker minder RSI-bevorderend. Teveel shiften is niet goed

Dan gebruik ik liever weer de eerstgenoemde variant:

PHP:

 echo '<p>'.$blaat.'</p>';

Maar type die dan wel in speciale volgorde, om twee redenen:
1) tel niet kwijtraken van open of dichte quote's
2) dat vage VS-internationaal toetsenbord, die op allerlei letters accenten neerzetten.

Dus in bovenstaand voorbeeld type ik:
echo [single quote][single quote][links]<p>[end]..[links]$blaat[end][single quote][single quote][links]</p>[end];

Op deze manier staan strings altijd binnen quote's en vergeet ik er nooit een. Voor jouw RSI opmerking, hier it maar 1 [shift] in namelijk voor de '$'.

Zijn er nog meer mensen die dat VS-internationaal toetsenbord gebruiken?

[enveekaa]

Ik ben er voorstander van om alle functions(); in een centraal script te plaatsen en deze te inluden in de script waar ze nodig zijn, dit houdt de functies heel overzichtelijk.

code:

<?
include('AllFunctions.php');

// en dan de rest :)
?>

Handig

Nick

[Spinal]

jvdmeer schreef op 24 oktober 2004 @ 22:20:
[...]


Dan gebruik ik liever weer de eerstgenoemde variant:

PHP:

 echo '<p>'.$blaat.'</p>';

Maar type die dan wel in speciale volgorde, om twee redenen:
1) tel niet kwijtraken van open of dichte quote's
2) dat vage VS-internationaal toetsenbord, die op allerlei letters accenten neerzetten.

Dus in bovenstaand voorbeeld type ik:
echo [single quote][single quote][links]<p>[end]..[links]$blaat[end][single quote][single quote][links]</p>[end];

Op deze manier staan strings altijd binnen quote's en vergeet ik er nooit een. Voor jouw RSI opmerking, hier it maar 1 [shift] in namelijk voor de '$'.

Zijn er nog meer mensen die dat VS-internationaal toetsenbord gebruiken?

Zeer bekend probleem Ik werk op een vergelijkbare manier.
Ik gok dat de meeste mensen VS-internationaal gebruiken, ik ken maar 1 persoon die een Nederlands toetsenbord heeft.

[Erkens]

ZanderZ schreef op 24 oktober 2004 @ 22:30:
[...]


Zeer bekend probleem Ik werk op een vergelijkbare manier.
Ik gok dat de meeste mensen VS-internationaal gebruiken, ik ken maar 1 persoon die een Nederlands toetsenbord heeft.

ik gok dat de meeste mensen juist niet VS-internationaal gebruiken, dat is echt een ramp tijdens het devven, elke quote moet je een spatie of wat dan ook typen, en als je dat vergeet krijg je ongewenste resultaten, nee doe mij maar normaal VS

[Creepy]

enveekaa schreef op 24 oktober 2004 @ 22:29:
Ik ben er voorstander van om alle functions(); in een centraal script te plaatsen en deze te inluden in de script waar ze nodig zijn, dit houdt de functies heel overzichtelijk.

code:

<?
include('AllFunctions.php');

// en dan de rest :)
?>

Handig

Nick

Tenzij er een hoop functies in staan die je op dat moment helemaal niet gebruikt Deel ze dan naar functionaliteit in zodat je meerdere scripts krijgt en alleen include wat je nodig hebt

PHP:

include('dbfunctions');
include('somefunkygraphicfunctions')

etc. etc.

Scheelt je later ook weer in de gigansche "allfunctions" zoeken naar welke functie ook alweer waar stond.

[Cavorka]

pierre-oord schreef op 24 oktober 2004 @ 22:04:
[...]
Ik geloof dat single quotes in HTML niet thuishoren.

Onzin, enkele quotes zijn net zo goed te verdedigen als dubbele en dus is er ook geen voorkeur en dus staat ook in de XHTML definitie dat het allebei mag. In HTML maakt het dan dus al helemaal niet uit. Non argument.

[ Voor 7% gewijzigd door Cavorka op 24-10-2004 23:04 ]

[crisp]

Cavorka schreef op 24 oktober 2004 @ 23:03:
[...]
Onzin, enkele quotes zijn net zo goed te verdedigen als dubbele en dus is er ook geen voorkeur en dus staat ook in de XHTML definitie dat het allebei mag. In HTML maakt het dan dus al helemaal niet uit. Non argument.

Dat klopt, hoewel ik uit alle voorbeelden in de recommendations van w3 toch een lichte voorkeur voor doublequotes bespeur
Er is ook maar 1 argument voor het gebruik van doublequotes in HTML, en dat is dat als je singlequotes gebruikt je dus in PHP bij het gebruik van htmlspecialchars en htmlentities ENT_QUOTES moet gebruiken. Je wijkt dan dus af van de default.

/me krijgt echter het idee dat veel PHP-programmeurs er vaak helemaal niet aan denken om output in HTML-attributen (dat geldt ook voor links!) te voorzien van entities wat dus vroeg of laat altijd problemen oplevert

[ Voor 16% gewijzigd door crisp op 24-10-2004 23:15 ]

[SaiBork]

Erkens schreef op 24 oktober 2004 @ 22:38:
[...]

ik gok dat de meeste mensen juist niet VS-internationaal gebruiken, dat is echt een ramp tijdens het devven, elke quote moet je een spatie of wat dan ook typen, en als je dat vergeet krijg je ongewenste resultaten, nee doe mij maar normaal VS

Dit gaat niet om de toetsenbord indeling, maar om de taal die erbij is ingesteld
VS en VS-internationaal TB is volgens mij zo goed als gelijk

Maarja, on-topic...

Ik php ook redelijk wat, maar met single quotes en dubbele quotes.. ik weet niet..
Ik vind escapen vaak toch wel erg makkelijk.

[Erkens]

SaiBork schreef op 24 oktober 2004 @ 23:26:
[...]


Dit gaat niet om de toetsenbord indeling, maar om de taal die erbij is ingesteld
VS en VS-internationaal TB is volgens mij zo goed als gelijk

dat zeg ik toch?
VS-internationaal is gewoon de VS indeling alleen dan met die internationale taal functie ingeschakeld (softwarematig) waardoor devven een hel wordt

[Grijze Vos]

LauPro schreef op 24 oktober 2004 @ 13:13:
De reden waarom ik het zo compact heb is als volgt. Ik heb scripts die vaak met deze mannier van werken nu al over de 2000 regels gaan. Mocht ik veel extra whitespacing gaan gebruiken dan wordt de code imo onnodig lang en moet de parser onnodig veel whitespacing negeren (dat kost ook tijd.)

Pst, "function() {" bevat een whitespace, een newline is ook maar 1 karakter, dus of hij nou een whitespace, of een newline moet skippen, maakt al geen fuck uit. Ik denk dat je voor de meeste nesting wel een spatie voor je bracket zet, dus dan is dit argument in beginsel al kul.

En dan nog, als het zou schelen, scheelt het op 2KLOC nog niet eens 2ms, schat ik zo.

[Verwijderd]

zowiezo kan je in PHP maar ook in andere talen/scripts veel beknopter en volgens mij ook "snellere" code schrijven door gebruik te maken van ingebouwde functies. klein voorbeeldje:

code:

<?
...
$voorraad[0] = "Melk";
$voorraad[1] = "Yoghurt";

$totaalvoorraad[0] = $voorraad;

$voorraad2[0] = "Brood";
$voorraad2[1] = "Beschuit";

$totaalvoorraad[1] = $voorraad2;
...
?>

wordt

code:

<?
...
$voorraad = array("Melk", "Yoghurt");
$voorraad2 = array("Brood", "Beschuit");

$totaalvoorraad = array($voorraad, $voorraad2);
?>

[Verwijderd]

Verwijderd schreef op 25 oktober 2004 @ 00:00:
zowiezo kan je in PHP maar ook in andere talen/scripts veel beknopter en volgens mij ook "snellere" code schrijven door gebruik te maken van ingebouwde functies. klein voorbeeldje:

code:

<?
...
$voorraad[0] = "Melk";
$voorraad[1] = "Yoghurt";

$totaalvoorraad[0] = $voorraad;

$voorraad2[0] = "Brood";
$voorraad2[1] = "Beschuit";

$totaalvoorraad[1] = $voorraad2;
...
?>

wordt

code:

<?
...
$voorraad = array("Melk", "Yoghurt");
$voorraad2 = array("Brood", "Beschuit");

$totaalvoorraad = array($voorraad, $voorraad2);
?>

Ook hier geldt m.i. dat het allemaal niet zoveelllll uitmaakt, wat zou het schelen. 1ms ofzo? De dbase-connecties en queries zorgen voor performance problemen over het algemeen, de pure php-code meestal niet.

Edit: als je doelt op het snellere klopwerk ben ik het wel met je eens natuurlijk

[ Voor 12% gewijzigd door Verwijderd op 25-10-2004 00:05 ]

[Verwijderd]

Verwijderd schreef op 25 oktober 2004 @ 00:04:
[...]


Ook hier geldt m.i. dat het allemaal niet zoveelllll uitmaakt, wat zou het schelen. 1ms ofzo? De dbase-connecties en queries zorgen voor performance problemen over het algemeen, de pure php-code meestal niet.

Edit: als je doelt op het snellere klopwerk ben ik het wel met je eens natuurlijk

Zowiezo het laatste argument maar kortere code leest ook wat makkelijker he .

BTW het scheelt idd 1ms maar dan in de situatie dat jij het op je thuispc een keer uittest. Hoe sneller de code-uitvoer in beeld komt bij een klant die tezamen met 2000 medeklanten die php-gegenereerde site bekijkt is wel een iets ander verhaal, dan telt namelijk elke milliseconde.

En daarnaast gaat het om de afweging of je de database 1 keer belast en de rest van de bewerkingen overlaat aan php-functies; of dat je de database sterker belast en weer minder php-code hoeft te gebruiken...

[Grijze Vos]

Mijn stijl dan maar ff:

PHP:

/************************************************************
*                                                           *
* GoT File : got.inc.php                                    *
* description: blabla                                       *
* modified: 25-1-2004 GreyFox                               *
* --------------------------------------------------------- *
* info over alle function calls van deze class/ deze file   *
************************************************************/

if($GOT_is_leet)
{ // doe iets leuks met de database
  $db->query("INSERT blabla");
}
else
{ // geef een error message

  # Hier moet ik nog iets fixen, temporary commentaar geef ik aan met een hekje.
}

uitleg dus altijd aan het begin van een genest blok. Als je in een zin niet kunt uitleggen wat je blok doet, dan zit er iets niet snor IMO.

tijdelijk commentaar, daar vind ik die hashes perfect voor. Valt ook altijd goed op tussen het andere commentaar.

Inspringen, twee spaties, geen tabs. (Evenals de HTML die ik output.) En uiteraard matching brackets.

[ Voor 23% gewijzigd door Grijze Vos op 25-10-2004 00:15 ]

[GeniusDex]

Wat me wel opvalt is dat zo ongeveer iedereen altijd brackets om codeblocks heen zet. Ben ik dan de de enige die dat alleen doet als er meer dan 1 statement is

PHP:

<?
if ($a == $b)
    echo "They match!";

if ($b > $c) {
    echo $c." is smaller than ".$b;
} else {
    $b++;
    echo "Incremented $b";
}
?>

[Reveller]

@GeniusDex - de laatste tijd zet ik er dan ook geen brackets meer omheen. Deed dat tot voor kort wel, en dan voornamelijk met conistentie als argument. Maar dat vond ik uiteindelijk wat weinig hout snijden. "Je bent dus niet alleen!"

[Erkens]

GeniusDex schreef op 25 oktober 2004 @ 18:21:
Wat me wel opvalt is dat zo ongeveer iedereen altijd brackets om codeblocks heen zet. Ben ik dan de de enige die dat alleen doet als er meer dan 1 statement is

PHP:

<?
if ($a == $b)
    echo "They match!";

if ($b > $c) {
    echo $c." is smaller than ".$b;
} else {
    $b++;
    echo "Incremented $b";
}
?>

ik doe dat altijd, brackets gebruiken, door dit altijd te doen krijg geen last van foutjes als je vergeten bent die brackets toe te voegen als er een statement bij moet later.
In het uitzonderlijke geval dat ik het niet doe dan komt dat statement op dezelfde regel als de if, ook hier om de structuur duidelijk weer te geven en te laten zien dat alleen dat statement uitgevoerd wordt.

[Mithrandir]

De short-hand notatie, zonder brackets, gebruik ik vaak als er 1 ding wordt aangepast. Voorbeeldje:

PHP:

if($gotDesc = 'leet')
  $userIsGotter = true;
else
  $userIsGotter = false;

Maar in het volgende geval:

PHP:

if($action = 'bloei')
{
  $bloem->bloei();
}
else
{
  echo 'bloem bloeit niet. bah.';
}

gebruik ik dus de lange notatie omdat er 2 totaal verschillende dingen worden gedaan.

[ Voor 29% gewijzigd door Mithrandir op 25-10-2004 18:46 ]

[drm]

GeniusDex:
Wat me wel opvalt is dat zo ongeveer iedereen altijd brackets om codeblocks heen zet. Ben ik dan de de enige die dat alleen doet als er meer dan 1 statement is

Naast het punt dat Erkens al noemt, heb ik mezelf aangewend om na if ()'s, else if()'s, else's etcetera direct de { en de } te typen en op de juiste plek te zetten. Ik typ een if-statement dus als volgt (| is caret)

code:

if ( some_condition ) |

code:

if ( some_condition ) {

}|

code:

if ( some_condition ) {
   |
}

Dan maak je het voor jezelf onnodig moeilijk om van te voren gaan bekijken of iets 1 of meer statements wordt

Verder scheelt het je gedonder als je nog eens een overstap maakt naar Perl

[drm]

Mithrandir:
De short-hand notatie, zonder brackets, gebruik ik vaak als er 1 ding wordt aangepast. Voorbeeldje:

PHP:

if($gotDesc = 'leet')
  $userIsGotter = true;
else
  $userIsGotter = false;

Ware het niet dat je hier beter gewoon

PHP:

$userIsGotter = ( $gotDesc == 'leet' );

kunt gebruiken In dat soort gevallen gebruik ik dus vrijwel altijd bovenstaande in geval van booleans en de ? ... : .... in het geval van andere typen

[Verwijderd]

GeniusDex schreef op 25 oktober 2004 @ 18:21:

PHP:

<?
if ($a == $b)
    echo "They match!";

if ($b > $c) {
    echo $c." is smaller than ".$b;
} else {
    $b++;
    echo "Incremented $b";
}
?>

Als je ze toch weglaat bij enkele statements kan je net zo goed ook de {} na het if-statement verwijderen... Scheelt je weer twee bytes

[GeniusDex]

Verwijderd schreef op 25 oktober 2004 @ 18:48:
[...]

Als je ze toch weglaat bij enkele statements kan je net zo goed ook de {} na het if-statement verwijderen... Scheelt je weer twee bytes

Probleem is dat ik zoiets er niet uit vind zien:

PHP:

<?
if ($bla)
    echo "ja";
else {
    echo "nu wel";
    $bla = true;
}
?>

Geef mij dan maar gewoon helemaal brackets

drm schreef op 25 oktober 2004 @ 18:48:
[...]
Ware het niet dat je hier beter gewoon

PHP:

$userIsGotter = ( $gotDesc == 'leet' );

kunt gebruiken In dat soort gevallen gebruik ik dus vrijwel altijd bovenstaande in geval van booleans en de ? ... : .... in het geval van andere typen

Mja, als je een var een waarde wil geven afhankelijk van een if ding, gebruik ik ook gewoon ?:

PHP:

<?
$var = (($bla > 5) ? true : false);
?>

[internetinfo]

Niet altijd even overzichtelijk, maar gek genoeg kan ik meestal m'n eigen troep wel weer vinden

PHP:

<? 
$ip = getenv("REMOTE_ADDR"); 
if($ip=="012.345.678.910") 
{ 
  echo "gaat u maar weg"; 
  die(); 
} 
else 
{ 
  echo "komt u verder"; 
} 
?>

en

PHP:

if (!$rs = mysql_query($sql,$db)) {
        die("sql error: $sql"); 
    }

[elgringo]

alienfruit schreef op 24 oktober 2004 @ 14:42:
Nou files van 2000regels vind ik maar weinig hoor
Mijn editor heeft alleen al rond 35.000 regels waarbij er twe bestanden zijn met rond de 10.000 regels en de rest is verdeeld over kleinere bestanden voor undo, painting, parser/compiler e.d. (geschreven door MartinW zodat ie bloedsnel is ) Mijn editor heeft echt geen moeite met 2000 regels te syntax highlighten, is het misschien een editor die de RichEdit control gebruikt ofzo

Nou files van 2000regels vind ik maar weinig hoor
Mijn editor heeft alleen al rond 35.000 regels waarbij er twe bestanden zijn met rond de 10.000 regels en de rest is verdeeld over kleinere bestanden voor undo, painting, parser/compiler e.d. (geschreven door MartinW zodat ie bloedsnel is ) Mijn editor heeft echt geen moeite met 2000 regels te syntax highlighten, is het misschien een editor die de RichEdit control gebruikt ofzo

Ik heb bij echostra een afstudeerproject gedaan en daar was de regel bij meer dan 500 regels code meerdere files van maken.

Files van 500+ regels zijn erg onoverzichtelijk, hoe net je code ook is. Ik werkte is met C en daarbij drukte in functies in een ander bestand

Tevens heb ik me daar iets heel makkelijka aangeleerd:
een string: $sEenString
een integer: $iEenInteger
een char: $cChar

Deze kende nog wat varianten met signed en unsigned. Tevens heb ik me aangeleerd erg efficient te proggen. Ik heb destijds fat16 en fat32 gepoort op een settopbox welke eerst een snelheid van 1mB/s haalde, na wat geknutsel en geoptimaliseer kwamen we op 8x zo snel uit. Dit was incl het opsporen van lange bestandsnamen.

Ik heb nog wel een programmeer probleem:
Ik gebruik meestal een while(1) icm een break. deze zijn vele malen sneller dan met een statement erin. Rekenen doe ik als het kan bitwise, gaat ook veel sneller maar is niet leesbaar.
Verder ben ik nogal buggie op aan te rotzooien met pointers. Array's doorloop ik dmv een pointer te verhogen (ook ivm snelheid) en soms wil het wel eens dat ik in een verkeerd geheugen adresje aan het poeren ben.

[Reveller]

Van een heel andere orde: het gebruik van globals. In sommige van mijn functies roep ik meerdere (lees: 4 tot 8 ) globals aan. In [rml][ PHP] Recursie werkt niet goed?[/rml] zegt pjotrk: "globals vermijd ik sowieso liever eigenlijk".

Een simpel voorbeeld van mijn manier:

PHP:

$node = 9;

function buildTree()
{
  global $node;

  db_query("SELECT FROM tree WHERE node_id =".$node);
}

Pjotrk:

PHP:

$node = 9;

function buildTree($input)
{
  db_query("SELECT FROM tree WHERE node_id =".$input);
}

function buildtree($node)

Wat is eigenlijk de regel wanneer je wel of geen globals opneemt in je functies? En daarbij aansluitend: hoe is jullie benamingsconventie voor variabelen?

PHP:

$ditIsMijnVariabele en eenMooieFunctie() of

$dit_is_mijn_variabele en nog_een_functie()

In een artikel van Joe Celko heb ik eens gelezen dat hij erg anti $dit_soort_variabelen_is. Immers: "we leven niet meer in 1970". De underscore schijnt iets te maken te hebben met technische beperkingen van toen, welke nu opgeheven zijn?

[ Voor 3% gewijzigd door Reveller op 25-10-2004 20:18 ]

[Erkens]

Reveller schreef op 25 oktober 2004 @ 20:17:
Van een heel andere orde: het gebruik van globals. In sommige van mijn functies roep ik meerdere (lees: 4 tot 8 ) globals aan. In [rml][ PHP] Recursie werkt niet goed?[/rml] zegt pjotrk: "globals vermijd ik sowieso liever eigenlijk".

In principe gebruik ik nooit globals juist omdat het makkelijker kan leiden tot fouten.

En wat betreft de naamgeving, tja ik kies liever niet voor de underscore oplossing omdat dat meer typwerk is behalve met constanten want die gaan in full CAPS en daar wel underscores. Overigens in mijn database gebruik ik wel constanten omdat hoofdletters met MySQL niet altijd goed gaan (windows/*nix)

[Orphix]

Reveller schreef op 25 oktober 2004 @ 20:17:
Wat is eigenlijk de regel wanneer je wel of geen globals opneemt in je functies?

Over het algemeen gebruik je nooit globale variabelen. De belangrijkste reden hiervoor is de beheersbaarheid. Door het gebruik van globals is het onduidelijk welke variabelen de aangeroepen functie allemaal gebruikt.

Als ik jouw functie buildTree() aanroep heb ik er geen idee van dat jij de variabele $node gebruikt. Het kan zo zijn dat ik zelf $node bijvoorbeeld op 0 zet, omdat ik $node gebruik voor andere functionaliteit. Het resultaat is brakke programmatuur.

Nu is dit bij een enkel php bestand geen groot probleem (in feite is een php bestand een grote functie), maar bij grotere applicaties en vooral waarbij veel code als componenten worden aangeboden is het absoluut een no-go.

Er zijn nog legio andere argumenten op te noemen om ze niet te gebruiken maar daar is genoeg over te vinden op het internet. Je kan het beste gewoon aan leren nooit globale variabelen te gebruiken

[pjotrk]

Precies mijn reden om geen globals te gebruiken inderdaad, bovendien zie ik ook geen enkel voordeel in het gebruik van globale variables.

PHP:

$node = 9; 

function buildTree() 
{ 
  global $node; 

  db_query("SELECT FROM tree WHERE node_id =".$node); 
}

Is net zo makkelijk op te lossen zonder globals

PHP:

$node = 9; 

function buildTree($node) 
{ 
  db_query("SELECT FROM tree WHERE node_id =".$node); 
}

buildTree($node);

edit:
oeps zelf gaf je al hetzelfde voorbeeld

Wat naar mijn mening toch een heel stuk netter is en bovendien ook prettiger werkt. Je hoeft er nu niet meer op te letten dat je de variable $node eerst goed set voordat je buildTree() aanroept.

Daarnaast is de herbruikbaarheid van je functies ook meteen weg door het gebruik van globale variables. Je kan/mag er niet vanuit gaan dat een script altijd een bepaalde variable in de globale scope heeft zitten. Dit zie ik toch nog wel redelijk vaak gebeuren, voornamelijk voor databaseconnectie variables als '$dbConn'.

Nog vervelender wordt het wanneer functies variables uit de globale scope ook nog eens gaan aanpassen....


Voor namen van variables gebruik ik eigenlijk altijd camelcase ($ditIsMijnVariabele), teneerste is het korter , en ik vind het het prettigste lezen, bovendien is camelcase geloof ik ook wel de meest gebruikte manier om variables te noteren.

[ Voor 4% gewijzigd door pjotrk op 25-10-2004 21:14 ]

[whoami]

Ik denk dat ik m'n stijl al eens in dit of dit topic uit de doeken gedaan heb.

Veel is het waarschijnlijk nog niet veranderd:

code:

if( conditie )
{
    DoSomething ();
}
else
{
   DoSomethingElse ();
}

code:

// hier komt dus inline xml-comments (C#).
void   DoSomethingWithParameters ( string    firstName,
                                   string    lastName,
                                   int       age )
{
     // Do stuff
}

[Hans1990]

Even een 'kleine' code uit mijn systeem gehaald om even snel te laten zien hoe ik code

PHP:

// class zooi enzo
    function initUser() {
        
        $user = array();
        
        if (!isset($_COOKIE["userHash"]))
            return $this->startGuest();
        
        // Controleer vanuit de settings of er op de frontend gebruikers systeem moet worden ingeschakeld
        if ($this->settings['users']['activeOnFrontend'] == true) {
            
            // Controleer of de gebruikers hash (die in de cookie staat) voorkomt in de database
            $sUser = $this->query("
                SELECT
                    *
                FROM
                    users
                LEFT JOIN
                    userGroups
                ON 
                    userGroups.userGroupID = users.userStatus
                OR
                    userGroups.userID = users.userID
                LEFT JOIN
                    userFields
                ON
                    userFields.userID = users.userID
                WHERE
                    users.userHash = '" . $_COOKIE["userHash"] . "'
                AND
                    users.userActive = '1'");
            
            if ($this->num($sUser) == 0) {
                
                $this->logout();
                
                $this->startGuest();
                
            } // end if
            else
                $user = array_merge(
                    array(
                        'ingelogd' => 1
                    ), 
                    $this->fetch($sUser)
                );
            
        } // end if
        else
            
            // Zijn we in de admin ?
            if ($this->onBackend == 1) {
                
                // Controleer of de gebruikers hash (die in de cookie staat) voorkomt in de database
                $sUser = $this->query("
                    SELECT
                        *
                    FROM
                        users
                    LEFT JOIN
                        userGroups
                    ON (
                        userGroups.userGroupID = users.userStatus
                    OR
                        userGroups.userID = users.userID)
                    LEFT JOIN
                        userFields
                    ON
                        userFields.userID = users.userID
                    WHERE
                        users.userHash = '" . $_COOKIE["userHash"] . "'
                    AND
                        users.userActive = 1
                    AND
                        userGroups.accessBackend = 1");
                
                if ($this->num($sUser) == 0)
                    die("Geen toegang");
                else
                    $user = array_merge(
                        array(
                            'ingelogd' => 1
                        ), 
                        $this->fetch($sUser)
                    );
                    
            } // end if
            else
                $this->startGuest();
        
        if (!isset($user["userStatus"]) OR $user["userStatus"] == $this->settings["users"]["guestGroup"])
            return $this->startGuest();
        
        $this->uInfo = $user;
    } // end function

Ik doe btw nooit HTML in me PHP, daarvoor gebruik ik natuurlijk templates.

[ Voor 19% gewijzigd door Hans1990 op 25-10-2004 22:02 ]

[Erkens]

Hans1990 schreef op 25 oktober 2004 @ 22:00:
Even een 'kleine' code uit mijn systeem gehaald om even snel te laten zien hoe ik code

PHP:

Ik doe btw nooit HTML in me PHP, daarvoor gebruik ik natuurlijk templates.

wat is daar zo natuurlijk aan?

offtopic:
ik zou toch maar iets doen aan die $_COOKIE die je zo doorstuurt naar je DB server

[simon]

dingen als

code:

                    array(
                        'ingelogd' => 1
                    ),

Is natuurlijk een beetje lang, lijkt mij. Ik vind dat je als je kijkt naar de combinatie lang/uitschrijven of naar kort, dat soms (in zo'n geval) kort netter is.

Ik denk dat je een compromis moet zoeken, waar je code leesbaar blijft, maar ook niet te lang is.

Her en der zie ik wat voorbeelden, bijvoorbeeld function bla ($vars) {, waarbij er geen newline tussen de ) en de { zit, daar ros ik er dus een newline tussen.

Eigenlijk is het beste qua leesbaarheid ook het breedst leesbaar...

[Reveller]

Ik heb wat conclusies getrokken over wat in z'n algemeenheid als net coden wordt gezien:

PHP:

/**
* Return whether the user has a cool name of not
*/

function coolStuff($arr, $firstName)
{
  if (in_array($firstName, $arr))
  {
    return 'cool name detected: '.$firstName;
  }
  else
  {
    return 'you\'re not cool'; // commentaar
  }
}

• phpDoc commentaar
• // voor 1 lijn commentaar - zijn er trouwens mensen die /* commentaar */ voor 1 regel gebruiken?
• matching brackets; ook bij enkel if - else statement ivm eventuele toekomstige uitbreiding
• camelcase variabelen en functienamen
• enkele quotes bij strings (net iets sneller en makkelijker ivm HTML properties)
• vermijden globals in functies
• tabs omgezet naar (2) spaties (de meesten hebben 4 spaties)

[ Voor 6% gewijzigd door Reveller op 25-10-2004 23:16 ]

[Erkens]

Reveller schreef op 25 oktober 2004 @ 23:15:
Ik heb wat conclusies getrokken over wat in z'n algemeenheid als net coden wordt gezien:

Ik denk dat je meer de conclusie kan trekken dat net coden inhoudt dat het overzichtelijk eruit ziet, makkelijk te lezen en vooral consequent werken.

[prototype]

Mijn god zeg, 'k kan 't niet meer aanzien, 'k moet me even mengen in de discussie en OO standpunten (voor zover ik heb gelezen van genoil) ondersteunen. Alvast mijn excuses iig als het wat onsamenhangend overkomt, aangezien ik nogal gek aan het worden ben van de hoeveelheid discrete wiskunde dat ik vandaag door m'n strot heb gestouwd

Allereerst valt me op dat er zich hier veel mensen bevinden die erg veel waarde hechten aan een top down approach c.q. procedural methode van programmeren. Hier is natuurlijk niets mis mee als we praten over relatief kleine software systemen maken, maar bij (grote) software systemen bouwen of uitbreiden kan dit een bottleneck vormen in de zin dat onderhoudbaarheid significant kleiner wordt doordat complexiteit hier vrij snel de overhand in neemt; het model simpelweg opbreken in procedures volstaat hierbij niet alleen, als we alleen al redeneren vanuit een complexiteit standpunt. Aan deze mensen even een paar sleutelwoorden voor het modeleren vanuit een object oriented standpunt: abstraction en composition.

Bij composition en abstraction gaan we uit van een probleem die we willen modeleren. Dit doen we door het complexe probleem ( het overkoepelend model) op te breken in kleinere, begrijpbare submodellen (composition) die we reduceren tot een gunstige, begrijpbare vorm (abstraction). Bij composition en abstraction moeten we oppassen dat we niet tever hiermee in doorgaan, waardoor er teveel componenten ontstaan of componenten te moeilijk van elkaar te onderscheiden zijn.

Als je dit eenmaal bewerkstelligd hebt, kun je classen bouwen/(abstract) inherenten en hierdoor reeds geschreven code gebruiken danwel uitbreiden; dit staat in schel contrast met simpelweg alleen static calls uitvoeren. Dit scheelt regels code, verkleint complexiteit en indien goed geschreven kan het resulteren tot een betere peformance, maar uiteindelijk is de algoritme het meest bepalende factor voor performance en niet whitespaces e.d. Ook gebruik je slechts code die je ook daadwerkelijk nodig hebt.


Indien goed uitgevoerd zou de afweging performance - onderhoudbaarheid niet echt meer aan de orde moeten zijn , en als je dan toch de afweging moet maken, kies dan voor onderhoudbaarheid; overcapaciteit voor performance kun je binnen 3 seconde aanschaffen itt code opnieuw van scratch opbouwen dat je ongetwijfeld veel tijd, moeite en tranen zal kosten. En ja, tijd is geld... , dus de afweging zou duidelijk moeten zijn . Goede documentatie draagt bij aan onderhoudbaarheid en dit is een GROOT voordeel als je met meerdere programmeurs aan een project werkt; hanteer hierbij allen dezelfde conventie (docstyle) zodat eenduidigheid bewerkstelligd kan worden. Duidelijke pre- en postcondities formuleren kan complexiteit ook tegengaan. Oh ja en voordat ik het vergeet, applicaties zijn zelden echt 'AF', hou rekening met de toekomst en kies onderhoudbaarheid; computerkracht wordt over tijd al steeds groter.

Een systeem bestaat over het algemeen (afhankelijk van de vereiste functionaliteit) uit minstens 3 lagen:
1. User Interface (Presentatielaag: Raampjes, weetikveel - Client)
2. Model (Codelaag: Classen etc.. - Server)
3. Data Management (Datalaag: Databasefile systeem)

Nahjah, 'k kan nog wel even doorgaan, maar 'k heb geen zin meer om te typen, 'k moet nog 500 pagina's discrete wiskunde inhalen . Ik hoop dat iig dat het bruikbaar voor iemand kan zijn

[Cavorka]

Nog even terugkomend op de Globals.

Soms is er echt geen redelijke mogelijkheid om er onderuit te komen. Voorbeeld (ook een stukje van hoe mijn classes eruit zien trouwens, met uberduidelijke scheiding tussen de methods in, in vind dat nogal handig):

PHP:

// WIP, hier moet nog wel wat gebeuren. :)

Class CMSMain {

    var $IncludedFiles = 0 ;
    
// Include Class ------------------------------------------------------------- Include Class

    function includeClass ($class, $mode) {
        
        global $QueryCount, $PerformedQueries, $ParseTime, $IncludedFilesNum, 
$IncludedFilesNames, $TemplateNum, $TemplateNames, $TemplateErrors ;
        
        if($mode == 1) {
            $classDir = CLASS_DIRECTORY ;
            $classExtension = CLASS_EXTENSION ;
        
            $classFile = $classDir . $class . $classExtension ;
            
            if(is_file($classFile)) {
                include ($classFile) ;
                
                $this->IncludedFiles++ ;
                $this->IncludedNames[] = $classFile ;
            }
            else { ; }
        }
        else {
            if(is_file($class)) {
                include ($class) ;
                
                $this->IncludedFiles++ ;
                $this->IncludedNames[] = $class ;
            }
            else {
                // File is missing :/ Error? :\
            }
        }
        
    }   // EoF: includeClass

## Include Class ============================================================= Include Class

(...etc...)

}   // EoC: CMSMain

Ik gebruik hier dus global omdat ik een functie heb die bestanden include, en niet vanuit de 'global scope' include. De geïnclude files krijgen dus de scope van de functie.

Echter in mijn index.php wil ik een deel er weer uit krijgen (ik heb juist een functie omdat ik achteraf wil weten welke bestanden, templates, queries etc. heb gebruikt bij het maken van de pagina):

PHP:

// Sum All Results From All Files
    $AllTemplateNames = $BWT->ArraySumText($TemplateNames, '<br />', 2) ;
    $AllTemplateErrors = $BWT->ArraySumText($TemplateErrors, '<br />', 2) ;
    $AllIncludedFiles = $BWT->ArraySumText($IncludedFilesNames, '<br />', 2) ;
    $AllPerformedQueries = $BWT->ArraySumText($PerformedQueries, '<br />', 2) ;

Wat dit dus doet is alle resultaten van sommeren (elke entry uit de array (bijv. IncludedFilesNames) en dan met een enter erachter) zodat je een overzicht krijgt. Want in elke module staat weer onderaan:

PHP:

// File Summaries
$QueryCount['agenda'] = $AgendaData->logQuery(0) ;
$PerformedQueries['agenda'] = $AgendaData->getQueries() ;
    
$IncludedFilesNum['agenda'] = $CMSMain->getIncludedFileNum() ;
$IncludedFilesNames['agenda'] = $CMSMain->getIncludedFileNames() ;
    
$TemplateNum['agenda'] = $template->getTemplateNum() ;
$TemplateNames['agenda'] = $template->getTemplateNames() ;
$TemplateErrors['agenda'] = $template->getTemplateErrors() ;

Soms 'moet' je het dus wel gebruiken.

[ Voor 37% gewijzigd door Cavorka op 26-10-2004 00:43 ]

[CyBeR]

Reveller schreef op 25 oktober 2004 @ 20:17:

In een artikel van Joe Celko heb ik eens gelezen dat hij erg anti $dit_soort_variabelen_is. Immers: "we leven niet meer in 1970". De underscore schijnt iets te maken te hebben met technische beperkingen van toen, welke nu opgeheven zijn?

Ehm. Mogen er tegenwoordig spaties in variabelenamen dan? Nope. Daarom gebruiken we underscores: ze komen dicht in de buurt van spaties, maar zijn het niet. ditSoortVariabelen vind ik persoonlijk erg lelijk en moeilijk leesbaar. Bovendien is het gewoon vreemd dat die eerste letter dan maar geen hoofdletter hoeft te zijn (en ja, ik ben bekend met het onderscheid metHode/Klasse).

Doe mij maar lekker underscores. dit_soort_variabelen vind ik veel mooier en fijner lezen (en dat is toch het punt, dacht ik?) dan ditSoortVariabelen (camel stijl), of erger nog hongaarse stijl (vb: $sDitSoortDingen).

[prototype]

Reveller schreef op 25 oktober 2004 @ 23:15:
• camelcase variabelen en functienamen

In het geval van PHP ben ik het daar niet mee eens, daar er voorgedefinieerde methode namen bestaan als in_array etc.. die een underscore seperated notation gebruiken; camelcase hier dan vervolgens bij hanteren oogt in mijn mening als inconsistent. Maar ja, smaken verschillen.

[jvdmeer]

prototype schreef op 26 oktober 2004 @ 00:37:
Mijn god zeg, 'k kan 't niet meer aanzien, 'k moet me even mengen in de discussie en OO standpunten (voor zover ik heb gelezen van genoil) ondersteunen. Alvast mijn excuses iig als het wat onsamenhangend overkomt, aangezien ik nogal gek aan het worden ben van de hoeveelheid discrete wiskunde dat ik vandaag door m'n strot heb gestouwd

[...]

Een systeem bestaat over het algemeen (afhankelijk van de vereiste functionaliteit) uit minstens 3 lagen:
1. User Interface (Presentatielaag: Raampjes, weetikveel - Client)
2. Model (Codelaag: Classen etc.. - Server)
3. Data Management (Datalaag: Databasefile systeem)

Ik ben volledig bekend met OO binnen Delphi, waar ik bijna alles in classes gooi, echter ik gebruik tegenwoordig ook PHP en daar zie ik nog steeds niet het nut van classes. Ik snap nog niet hoe OO je kan helpen in een stateless situatie als een html-pagina. Na het uitpoepen van een pagina zijn v.w.b. de server volgens mij weer alle objecten vernietigd.
Waarom elke keer de objecten intialiseren, een of meerder procedures uitvoeren en daarna weer vernietigen? Dit kan volgens mij net zo goed langs procedurele weg: variabelen zetten, bewerken, uitvoeren.

Kan iemand uitleggen waarom OO in PHP? (evt. andere discussie)

[Verwijderd]

Ok, ik dan ook maar

Een stukje code van mij om mijn "stijl" aan te geven.. Grote projecten nu, dus het werd eens tijd voor een unanieme stijl (ff snel iets uit de losse pols neergekrabbeld):

PHP:

<?php

/*
 *  Project:    Bla die bla
 *  Author:     Michiel
 */

class template
{
    var $template;

    function template ()
    {
        # Doe iets
        echo "blaat!";
    }

    function actie ( $blaat )
    {
        # Woei
        echo $blaat;
    }
}

$cTemplate  = new template();

switch( $_GET['actie'] )
{
    case "een":
        $cTemplate->actie('dat is een');
    break;

    case "twee":
    default:
        $cTemplate->actie('en de rest');
    break;
}

?>

Veel whitespace dus.. Ik hou van ruimte in mijn code (overzichtelijkheid)...

[ Voor 16% gewijzigd door Verwijderd op 26-10-2004 01:25 ]

[prototype]

jvdmeer schreef op 26 oktober 2004 @ 01:22:
[...]


Ik ben volledig bekend met OO binnen Delphi, waar ik bijna alles in classes gooi, echter ik gebruik tegenwoordig ook PHP en daar zie ik nog steeds niet het nut van classes. Ik snap nog niet hoe OO je kan helpen in een stateless situatie als een html-pagina. Na het uitpoepen van een pagina zijn v.w.b. de server volgens mij weer alle objecten vernietigd.
Waarom elke keer de objecten intialiseren, een of meerder procedures uitvoeren en daarna weer vernietigen? Dit kan volgens mij net zo goed langs procedurele weg: variabelen zetten, bewerken, uitvoeren.

Kan iemand uitleggen waarom OO in PHP? (evt. andere discussie)

Ik denk dat het al meteen terug te vinden is in de taal opbouw, PHP 4 leent zich niet geheel aan het OO principe, slechts tot op een zekere hoogte. Maar terugkomend op je vraag, uiteraard kan het ook op de procedurele weg, maar je wil denk ik vooral oog houden op de toekomst mbt uitbreidbaarheid en complexiteit verminderen.

[prototype]

Cavorka schreef op 26 oktober 2004 @ 00:39:
Nog even terugkomend op de Globals.
...

Soms 'moet' je het dus wel gebruiken.

Allereerste wat me opvalt: keyword uppercasing , niet doen en als je het toch doet, doe het dan overal, Class, If, Else etc..

Ten tweede, zoals ik je code even 123 snel lees, zie ik helemaal geen behoefte aan globals, daar je deze als instantievariabelen kunt declareren binnen je classe en deze bv kunt setten in je constructor.

Mithrandir schreef op 25 oktober 2004 @ 18:45:
De short-hand notatie, zonder brackets, gebruik ik vaak als er 1 ding wordt aangepast. Voorbeeldje:

PHP:

if($gotDesc = 'leet')
  $userIsGotter = true;
else
  $userIsGotter = false;

[/php]

Doe dan echt stoer:

PHP:

<?php
    ($gotDesc == 'leet') ? $userIsGotter = true : $userIsGotter = false;
?>

Korter is per definitie niet duidelijker, bah.

[ Voor 107% gewijzigd door prototype op 26-10-2004 02:03 ]

[Macros]

prototype schreef op 26 oktober 2004 @ 01:45:
Doe dan echt stoer:

PHP:

<?php
    ($gotDesc == 'leet') ? $userIsGotter = true : $userIsGotter = false;
?>

Korter is per definitie niet duidelijker, bah.

Wannabe

PHP:

    $userIsGotter = ($gotDesc == 'leet') ?  true : false;

Alleen is hier een if/else onnodig:

PHP:

    $userIsGotter = $gotDesc == 'leet';

[prototype]

Macros schreef op 26 oktober 2004 @ 02:12:
[...]

Wannabe

PHP:

    $userIsGotter = ($gotDesc == 'leet') ?  true : false;

Alleen is hier een if/else onnodig:

PHP:

    $userIsGotter = $gotDesc == 'leet';

Ik wilde zo dicht mogelijk bij het oorspronkelijke voorbeeld blijven

[ Voor 6% gewijzigd door prototype op 26-10-2004 02:15 ]

[Anders]

prototype schreef op 26 oktober 2004 @ 00:47:

In het geval van PHP ben ik het daar niet mee eens, daar er voorgedefinieerde methode namen bestaan als in_array etc.. die een underscore seperated notation gebruiken; camelcase hier dan vervolgens bij hanteren oogt in mijn mening als inconsistent. Maar ja, smaken verschillen.

CamelCase is dan idd inconsistent. Probleem bij de underscore-discussie, als je uit wilt gaan van PHP, is echter wel weer dat PHP daar zelf ook een ontiegelijke zooi van maakt.

strip_tags
stripcslahes
stripslashes

str_pad
str_repeat
strcmp
strcasecmp
strtolower

addslashes
get_html_translation_table
getallheaders
get_class_vars
getdate
gettimeofday
get_defined_functions
gethostbyaddr
getprotobyname
get_loaded_extensions
getlastmod
get_current_user
getmypid

php_sapi_name
phpinfo
php_uname
phpversion

readfile
readlink
read_exif_data

.. er is echt geen lijn in te ontdekken.

[Genoil]

jvdmeer schreef op 26 oktober 2004 @ 01:22:
[...]
Waarom elke keer de objecten intialiseren, een of meerder procedures uitvoeren en daarna weer vernietigen? Kan iemand uitleggen waarom OO in PHP? (evt. andere discussie)

Toen ik nog PHP4 gebruikte vroeg ik me het idd ook sterk af, maar nu ik met PHP5 werk voelt het allemaal een stuk logischer aan, dat OO. In combinatie met een object persistance library als Propel of MyObjects heb je op abstract niveau gewoon "live" objecten, die weliswaar op een lager niveau de hele tijd opnieuw in elkaar gezet worden, eventueel gemodificeert, naar de database gesaved en weer afgebroken, maar daar heb je in de praktijk eigenlijk bijzonder weinig last van. De Model classes worden al voor je gebouwd, hetgeen een hoop ontwikkeltijd scheelt en de onervareen OOPer (waarvan acte) en juiste zet in de richting geeft voor het bouwen van de rest van je app.

Ik denk serieus dat dit hele OO ding me 2 tot 4 keer zo snel heeft gemaakt in het bouwen van webapp(je)s.

[Wolfboy]

Macros schreef op 26 oktober 2004 @ 02:12:
[...]

Wannabe

PHP:

    $userIsGotter = ($gotDesc == 'leet') ?  true : false;

Alleen is hier een if/else onnodig:

PHP:

    $userIsGotter = $gotDesc == 'leet';

Doe het dan direct goed

PHP:

$userIsGotter = ($gotDesc == 'leet');

n00b

[Bergen]

Verwijderd schreef op 26 oktober 2004 @ 01:24:

PHP:

<?php
switch( $_GET['actie'] )
{
    case "een":
        $cTemplate->actie('dat is een');
    break;

    case "twee":
    default:
        $cTemplate->actie('en de rest');
    break;
}
?>

Dat zou ik iets anders doen:

PHP:

<?
switch($_GET['actie']) {
    case "een":
        $cTemplate->actie('dat is een');
        break;
    case "twee":
    default:
        $cTemplate->actie('en de rest');
}
?>

Afgezien van de plaats van de brackets en de spaties binnen de haakjes: de breaks ook inspringen, omdat ze bij de uitgevoerde code horen en die laatste break zou ik achterwege laten, omdat die geen functie heeft. De regel met "case twee" heeft eigenlijk ook geen nut, maar voor de volledigheid zou ik hem er zelf ook neerzetten. Jouw hele switch-constructie zou je overigens ook gewoon kunnen schrijven als...

PHP:

if ($_GET['actie'] == "een") $cTemplate->actie(foo) else $cTemplate->actie(bar);

...maar dat terzijde.

Een (overigens ruimte vretend) leuke manier van een codeblok maken is trouwens gebruik maken van de slashes om ronde randjes te krijgen... Het werkt ook nog eens met /* en */

code:

/**********************\
* Hier staat een klein *
* stukje commentaar!   *
\**********************/

Deze methode gebruik ik zelf niet ofzo, maar liever lelijk commentaar dan geen commentaar, toch? Ik prefereer een blokje commentaar voor elke functie en verder alleen commentaar bij ifs en elses:

PHP:

<?php
    /*
     * This function checks whether this is a new visitor or not and
     * takes care of the validation of the sessionvars and the
     * pagerequest.
     */

    function checkVisitor()
    {
        if (isSet($_SESSION["page"])) { // not a new visitor
            validateSessionvars();
        } else { // new visitor!
            setDefaultSessionvars();
        }
        validatePagerequest();
    }
?>

Wat is jullie mening over de grootte van functies? De standaard ANSI-grootte (?) van een terminal is 80x24 karakters en ik gebruik altijd anderhalf keer de grootte daarvan; 120x36 karakters. Als een regel breder dan 120 karakters wordt breek ik hem op in kleinere stukjes en als hij langer wordt dan 36 regels (exclusief het blokje commentaar boven de functie) vind ik per definitie dat de functie moet worden opgesplitst, tenzij 't gaat om een lap HTML of bijvoorbeeld assemblercode. Normaal gesproken komt dat de leesbaarheid alleen maar ten goede.

[ Voor 36% gewijzigd door Bergen op 26-10-2004 04:17 . Reden: add-on ]