verschil tussen if ($x == $y) {...} else {...} en <?php if ($x == $y) : ?> ... <?php else : ?> ...
Misschien heel basaal. Ik ben met joomla bezig. Deze if instructie ken ik:
Nu kom ik 'opeens' dit in de default view tegen:
'HTML code'
'HTML code'
Wat is nu het verschil met : en {?
En waarom pas je dit toe?
Het is volgens mij geen ternary constructie oid.
Nico.
alternatieve notatie voor control flow in PHP. Wordt vaak toegepast in templates, omdat het lekkerder leest.
Dat is Gewijzigd op 07/01/2018 21:26:26 door Jan Koehoorn
Jan Koehoorn op 07/01/2018 21:24:44:
omdat het lekkerder leest
Objection!!!
:p
Hierover verschillen de meningen. Functioneel doen beide constructies hetzelfde.
Gewijzigd op 08/01/2018 00:18:33 door Thomas van den Heuvel
Thomas van den Heuvel op 08/01/2018 00:17:39:
Hierover verschillen de meningen. Functioneel doen beide constructies hetzelfde.
Meningen verschillen altijd. En ik heb niet beweerd dat ze functioneel verschillen. Ik vind code waarin je niet kunt zien waar een sluit-accolade voor is heel erg ondoorzichtig. Dan zie ik (nogmaals in een template) liever dit:
Dan dit:
Ik ben het helemaal met Jan eens. Enkel zo een accolade sluiten tussen je HTML is geen pan.
Mja, maar da's toch een beetje een voorbeeld zoeken van een manier die niemand handig vindt. Daarmee kun je niet opeens een notatiewijze afschrijven imo. Een verkeerd gebruik van wat dan ook is nooit handig :p.
Er is in mijn opzicht geen sprake van verkeerd gebruik. Het gaat slechts om twee verschillende methoden. Ik zou in mijn applicatie zelf gewoon de accolades gebruiken. Deze staan dan ook niet tussen blokken HTML. Maar in templates zoals Jan zegt is de andere variant beter leesbaar, temeer omdat je in plaats van de accolade sluiten letterlijk uit de notatie kunt opmaken of je een foreach of een if/else afsluit. Dit is in een flinke template toch wel degelijk een behoorlijk voordeel ten opzichte van de accolade.
Ik heb persoonlijk liever accolade´s en wat ik overigens altijd doe is dit:
Code (php)
Of het nu PHP, Java, javascript... altijd doe ik dit. Natuurlijk wijzigt het if statement wel eens en moet ik het comment bij de sluit accolade aanpassen, maar ik weet dan meteen dat het om if of foreach of..., gaat waar mijn bepaalde flow op houd.
Nogmaals bedankt.
Nico
De schrijfwijze met de accolades is inderdaad ver weg de meest gebruikte schrijfwijze dus je maakt denk ik de juiste keuze voor nu. Commentaar plaatsen is ook prima maar eigenlijk zou dit niet nodig moeten zijn bij een accolade sluiten als je je code logisch onderverdeeld in functies (of classes). Hierbij krijgt iedere functie zijn eigen kleine stukje verantwoording binnen je applicatie en daarin zul je niet al te veel (geneste) loops of conditions aantreffen. Met andere woorden: Je code is dan goed leesbaar zonder die commentaar regels aan het einde van een loop of condtion.
Frank Nietbelangrijk op 09/01/2018 08:59:54:
Maar in templates zoals Jan zegt is de andere variant beter leesbaar, temeer omdat je in plaats van de accolade sluiten letterlijk uit de notatie kunt opmaken of je een foreach of een if/else afsluit. Dit is in een flinke template toch wel degelijk een behoorlijk voordeel ten opzichte van de accolade.
Dit lijkt mij alleen een probleem als er niet fatsoenlijk wordt ingesprongen? Je kunt je code hierin best leidend laten zijn, en de inspring overnemen in HTML. Niemand zal wakker liggen van extra spaties/tabs, die door compressie (en de beschikbare bandbreedte, we leven niet meer in het modem tijdperk) toch grotendeels wordt platgeslagen.
Zolang je zelf maar een onderbouwde reden hebt waarom je voor een aanpak kiest maakt het mij niet uit wat iemand doet.
Iets in de trant van "zelfs als de code brak is kan ik het op deze manier nog steeds lezen" lijkt mij echter niet echt een fantastisch uitgangspunt. Dan is er toch echt meer aan de hand.
@Nico, commentaar zetten bij een sluitingshaak bij wat uitgebreidere nesting (meerdere niveau's) kan het lezen van code inderdaad eenvoudiger maken. Maar in principe zou fatsoenlijk geneste code redelijk voor zich moeten spreken.