Dat zijn echt de grootste K-klussen die d'r zijn: een probleem opsporen in een website waarbij de originele programmeur dacht "O, het is slechts een notice". Een notice is ook een melding dat er iets "niet helemaal goed gaat" (niet conform de verwachting), en dus gewoon een fout (maar dan net iets minder - we noemen het een slordigheid). Zelf zet ik altijd error_reporting(E_ALL) en dan een set_error_handler(...) die alles gewoon naar een Exception gooit. Dan is het tenminste duidelijk dat er *iets fout gaat* (anders hobbelt PHP veels te lang door, met allemaal halve waarheden; mi het grootste nadeel van PHP)
O ja, het @-teken, nog zo'n "geweldige uitvinding". Dat wordt zo wijdverbreid misbruikt dat ik moet bekennen dat mijn errorHandler niet in alle gevallen een Exception gooit (anders kan ik dat hele Composer maar meteen links laten liggen):
public function errorHandler($error_no,$message,$filename,$line_no,$context = null){
if(error_reporting()) throw new \ErrorException($message,$error_no,0,$filename,$line_no);
elseif($this->_initialized) $this->log->info($message,$filename,$line_no);
}
Dus een Exception als de error ook gereport mocht worden (dus niet onderdrukt met @), en anders (wel onderdrukt) een info melding in het log (dan is het in ieder geval geen show-stopper, maar wordt je er wel op geattendeerd).
Gebruik nooooooooooooooit and, behalve wellicht in SQL, en dan liefst in HOOFDLETTERS. Beter is om in PHP && te gebruiken. Dit vanwege de precedence van operatoren, er gebeuren anders misschien hele vervelende dingen. Dit wordt op een gegeven moment gewoon een grote clusterf*ck, al helemaal als je && en and door elkaar gebruikt.
Overigens is het gebruik van @ wel in sommige gevallen zinnig, namelijk als je wéét dat er dingen fout kunnen gaan, maar niet de notice/error wilt, maar tevens dat je dan vervolgens hier op acteert door middel van een (directe of indirecte) foutafhandeling. Dit moet je niet verwarren met @ als het onder-het-tapijt-veeg-symbool want daar is het dus overduidelijk niet voor bedoeld, tenzij je misschien een struisvogel bent en/of je je opvolger op voorhand haat en een miserabel leven toewenst.
Overigens gaat de constructie A && B hierboven dan goed omdat PHP zich bedient van lazy evaluation. Dit houdt in dat als je de constructie A && B hebt, en A is false, dan kan dit nooit iets opleveren wat true is (false && whatever is altijd false), en om die reden zal 'ie dus ook niet struikelen over $_GET['actie'] == 'status' (ondanks het feit dat $_GET['actie'] niet bestaat, maar daar heb je dus in het eerste deel al een controle op uitgevoerd). De inspectie van B wordt in dat geval overgeslagen. "Oh A is false, ok we zijn klaar."
[color=#00aa00](Dus nu is ook de reden waarom de isset()-constructie werkt duidelijk en bekend)[/color]
Op eenzelfde (lazy) wijze wordt bij A || B nooit B gecontroleerd als A true is, immers true || whatever is altijd true.
EDIT: en zoals wordt aangehaald in de reacties van het gelinkte topic: als er mogelijk verwarring is over wat bij elkaar hoort, gebruik dan ( haken om dingen te groeperen ).
Het is een keuze. Op het moment dat je met meerdere mensen code ontwikkelt zul je hier sowieso afspraken over moeten maken.
Ik ben van mening dat je bij logische operatoren beter af bent met symbolen dan de geschreven teksten and en or, omdat er in dat geval sneller verwarring kan ontstaan met andere zaken (denk bijvoorbeeld aan namen van constanten en variabelen). En ook is dan de binding met andere operatoren anders. Haakjes helpen natuurlijk altijd. Maar die zou je dan met and en or ook in de meest triviale gevallen moeten gaan gebruiken. Dat zou niet mijn voorkeur hebben.
Zolang je maar ergens argumenten voor hebt en je hier zelf vrede mee hebt (en je anderen die met jouw code moeten werken ook kunt overtuigen wellicht) maakt het mij niet zoveel uit wat je gebruikt, maar ik vind "heb er nog nooit enig probleem mee gehad" niet zo'n sterke :p. Is zoiets als "heb nog nooit mijn autogordels omgehad en heb nog nooit een ongeluk gehad".
Heb je het voorbeeld gezien in de SO-post waar het in een triviaal geval al "mis" gaat? Of er in ieder geval iets onlogisch gebeurt? Dat zou mij niet motiveren om and en or te verkiezen boven && en ||.
Ik moet er niet aan denken dat ik een lap code zou moeten debuggen en dat er dan na een half uur zoiets uitrolt, ik zou dat probleem op voorhand uit de weg gaan door die constructie in eerste instantie niet te gebruiken.
