variabler tilgængelig udenfor definerende scope

Det er et spørgsmål om præference.

Begge muligheder virker jo. Personligt ville jeg nok assigne en værdi ud fra en funktion i stedet:

function doLogic(): string|null {
    foreach(...) {
      if(something()) {
        return 'string';
      }
   }
   return null;
}

if($foo = doLogic()) {
    ...
}

Men igen, det er en præference.

For læselighedens skyld vil jeg foretrække den første udgave: "Her er en variabel, og måske får den en anden værdi."

Startværdien kan være den tomme streng, 0 eller -1 eller false  -  hvis det giver mening.  $fundet=false;  $pos=-1;  $navn="Ukendt";

Hvis man ikke har en god startværdi, så skal man lige vide at man kan kan give en variabel en ikke-værdi: null.

    $a = null;

Så vil isset($a) sige false, og så svarer det sådan set til din anden udgave, men med angivelse af at der er en variabel, som måske ændrer værdi.

Jeg vil splitte diskussionen op i 2.

Initialisering før foreach eller ej.

$z = ...;
foreach(...) {
  if(...) {
      $z = ...;
  }
}
// use $z

vs:

foreach(...) {
  if(...) {
      $z = ...;
  }
}
// use $z

Jeg foretrækker den første.

Af 2 grunde:

1) At $z ikke er sat er et potentielt problem - PHP har isset
  men programmører laver fejl - variablet som måske er sat og som
  måske ikke er sat er ikke god kode.

2) Ligheden med sprog som kræver type erklæring.

String z = ...;
foreach(...) {
  if(...) {
      z = ...;
  }
}
// use z

virker.

foreach(...) {
  if(...) {
      String z = ...;
  }
}
// use z

virker ikke.

Generelt mener jeg at det er bedre at skrive kode som kan forståes af de fleste
programmører fremfor kode som kræver en lidt dybere forståelse for det anvendte
sprog. Der er naturligvis masse af situationer hvor det ikke er muligt, men hvis
det er muligt så er det min præferance.

Værdi for initialisering.

Hvis man vil initialisere så er der spørgsmålet om hvilken værdi man skal bruge.

null vs '' vs 'Some magic value' vs false.

Jeg kan ikke lide false (medmindre variablen inden i foreach og if altid bliver sat
til true/false). Variable som enten indeholder en boolean eller en string er
noget rod.

Så null eller '' eller 'Some magic value'.

Hvilken der er bedst må afhænge af konteksten.

Er der udfra domæne viden en værdi som faktisk giver mening som default værdi.

Kan variablen inden i foreach+if blive sat til samme værdi og vil det være et problem
at man ikke kan skelne mellem oprindelig initilaisering og en senere sat værdi.

Hvordan forholder den efterfølgende kode sig til null. Vil det give fejl eller
forventer koden faktisk null for ingen værdi.

O.s.v..

#1:
Fint med funktion - med dens navn kan man udtrykke noget mere meningsfuldt en i et udtryk.
Mine præferencer er dog skammeligt til det komprimere - elsker php for dets 'frække' måde at kunne udtrykke sig kortfattet grundet de implicitte konverteringer. En funktion kommer her til rette hvis konseptet opræder flere gange. Nu var mit spørsmål også lidt kontekstløst, så her kommer sammenhængen:

html body elementet ligger i fil - dens extension kan være php eller md (grundet editoren syntax higligtning) array $pe er url'ens path elements

Det kan laves i en klasses dertil, $pe[2] benævnte methods - men dette, i base klassens liggende , nogle steder udskammede magi, er default, idet methods i en nedarvet klasse er tiltænkt speciel tilfælde:

function __call($notUsed,$notPermitted) {
    global $pe;
    if (count($notPermitted))
        throw new \Exception("PageAware:73:parmameters to __call not allowed here");
    $barePath = __DIR__.strtolower("/$pe[1]/$pe[0]/$pe[2]");
    foreach ([".md",".php"] as $ext)
        if (file_exists($barePath.$ext)) {
            $incPath = $barePath.$ext;
            break;
        }   
    if (isset($incPath)) {
        $mdSrcArr = [];
        $mdSrc = include($incPath);
        if (is_array($mdSrc))
            $mdSrcArr=$mdSrc;
        else
            $mdSrcArr[]=$mdSrc;
        if (substr($mdSrcArr[0],0,1) == "<") { // first item can be content or html template
            $this->body = $mdSrcArr[0];
            array_shift($mdSrcArr);
        } else
            $this->body = str_repeat(' #md# ',count($mdSrcArr)); // template for insertions
       
        foreach($mdSrcArr as $mdSrcI) {
            $this->body = preg_replace('/#md#/',(new Parsedown())->text($mdSrcI),$this->body,1) ;
        }
        $this->stdPage();
    } else 
        redirDefault();
}

#2:
Ja - jeg kan godt se at det er tydeligere med variabel definering uden for scopet - sådan skriver jeg også på en god hvor jeg forfalder til være for kondenseret tiltrukket.

#3: Ja, da det jo hverken Lisp eller R som programmører i almindelighed excelerer i, er
  varname = ekspression
tydeligt - også ud over at kunne php's implicitte konverteringer på fingrene.

Der er jo forskel på kontekst for kode. Og forskellig kontekst kan godt begrunde forskellige tilgange til koden.

Der er kode som kun skal bruges ved en lejlighed. Der er kode som har en forventet levetid på under et år. Og så skriver man noget kode som løser opgaven nemmest muligt og det er det. Er der en fejl så fikser man den selv.

Der er kode som kan forventes brugt 10-20-30-40 år. Og hvor den oprindelige udvikling er måske kun 10% af total livs cyklus omkostning (90% er vedligehold). Så kan det godt betale sig at skrive koden sådan at den er nem at forstå for hvem som helst, fordi der kommer sandsynligvis mange forskellige vedligeholdelses programmører som skal forstå koden.

Der er en gammel vits omkring det:



Folk bliver præget af hvilken type kode de arbejder med. Jeg er meget i den anden kategori. Jeg har en masse kode som jeg skrev i 2001 som stadig er i produktion.

Jeg er glad for at du udspænder forskellen mellem den kommecielt levetids betingende læsbare kodestil og så minimalist dyrkende.
Men hvad er så også levetiden for det der skrives i PHP og paradigmerne der er gængse i givne versioner eller frameworks?
Det er interessant problematik - tak for det.

Jeg er ikke specielt godt kendt med PHP verdenen.

Men jag kan observere at:
* PHP fra version til version strammer checkene notice -> warning -> fatal
* mange PHP frameworks laver inkompatible API ændringer når major version ændres

Min konklusion er at den typiske PHP applikation enten erstattes eller opdateres i løbet af nogle få år. Ellers ville man ikke kunne gøre disse ting.

Og der er vel også en generel tendens til at kode relateret til brugerinterface opdateres hyppigere end ren backend logik.

Af flere årsager:
* i mange sammenhænge forventer man at brugerne ser positivt på et UI facelift
* hvis der er en uhensigtsmæssighed i backend så man må lave 2 API kald i.s.f. 1 API kald så betyder det formentligt ikke noget, mens hvis der er en uhensigtsmæssighed i brugerinterface så brugerne må indtaste 2 forme i.s.f. 1 form så er det et problem