[ALG / PHP] Hoe netjes code afbreken?

[Reveller]

De afgelopen anderhalf jaar ben ik erg enthousiast bezig geweest met een eigen CMS'je. Omdat ik toch op een groot scherm met een hoge resolutie werk vond ik het niet nodig, en ook niet overzichtelijk, om lange regels code af te breken.

Vandaag wilde ik delen van de code uitprinten, en dat ziet er niet uit. Had ik nu maar een maximum van 80 karakters aangehouden! Enkele voorbeelden:

PHP:

// Eerste voorbeeld
function nav_item_list($unfold_items) {
  $header = array('', 'Title', array('data' => 'Access', 'align' => 'right'), array('data' => 'Operations', 'colspan' => 4, 'align' => 'right'));
  $unfold = ($unfold_items) ? explode(',', $unfold_items) : array(1);
  $rows   = _item_list($unfold);
  
  foreach (user_fetch_roles() as $rid => $role) {
    $roles.= " $rid $role";
  }
  
  $output = get_messages();
  $output.= p('Navigatie', "Overzicht navigatie menu. U kunt pagina's toevoegen, bewerken of verwijderen. De legenda voor de gebruikersgroepen is: $roles.");
  $output.= p(null, l('Maak een nieuwe pagina', 'admin/nav/add').' om aan de navigatie toe te voegen.');
  $output.= form(table($header, $rows, array('id' => 'nodelist', 'cellpadding' => 4, 'border' => 1)));

  theme('body', $output);
}

// Tweede voorbeeld
function nav_multi_tree($active_item, $level = null) {
  global $nav;

  $active_item = $active_item ? $active_item : 1;
  $level = $level ? $level : 1;
  
  $unfold_items = nav_path_to_top($active_item);
  $child_table  = nav_child_table();

  foreach ($unfold_items as $unfold_item) {
    if (isset($child_table[$unfold_item]) && $unfold_item != 0) {
      $childcode = '';
      foreach ($child_table[$unfold_item] as $child_id) {
        $child = $nav[$child_id];
        if ($child['innav'] == 1 && $child['status'] == 1 && ($child['level'] >= $level) && nav_access($child['roles'])) {
          $class = (in_array($child_id, $unfold_items)) ? 'active' : 'inactive';
          $childcode.= sprintf("<li %s>%s</li>", 'class="'.$class.'"', l($child['title'], $child['url']));
        }
      }
      if ($childcode) {
        $output = sprintf('<div class="subnav"><div class="header"></div><ul>%s</ul><div class="footer"></div></div>', $childcode).$output;
      }
    }
  }
  return $output;
}

Neem de regels 12, 13, 34, 36 en 40 als voorbeeld. Deze zijn veel te breed, maar de "flow" van de code is ihmo op deze manier wel overzichtelijker dan wanneer je deze regels gaat afbreken. Bijvoorbeeld regel 34-37:

PHP:

if ($child['innav'] == 1 && $child['status'] == 1 && 
     ($child['level'] >= $level) && nav_access($child['roles'])) {
  $class = (in_array($child_id, $unfold_items)) ? 'active' : 'inactive';
  $childcode.= sprintf("<li %s>%s</li>", 'class="'.$class.'"', 
    l($child['title'], $child['url']));
}

Ik vind de code er niet leesbaarder op geworden. Ik heb zojuist een aantal topics op GoT doorgelopen die gaan over programmeer stijlen, maar in geen van die topics wordt ingegaan op regel lengte. Mijn vragen aan jullie zijn dan ook:

• houd jij je aan een maximum aantal karakters per regel, en zo ja - hoeveel?
• stamt de 80-karakters regel niet nog uit de tijd dat unix-terminals nu eenmaal niet meer karakters op een regel konden weergeven en is die regel dan niet achterhaald?
• wat zijn jouw motieven om je eventueel aan een maximale breedte te houden? Vind je "anders kan ik niet printen" een goede reden? (Weet niet of ik m'n code om alleen die reden wil aanpassen)
• zijn er ergens standaarden te vinden over het afbreken van regels? Ik kon ze niet vinden in de MS .NET coding style bijvoorbeeld

Ik wil mijn code zo professioneel mogelijk opzetten, omdat ik geen zin heb om alles over twee jaar te moeten gaan herschrijven. Wil een standaard code base waar ik telkens uit kan putten / die ik telkens kan verbeteren volgens vaste regels. Ik gebruik PHPdoc commentaarstijl en heb al vaste conventies voor variabele-namen, etc. Regel lengte ontbreekt nog echter. Hoe doen de pro's het?!

[NMe]

Ik hou me netjes aan de 80 karakters per regel. Om te beginnen is dat inderdaad een stuk handiger met printen, en daarnaast is het veel makkelijker om je code te lezen bij lagere resoluties.

Overigens zijn er code formatters op de markt waarmee het in principe wel mogelijk is om je code netjes weer te geven op een maximale breedte, maar daar zul je even op moeten Googlen.

[prototype]

Je zegt dat je je code zo professioneel mogelijk wil schrijven zodat je over twee jaar het gebeuren niet meer opnieuw hoeft te herschrijven. Je code ziet daar echter nog niet geheel naar uit
Allereerst de issue van html binnen je code, opzich niets mis mee als het je view betreft in het MVC paradigm. Een hoop mensen echter, waaronder ik , zijn van mening dat html code scheiden van code constructs wat flexibeler is, en dat zul je denk ik ook terug zien in de omvang van je logics; bijkomend voordeel is dat iemand die de layout wil aanpassen geen kennis hoeft te hebben van PHP. Opzich gaat dat nu ook al enigzins op, aangezien ik zie dat je wel met CSS werkt, maar het scheiden brengt ook met zich mee dat bij verandering van de markup structuur je minder kans hebt op broken code. Je kan tijdens het editten namelijk makkelijk iets breken in de code... en dat is zonde, kost je alleen maar tijd
Standaard 'code base' kun je bewerkstelligen door compositie en abstractie. Je breekt je relatief grote complexe systeem dus op in kleinere, en daarmee vaak ook eenvoudiger te begrijpen onderdelen. Het doorvoeren van abstractie zorgt ervoor dat je onderdelen eenvoudig kunt vervangen met een ander van dezelfde soort, maar met een andere implementatie. Het genoemde 'template' voorbeeld van boven is een toepassing ervan zou je kunnen stellen. Tel daar object orientatie bij op, en uitbreidbaarheid kan zich dan uiten door overerfing, en een hele reeks aan mogelijkheden die hiermee gepaard gaan
Even terugkomend op je code, hetgeen dat je regels echt zo lang maakt, zijn de UI teksten en lange boolse expressies. Nu is het good practice als je je teksten niet als 'static final string' in je code zet, want wat nou als je een andere taal wil gaan ondersteunen? Of wat nou als je een gewoon een verandering wil doorvoeren in je teksten. In het huidige geval zal een iemand dan door code moeten 'baggeren', en daarbij is het de vraag of je dan niet tijdens het editten iets stuk maakt Deze vervangen door bijvoorbeeld constanten is misschien al een beter idee
Dan je boolse expressies. Zoals ik het nu bekijk programmeer je erg defensief. Daar is opzich niet zoveel mis mee, maar zoals je zelf al merkt neemt je code erg toe in omvang, dat de herbruikbaarheid in het gevaar brengt; je code wordt er ook nog eens te specifiek door, waardoor het misschien niet voor andere dingen gebruikt kan worden die wel voor 90% overeenkomen, door de 'strenge checks'. Design by contract is een principe die gebruikt wordt om pre- en postcondities toe te kennen aan bepaalde methodes, om defensief programmeren tegen te gaan. Je stelt als het ware voorwaarden, waar iemand aan moet voldoen alvorens de methode 'correct' uitgevoerd wordt. Deze voorwaarden zijn precondities, en de consequenties ervan wordt gedefinieerd in de postconditie. Je hebt dus nu als het ware de verantwoordelijkheden verplaatst van je model naar je controller. Meer erover kun je iig vinden in m'n sig, aangezien ik daar op een blauwe maandag eens een lang artikel over heb geschreven
Wat je overigens ook wil proberen is nested constructs te vermijden op een regel te plaatsen Tegenwoordig werken we veelal met freeform talen, en van dat gegeven mag je best gebruik maken, i.e. extra whitespaces.
Het aanhoudne van een maximum aantal karakters per regel, is om bij mezelf te voorkomen dat ik niet teveel in een statement ga proppen Het is dus voor mij als het ware een indirecte indicatie, plus het bevorderd de leesbaarheid zeer.
Nahjah, succes iig my 2 cents.

[XWB]

Hmm, nooit last van eigenlijk. Tekst gaat gewoon in een language file die ik in de init include. Voor de rest niet vies zijn van enkele enters meer te zetten Enkele voorbeeldjes:

In plaats van de waarden uit een array allemaal achter elkaar te zetten, zet je ze onder elkaar:

PHP:

$blaat = array (
        0 => 'miep',
        1 => 'blaat',
        2 => 'test'
);

Hetzelfde voor SQL code:

PHP:

$sql = 'UPDATE 
                table
        SET
                field1 = "bla",
                field2 = "bla2"
        ';

Grote if structuren gewoon op meerdere regels:

PHP:

if ( isset($_GET['miep']) && $_GET['miep'] != ''
     && isset($_GET['blaat']) && $_GET['blaat'] != ''
     && isset($_GET['test']) && $_GET['test'] != '' )

Ook voldoende spaties zetten, dus niet class="'.$class.'" maar class = "' . $class . '"

Dan hebben we de benaming van variabelen. Netjes is om het type van de var aan te duiden, in de vorm van $iTel. Hierbij weet je direct dat Tel een integer is. Hetzelfde voor functies. Een boolean functie, welke een true of een false terug geeft, kan je bEenFunctie() noemen. Moet wel zeggen dat ik dit soort benamingen zelf niet altijd toepas (toch veel minder voor privé gebruik)

[ Voor 102% gewijzigd door XWB op 26-03-2006 22:46 ]

[YopY]

Ik gebruik zelf Eclipse voor het PHP-devven (niet dat ik professioneel ben, voor een hobby siteje), en daarin zitten een paar handige dingetjes met betrekking tot de 80 kolommen regel. Ten eerste een lijn die aangeeft waar de 80 grens zit, ik ga er soms wel iets overheen, maar da's niet het ergste. Ten tweede is het edit veld iets van 100 kolommen breed op mijn computer (en ik heb een resolutie van 12nogwat * 1024), dus je merkt het snel als je regels te breed zijn. En tenslotte kun je gewoon op enter drukken als je bijvoorbeeld een lange echo-statement hebt, Eclipse zet er vanzelf punten en sluit / open quotes voor en achter.

Als je in jouw code-voorbeeld dus in regel 12 een enter of twee zet, maakt Eclipse er vanzelf iets moois van, dat ook gewoon nog werkt. Ik zou in ieder geval een editor zoeken die een lijn laat zien op 80 kolommen (of 100), zodat je zelf een richtlijn hebt hoe breed je code moet zijn.

Zoals vaak word gezegd, een programmeur / scripter kan zijn eigen code nog zo overzichtelijk / handig vinden, maar ze moeten het eigenlijk zodanig maken dat iedereen het kan bekijken en iedereen een aanpassing moet doen. Ook voor jezelf, als je bijvoorbeeld er een jaar niet mee bezig bent en je duikt weer in de code, moet je eerst opzoeken waar iets is. En het word al helemaal erg als je het op een computer met een lagere resolutie doet.

[Verwijderd]

Hacku schreef op zondag 26 maart 2006 @ 22:40:
Dan hebben we de benaming van variabelen. Netjes is om het type van de var aan te duiden, in de vorm van $iTel. Hierbij weet je direct dat Tel een integer is. Hetzelfde voor functies. Een boolean functie, welke een true of een false terug geeft, kan je bEenFunctie() noemen.

Die zgn. Hongaarse notatie vind ik eigenlijk maar vies. CamelCase is imho erg vervelend om naar te kijken. Sowieso horen types niet in variabelenamen. Zulke procesgegevens horen door je IDE bijgehouden te worden.

[prototype]

Uhm, sinds wanneer dient de naamgeving van een identifier de type ervan te specificeren? Een programeertaal dient zelf te typeren, en in het geval van PHP waarbij er gekozen is voor weaktyping, dan heeft het _BAR_ weinig effect in de praktijk, daar het eenvoudig mogelijk is om een $iTel een string te assignen

[Wim-Bart]

prototype schreef op maandag 27 maart 2006 @ 02:17:
Uhm, sinds wanneer dient de naamgeving van een identifier de type ervan te specificeren? Een programeertaal dient zelf te typeren, en in het geval van PHP waarbij er gekozen is voor weaktyping, dan heeft het _BAR_ weinig effect in de praktijk, daar het eenvoudig mogelijk is om een $iTel een string te assignen

Ja, je hebt gelijk, nee, er zijn andere redenen.

Wanneer je Bijvoorbeeld $iVariabele naam aanhoud en je strict houdt aan dit consequent toepassen maakt dit je code stuk overzichtelijke en eenvoudigen na te pluizen. Standaard gebruik ik bijvoorbeeld $ayXXXXX voor array's. Ik haat mixedtyped arrays, bijvoorbeeld een array van strings= $asMijnArray. Voor Objecten/Classes gebruik ik altijd $oXXXX, integers $iXXXXX, floats $fXXXXX, bool $bXXXX etc. etc.

Je forceert er geen typecasting mee, maar op een paar 1000 regels code weet je wel wat een bepaalde variabele is.

Daarnaast geloof ik ook in initialiseren. Gebruik ik de variabele $iCounter dan zet ik $iCounter= 0; in mijn code. Heeft geen zin, maar wel zo netjes. Daarnaast neem ik de overhead van SetType(var,type) op de koop toe, vooral als ik getallen ga vergelijken, input validators of classes maak. Voorkomt een hoop ellende.

Gebruik overigens ook debugcode voor variabele checking. Heb bijvoorbeeld de functie:

PHP:

  function CheckInt(&$iValue,$sVarName=NULL)
  {
    if (!APP_DEBUG) return TRUE;
    if (!is_int($iValue)) die("Integer verwacht". (is_null($sVarName)?".":" voor variabele \$".$sVarName) );
    return TRUE;
  }

In de code:

PHP:

define(APP_DEBUG,TRUE);

..
..
..

CheckInt($iCounter,'iCounter');
CheckInt($iTop,'iTop');

if ($iCounter===$iTop)
{
}

[ Voor 3% gewijzigd door Wim-Bart op 27-03-2006 02:53 ]

[prototype]

wim-bart schreef op maandag 27 maart 2006 @ 02:53:
[...]


Ja, je hebt gelijk, nee, er zijn andere redenen.

Wanneer je Bijvoorbeeld $iVariabele naam aanhoud en je strict houdt aan dit consequent toepassen maakt dit je code stuk overzichtelijke en eenvoudigen na te pluizen. Standaard gebruik ik bijvoorbeeld $ayXXXXX voor array's. Ik haat mixedtyped arrays, bijvoorbeeld een array van strings= $asMijnArray. Voor Objecten/Classes gebruik ik altijd $oXXXX, integers $iXXXXX, floats $fXXXXX, bool $bXXXX etc. etc.

Je forceert er geen typecasting mee, maar op een paar 1000 regels code weet je wel wat een bepaalde variabele is.

Daarnaast geloof ik ook in initialiseren. Gebruik ik de variabele $iCounter dan zet ik $iCounter= 0; in mijn code. Heeft geen zin, maar wel zo netjes. Daarnaast neem ik de overhead van SetType(var,type) op de koop toe, vooral als ik getallen ga vergelijken, input validators of classes maak. Voorkomt een hoop ellende.

Heheh, ik daarentegen geloof in goede semantiek, en vindt het $iCounter gebeuren eigenlijk een ongewenste beperking; wat nou als je in de toekomst bepaald om een counter van het type double te maken te maken? Alle $iCounters dan maar refactoren naar $dCounter? Dat is ook niet alles
Wat betreft je bezwaar met betrekking op mixed arrays, JIJ bent -als het goed is- degene die het laatste woord heeft over welke dingen erin zitten en dus ook mogen zitten. Opzich zouden generics een aardige toevoeging kunnen zijn aan PHP als men de taal sterker zou typeren, maar dat laatste is ook meteen de 'kracht' van de taal, dus ik zie het niet snel gebeuren
Ook moet je jezelf afvragen wanneer je niet meer het onderscheid kan maken tussen wat wat bevat, door de omvang nagaan of je het niet kan versimpelen. Grote code is welliswaar niet altijd onvermijdelijk, maar een ding staat wel zeker; het is niet fijn om te bewerken

Gebruik overigens ook debugcode voor variabele checking. Heb bijvoorbeeld de functie:

PHP:

  function CheckInt(&$iValue,$sVarName=NULL)
  {
    if (!APP_DEBUG) return TRUE;
    if (!is_int($iValue)) die("Integer verwacht". (is_null($sVarName)?".":" voor variabele \$".$sVarName) );
    return TRUE;
  }

In de code:

PHP:

define(APP_DEBUG,TRUE);

..
..
..

CheckInt($iCounter,'iCounter');
CheckInt($iTop,'iTop');

if ($iCounter===$iTop)
{
}

Wat betreft je methode gebeuren, sinds versie 5 ondersteund PHP typehinting. Uit eigen ervaring werkt dit nog niet je van het met primitieve typen, maar voor eigen gedefinieerde typen werkt het 'prima' Via die wegen kun je ook al het een en ander afdwingen, en kun je weer wat defensieve if statements verwijderen. Ook kun je met design by contract via assertions (die ook PHP ondersteund) hetzelfde bewerkstelligen in minder regels; de regel is dan, "if code fails, it should fail hard". Dit vertaalt zich in, als de preconditie niet is nagekomen dan zal de code abrupt tot een einde komen. In jouw geval, ga je coulant om met problemen, waarom? Waarom zou je eventueel een bug onopgemerkt willen hebben tijdens runtime, wanneer je debug flagje op uit staat? Juist DAT is niet de bedoeling Voorkomen is beter dan genezen enzo

[ Voor 7% gewijzigd door prototype op 27-03-2006 04:58 ]

[Janoz]

wim-bart schreef op maandag 27 maart 2006 @ 02:53:
Je forceert er geen typecasting mee, maar op een paar 1000 regels code weet je wel wat een bepaalde variabele is.

Ikzelf zorg ervoor dat de scope van een variabele nooit ook maar in de buurt van de 1000 regels komt.

[Reveller]

Hieronder heb ik een voorbeeld functie die ik nu heb afgebroken tot een maximum regellengte van 80 karakters. De leesbaarheid is er m.i. niet op vooruit gegaan, maar dat komt waarschijnlijk voornamelijk omdat ik nog niet precies weet hoe je een regel goed afbreekt. Heeft iemand nog tips?

PHP:

/**
 * Returns a rendered (admin) menu tree. Don't render the menu when it is 
 * hidden, or when it has no callback nor children. The latter check avoids that
 * useless links are being rendered.
 *
 * @param string $parent
 * @param bool $hidden
 * @return A html ordered list
 */
function _menu_tree($parent = '', $hidden = 0) {
  global $menu;
  
  $output = '';

  if (isset($menu[$parent]) && $menu[$parent]['children']) {
    usort($menu[$parent]['children'], '_menu_sort');
    
    foreach ($menu[$parent]['children'] as $item) {
      $visible = menu_has_visible_children($item);
      
      if (($menu[$item]['hidden'] == MENU_SHOW && 
           $menu[$item]['callback'] && $menu[$item]['access'] == 1) || 
           ($menu[$item]['hidden'] == MENU_SHOW && $visible && 
           $menu[$item]['access'] == 1)) {
        $style = ($visible ? (menu_in_active_trail($item) ? 
          'expanded' : 'collapsed') : 'leaf');
        $output .= '<li class="'.$style.'">'.l($menu[$item]['title'], $item);
      
        if (menu_in_active_trail($item)) {
          $output .= _menu_tree($item);
        }
      
        $output .= '</li>';
      }
      else if ($menu[$item]['hidden'] == MENU_HIDE && 
               $menu[$item]['children']) {
        $output .= _menu_tree($item, 1);
      }
    }

    if ($output != '' && $hidden != MENU_HIDE) {
      $output  = '<ul>'.$output.'</ul>';
    }
  }
  return $output;
}

Overigens neem ik de opmerkingen van prototype ter harte en zal eens nadenken over een minder strikte manier van programmeren. Sowieso ga ik de html en textstrings uit de php functies verwijderen en in een aparte language en template file zetten

[ Voor 33% gewijzigd door Reveller op 28-03-2006 18:45 ]

[XWB]

PHP:

if ($output != '' && $hidden != MENU_HIDE) {
      $output  = '<ul>'.$output.'</ul>';
    }

naar

PHP:

if ( $output != '' && $hidden != MENU_HIDE ) 
{
   $output  = '<ul>' . $output . '</ul>';
}

Enzo verder. Leest toch een stuk beter?

[Creepy]

Reveller: De leesbaarheid van de code die je nu net geeft is wat mij betreft meer afhankelijk van de gebruikte constructies.

PHP:

  $style = ($visible ? (menu_in_active_trail($item) ?   'expanded' : 'collapsed') : 'leaf');

Die dubbele ?'s i.c.m. met de haakjes en het opbreken van het geheel over meerdere regels maakt het voor mij minder prettig leesbaar.

PHP:

if (visible) {
   if (menu_in_active_trail($item)) {
      $style='expanded';
   } else {
      $style='collapsed';
   }
}
else {
  $style='leaf';  
}

Bovenstaande is wat langer maar wat mij betreft beter leesbaarder.
En mocht je het te lang vinden dan kan je er altijd nog een losse functie/method van maken zodat je iets krijgt ala

PHP:

$style = getItemStyle($item)

of misschien zelfs

$style = $item->getStyle();

@hacku: of je de { nu wel of niet op de volgende regel zet is wat mij betreft meer persoonlijke voorkeur zolang je maar consequent bent.

[ Voor 13% gewijzigd door Creepy op 28-03-2006 20:38 ]

[JHS]

Naast het bovenstaande zou ik langere conditions ook anders uitsmeren :

PHP:

/* Niet */

if (($menu[$item]['hidden'] == MENU_SHOW && 
    $menu[$item]['callback'] && $menu[$item]['access'] == 1) || 
    ($menu[$item]['hidden'] == MENU_SHOW && $visible && 
    $menu[$item]['access'] == 1))

/* Maar */

if(  (
       $menu[$item]['hidden'] == MENU_SHOW
       && $menu[$item]['callback']
       && $menu[$item]['access'] == 1
     )
  || (
       $menu[$item]['hidden'] == MENU_SHOW
       && $visible
       && $menu[$item]['access'] == 1
     )
 )

Maar dat is misschien overdreven naar de smaak van sommigen .

[prototype]

PHP:

(($menu[$item]['hidden'] == MENU_SHOW && 
           $menu[$item]['callback'] && $menu[$item]['access'] == 1) || 
           ($menu[$item]['hidden'] == MENU_SHOW && $visible && 
           $menu[$item]['access'] == 1))

Als je goed naar deze boolse expressie kijkt is het enige dat verschillend is, dat de ene OR-operand $visible ipv $menu[$item]['callback'] heeft. Voor de rest zijn beide expressies overeenkomstig. Dit vertaalt zich dus naar het feit dat zowel $menu[$item]['hidden'] == MENU_SHOW && $menu[$item]['access'] == 1 sowiesow altijd true moeten zijn, om deze expressie tot een waarheid te maken. Het enige is dus nu dat $visible OF $menu[$item]['callback'] true moeten zijn.
Ofwel refactoren naar:

PHP:

($menu[$item]["hidden"] == MENU_SHOW && $menu[$item]["access"] == 1 && ($menu[$item]["callback"] || $visible))

Misschien wil je eerst je code dus eens goed nakijken, voordat je het opzoekt in conventies

[ Voor 23% gewijzigd door prototype op 28-03-2006 22:31 ]

[mcdronkz]

Wellicht kun je hier iets mee, http://pear.php.net/manual/en/standards.php.

[RedHat]

Voor if constructors doe ik altijd het volgende:

PHP:

if (value) {

     /* evt commentaar */
     function();

}

Bij lange if statements afbreken per onderdeel (voor && etc een newline)

[ Voor 23% gewijzigd door RedHat op 29-03-2006 13:39 ]

[Reveller]

Als je het hebt over het maximaal aantal karakters per regel, is 80 historisch bepaald. Ik heb net wat zitten prutsen, en zag dat ik 90 karakters op een regel kwijt kan, en het dan ook nog fatsoenlijk kan printen (op courier new puntgrootte 8 ). In hoeverre is 80 een vaste grens en in hoeverre zou het een probleem kunnen zijn als ik 90 karakters per regel neem? Ik voorzie alleen problemen als mensen aan de code zouden moeten werken die 80 karakters gewend zijn. Nog andere argumenten?

[Reveller]

Ik ben uiteindelijk voor een breedte van 90 karakters gegaan. Op courier new 10pt kan ik dit keurig uitprinten. Het valt me alleen wel op dat je soms behoorlijke consessies aan leesbaarheid moet doen als je eea overzichtelijk wilt houden. Neem onderstaand voorbeeld:

PHP:

// Voor aanpassing aan 90 karakters (regels zijn 96 tekens lang)
menu('admin/user'           , 'Gebruikers'    , 'user_admin'       , 80, MENU_SHOW, $access);
menu('admin/user/browse'    , 'Overzicht'     , 'user_admin_list'  ,  0, MENU_SHOW, $access);
menu('admin/user/create'    , 'Toevoegen'     , 'user_admin_create',  1, MENU_SHOW, $access);
menu('admin/user/role'      , 'Groepen'       , 'user_admin_roles' ,  2, MENU_SHOW, $access);
menu('admin/user/permission', 'Rechten'       , 'user_admin_perms' ,  3, MENU_SHOW, $access);
menu('admin/user/rule'      , 'Toegangsregels', 'user_admin_rules' ,  4, MENU_SHOW, $access);

// Na aanpassing aan 90 karakters. Langste regel is 88 karakters
menu('admin/user', 'Gebruikers', 'user_admin', 80, MENU_SHOW, $access);  
menu('admin/user/browse', 'Overzicht', 'user_admin_list', 0, MENU_SHOW, $access);
menu('admin/user/create', 'Toevoegen', 'user_admin_create', 1, MENU_SHOW, $access);
menu('admin/user/role', 'Groepen', 'user_admin_roles', 2, MENU_SHOW, $access);
menu('admin/user/permission', 'Rechten', 'user_admin_perms', 3, MENU_SHOW, $access);
menu('admin/user/rule', 'Toegangsregels', 'user_admin_rules', 4, MENU_SHOW, $access);

Maar bijvoorbeeld ook

PHP:

// Voor: langste regel is 96 karakters
function menu($path, $title, $callback = null, $weight = 0, $hidden = MENU_HIDE, $access = 0) {
  global $menu;

  $menu[$path] = array('title' => $title, 'callback' => $callback, 
    'weight' => $weight, 'hidden' => $hidden, 'access' => $access
  );
}

// Na: langste regel is 80 karakter
function menu($path, $title, $callback = null, $weight = 0, $hidden = MENU_HIDE, 
  $access = 0) {
  global $menu;

  $menu[$path] = array('title' => $title, 'callback' => $callback, 
    'weight' => $weight, 'hidden' => $hidden, 'access' => $access
  );
}

Mijn vraag is: waar wordt in een professionele omgeving dan voor gekozen? Toch maar lange regels laten (en evt. niet netjes kunnen printen) of altijd afbreken op 90 karakters?

[ Voor 14% gewijzigd door Reveller op 05-04-2006 08:47 ]

[BertS]

Beide heeft z'n nadelen. De vraag is echter wat je als het meest hinderlijk ervaart. Ik lees code meestal op het scherm (is denk ik langer dan een jaar geleden dat ik het geprint heb), dus de nadelen bij het printen vind ik irrelevant.
Als je dan toch een keer wilt printen (btw, waarom zou je dat doen? Ik zie het nut nooit zo van het printen van code), kun je het altijd nog landscape doen (of evt op A3).

[prototype]

Mag ik vragen waarom je je strings 'hardcode', terwijl je wel een notie hebt van constanten (MENU_SHOW) ? Wat nou als je straks een andere taal wil ondersteunen, dat zijn nou dingen die in een CMS er toe doen dunkt me In de huidige opzet zou je nu de teksten moeten veranderen binnen je logics, beetje onwenselijke situatie dunkt me, daar je al gauw wat gebroken hebt
Wat betreft je lange statements, die vertonen vrij veel commonality in de $path, i.e. "admin/user/" komt in elke regel voor die je nu gepaste hebt. Misschien dat je deze kan opvangen in een variabele, met een kleine identifier naam, een temp var dus, en die dan kan concatten. Dat scheelt je alweer wat colspace als je er toch zo op gefixeerd bent
Dan nog wat je in je menu methode uitvoert. Is het misschien niet een idee om de twee dimensionale array te 'unrollen'? i.e.

PHP:

    $menu[$path]['title'] = $title;
    $menu[$path]['callback'] = $callback;
    //etc...

Overigens wil je overwegen om "global menu" niet te doen, daar het 'onderwater' activiteit vertoond, krijg je misschien nog last van met debuggen; het volgt niet echt de normale flow.