Simpel $var check
Normale check bijvoorbeeld
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<?php
If (isset($var)) {
$newValue = $var;
} else {
$newValue = 'some_value';
}
//normale if short notatie is dan
$newValue =(isset($var))?$var:'some_value';
//Een andere check die men zelden ziet is de OR check
isset($var)|| $var = 'some_value';
// als var leeg is krijgt het 'some_value'
$newValue = $var;
?>
If (isset($var)) {
$newValue = $var;
} else {
$newValue = 'some_value';
}
//normale if short notatie is dan
$newValue =(isset($var))?$var:'some_value';
//Een andere check die men zelden ziet is de OR check
isset($var)|| $var = 'some_value';
// als var leeg is krijgt het 'some_value'
$newValue = $var;
?>
Moeilijk is het niet en het geeft een goed leesbare vergelijking
Gewijzigd op 14/02/2015 17:53:48 door Cees S
Na de extra haken zou dit $newValue = ((isset($var)) || 'some_value'); ook moeten werken
Nee, ook niet.
Zit je met "zou moeten werken" maar wat te raden of ben je aan het trollen?
@Cees S: wellicht voortaan eerst even testen voordat je dit soort constructies plaatst ;)
Het blijft volgens mij wel een hele mooie vergelijking
werkend in gebruik is
Code (php)
Toevoeging op 14/02/2015 18:02:57:
Kan iemand mij uitleggen waarom dit wel werkt
Code (php)
en navolgend een boolean geeft en helaas niet werkt
Code (php)
Op zich ben ik al heel blij met de deze mogelijkheid
isset($config['width']) || $config['width'] = 120;
Ik kan niet direct overzien wat er in zo'n "OR" statement gebeurt, en wat gebeurt er als een assignment "false" oplevert?
Als ik dit soort code zie zou mijn eerste ingeving zijn om weg te sturen van zo'n opzet, en de desbetreffende programmeur vragen stellen over zijn beweegredenen voor het schrijven van onleesbare code.
korter !== beter
Even vertalen naar simpel Nederlands:
Code (php)
1
2
3
4
2
3
4
$config['width'] = 150; $config breedte = 150.
Als $config breedte geset is, (Dat is ie al, want hij heeft een waarde van 150)
OF $config with heeft een waarde van 120
Laat $config with zien.
Als $config breedte geset is, (Dat is ie al, want hij heeft een waarde van 150)
OF $config with heeft een waarde van 120
Laat $config with zien.
Hier gaat iets mank. Want waarom wil je in hemelsnaam iets wat al een vaste waarde heeft een controle of hij daadwerkelijk wel bestaat. Dat is niet logisch.
Dan ga je nog een stapje verder:
Je maakt een nieuwe variabele aan die je eerst controleert of hij bestaat, OF een waarde heeft van 120.
Dan is het eigenlijk wel logisch dat de variabele de eerste controle doet, de tweede controle is niet meer van belang. Dus de variabele word een boolean.
Maar wat wil je bereiken?
Want ik heb het idee dat je iets aan het zoeken bent wat veeeeeeel makkelijker kan.
Gewijzigd op 14/02/2015 19:03:21 door Bart V B
Hierin geeft isset() true of false.
Indien true dan hoeft de rest achter de OR niet meer te worden uitgevoerd en blijft $config['width'] ongewijzigd..
Indien false dan wordt de rest wel uitgevoerd. $config['width'] krijgt een (nieuwe) waarde. En een gelukte toekenning geeft true.
Idem als hierboven.
Echter het resultaat, dus of true of false, dat stop je in $var.
$whatever = false; (dit statement)
is equivalent met
false
Hoe moet ik de toekenning van een ongeinitialiseerde variabele met een waarde die "equivalent" is met false interpreteren in dit geval?
false || false
lolwut?
Het probleem is dat niet direcht duidelijk is wat de bedoeling van de programmeur is. Dan moet je nadenken over:
- wat de bedoeling (waarschijnlijk) was en
- of dit ook daadwerkelijk gebeurt (variabelen na afloop altijd een correcte waarde hebben)
Dit lijkt mij ook geen handige aanpak indien er hier of elders bugs in je scripts zitten. Het resultaat van debugging hiervan zal waarschijnlijk (en hopelijk) resulteren in het weg-refactoren van dit soort constructies.
EDIT: de crux van dit alles is waarschijnlijk dat je lazy evaluation op een verkeerde manier gebruikt (misbruikt).
Gewijzigd op 14/02/2015 19:38:17 door Thomas van den Heuvel
Code (php)
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
<?php
// geeft true
$var = (true || n.v.t.);
$var = (false || true);
//geeft false
$var = (false || false);
?>
// geeft true
$var = (true || n.v.t.);
$var = (false || true);
//geeft false
$var = (false || false);
?>
De waarde kan niet worden toegekend worden aan een variabele, omdat het een vergelijking op basis van waar of niet waar is.
Isset() geeft een boolean als result en niet de werkelijke waarde.
De fout ontdekte ik pas later omdat Isset() een 1 als result geeft en mijn routine een integer verwachte.
Het is m.i. wel een rare constructie maar met een heel handig gebruik.
Zoals al bleek gebruik ik het met config variabelen.
In mijn normale sources check ik altijd de variabele waardes voordat ik ze gebruik, met het resultaat een hoop if else etc.
Door deze voorwaarde
Weet ik zeker dat $var een waarde had, of krijgt ('default').
Wat betekend dat geen van de verdere routines undefined problemen van de $var zal ondervinden.
Ik hoop dat het hiermede duidelijk is waarom het echt een handige toepassing is.
Nu kan ik in 1 vergelijking testen of iets een waarde heeft en zo niet een default toekennen.
Gewijzigd op 14/02/2015 20:55:27 door Cees S
Als je probleem is dat $var undefinded is, dan kan je hem toch bovenaan setten?
Dan heb je helemaal geen isset nodig... Maar is wel duidelijker wat er bedoeld word.
Het kan natuurlijk altijd zo:
if(trim($var) == '')
{
$var = 'default';
}
maar de short wijze is bij veel controleren overzichtelijker
isset($var)|| $var = 'some_value';
hoewel ik ook het zo deed;
if(trim($var) == '') $var = 'default';
daar geven een aantal editors een warning op en die verwachten minimaal
if((isset($var))&&(trim($var) === '')) {$var = 'default';}
Daarnaast kan ik er ook bijvoorbeeld een min. waarde mee controleren en/of toekennen
(waarde < 100)||waarde = 100;
of max
(waarde >1000)||waarde = 1000
Gewijzigd op 14/02/2015 21:22:29 door Cees S
Op zich kan dat natuurlijk wel, maar de vraag is of het ook duidelijk is.
Je kunt het ook als volgt schrijven, waardoor het wél zeer duidelijk is.
Quote:
maar de short wijze is bij veel controleren overzichtelijker
isset($var)|| $var = 'some_value';
isset($var)|| $var = 'some_value';
Je kan met isset() meteen meerdere variabelen controleren.
Dus ik zie het totale nut niet van short wijze.
Het maakt de code alleen maar onoverzichtelijk wanneer je het precies niet wil.
Natuurlijk zijn er uitzonderingen wanneer je een view schrijft gemixt met html code.
Dan is het soms prettiger om het short te maken zodat het duidelijker is.
Bijvoorbeeld:
Code (php)
Let op! shorthand werken levert geen snelheid op.
Dus als je daarom dit zou willen dan moet je het zeker niet doen.
Quote:
daar geven een aantal editors een warning op en die verwachten minimaal
if((isset($var))&&(trim($var) === '')) {$var = 'default';}
if((isset($var))&&(trim($var) === '')) {$var = 'default';}
Um... Dus als ik het goed begrijp dan laat jij een editor beslissen wat goed en fout is?
Als het goed is, en je weet zeker dat met error_reporting er geen fout is, dan is het toch goed?
Mijn editor doet ook dingen die ik niet wens, maar als ik zeker weet dat het geen probleem oplevert en geen foutmeldingen van php geeft dan negeer ik deze. Per slot van rekening ik ben de baas over mijn code niet mijn editor. :)
EDIT
koek kruimel tussen de T dus kleine typo..
Gewijzigd op 14/02/2015 22:40:17 door Bart V B
Dit impliceert tevens dat $var mogelijk ergens anders geïnitialiseerd wordt. Moet iemand die jouw code bekijkt naar die variabele gaan zoeken? Initialiseer één variabele op één plek op de manier die Bart V B beschrijft (eerste fragment).
Bekijk het eens op de volgende manier: als jij iemand anders zijn code moet bekijken dan heb jij niet de "rode draad" die die persoon had tijdens de ontwikkeling ervan. Vaak komt het er op neer dat je de code redelijk aandachtig moet doornemen voordat je "de draad" kunt oppikken. Daarbij is er zeker iets voor te zeggen om onnodige complicaties uit de weg te gaan. Deze code "leest niet fijn", je moet in je gedachten deze enkele regel ontleden voordat je je een beeld kunt vormen wat deze inhoudt, daarna moet je deze interpreteren (bijvoorbeeld door dummy-waarden in te voeren en beredeneren wat hier dan uitkomt). Als een compleet programma in dit steno is opgezet, probeer dit dan maar eens te ontrafelen - te meer wanneer er bugs in zitten.
Als je "denkstappen" kunt elimineren bij het schrijven van code lijkt mij dit alleen maar voordelen hebben.
Door dit met if statements te doen wordt de gehele functie of class onnodig lang en daarvoor gebruik ik graag dergelijke short notaties.
Navolgende toepassing zullen jullie dan waarschijnlijk ook wel nooit toepassen ;)
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
<?php
if ($var = functie_call()) {
//use $var for something
}
//normale code zou zijn
$var = functie_call();
if ($var) {
}
//of misschien nog erger
$data['user']['ID'] = $user_id = $this->model->user->get_user($id);
// voor de leesbaarheid $user_id var gemaakt om in de verdere source te kunnen gebruiken.
$data['user']['adres'] = $this->model->address->get_address($user_id);
/* Natuurlijk kan het ook anders door aan het begin */
$user_id = $this->model->user->get_user($id);
/* en aan het eind of direct volgend */
$data['user']['ID'] = $user_id;
//het begin en eind kan een groot aantal regels uit elkaar liggen
?>
if ($var = functie_call()) {
//use $var for something
}
//normale code zou zijn
$var = functie_call();
if ($var) {
}
//of misschien nog erger
$data['user']['ID'] = $user_id = $this->model->user->get_user($id);
// voor de leesbaarheid $user_id var gemaakt om in de verdere source te kunnen gebruiken.
$data['user']['adres'] = $this->model->address->get_address($user_id);
/* Natuurlijk kan het ook anders door aan het begin */
$user_id = $this->model->user->get_user($id);
/* en aan het eind of direct volgend */
$data['user']['ID'] = $user_id;
//het begin en eind kan een groot aantal regels uit elkaar liggen
?>
En ja het gebeurt inderdaad regelmatig dat door debuggen een $var met name undefined $var moet worden gevonden. Door eigen fouten of door andermans fouten maakt dan niets uit.
Thomas heeft absoluut gelijk dat je onnodige complicaties uit de weg moet gaan.
Naar mijn idee doet een short notatie daar een positieve bijdrage aan en zeker als die undefined $var fouten elimineert.
Bij het gebruik van public sources is undefined een van de meest gemaakte fouten die bij ons problemen geeft.
Als je dan onderzoek wat de oorzaak is blijkt het veelal een scope probleem te zijn, die je niet op deze wijze oplost maar voor de rest van de applicatie niet op voorhand een error veroorzaakt.
En wat betreft die editor, ja die geef ik het voordeel van de twijfel. Eclipse, Netbeans, PhpED, etc. helpen door vroegtijdig codes te controleren, waarom zou ik daar bij syntax controles wel gebruik van maken en niet wanneer de editor misschien slechts goed gebruik aangeeft?
Je moet gewoon zorgen dat de variabelen die terug verwacht worden altijd bestaan. In sommige situaties kan het voorkomen dat een element in een array misschien soms wel en soms niet bestaat maar dat kun je ook in de view nog testen.
En nee, in een View een $var testen is bij ons NIET gewenst, daar MOET die (ook array's) inderdaad een waarde vanuit de controller hebben.
Quote:
Bij het gebruik van public sources is undefined een van de meest gemaakte fouten die bij ons problemen geeft.
??? Dat moet je dan toch daar oplossen - of het zou uit de specificatie moeten blijken wat je kunt terugverwachten en daar dan op anticiperen.
Dit is een haast klassieke fout, maar hangt ook weer af van de specificatie van functie_call(). Zo zou in deze definitie kunnen staan "returns false on error". Maar wat als nu de lege string, het cijfer 0, een leeg array of de waarde null geldige return-values zijn? Het if-statement wordt dan niet uitgevoerd.
Denk aan functies als readdir.
Een betere afhandeling zou zijn (maar dit hangt dus ook weer af van de specificatie):
Code (php)
Daarnaast, ik denk niet dat er één universele manier bestaat om iets te initialiseren, dit hangt ook van het gebruik af.
Maar ook:
Wellicht is null een toegestane waarde voor $var (al zou je voorzichtig moeten omgaan met null-waarden). Die wordt in het bovenstaande geval dan overschreven. Misschien is het beter om in plaats van isset() een specifieke controle op een waarde of een type te doen.
Laat ik het zo zeggen, ik begin de beweegredenen wel een beetje te zien, en het is korter dan:
Maar in dit geval schiet het zijn doel een beetje voorbij: je offert leesbaarheid op voor code-lengte, en in dit geval zou ik deze extra lengte voor lief nemen omdat het de interpretatie van wat er gebeurt makkelijker maakt en niet opweegt tegen de extra moeite die je moet doen om de kortere code te lezen.