verschil tussen if ($x == $y) {...} else {...} en <?php if ($x == $y) : ?> ... <?php else : ?> ...

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Nkamp Kamp van de

nkamp Kamp van de

07/01/2018 20:54:13
Quote Anchor link
Hallo,

Misschien heel basaal. Ik ben met joomla bezig. Deze if instructie ken ik:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
<?php
if ($x == $y) {
    ...
}
else {
    ...
}

?>


Nu kom ik 'opeens' dit in de default view tegen:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
<?php if ($x == $y) : ?>

'HTML code'
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
<?php else : ?>

'HTML code'
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
<?php endif; ?>


Wat is nu het verschil met : en {?
En waarom pas je dit toe?

Het is volgens mij geen ternary constructie oid.

Nico.
 
PHP hulp

PHP hulp

24/04/2024 01:02:54
 
Jan Koehoorn

Jan Koehoorn

07/01/2018 21:24:44
Quote Anchor link
Dat is alternatieve notatie voor control flow in PHP. Wordt vaak toegepast in templates, omdat het lekkerder leest.
Gewijzigd op 07/01/2018 21:26:26 door Jan Koehoorn
 
Thomas van den Heuvel

Thomas van den Heuvel

08/01/2018 00:17:39
Quote Anchor link
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
 
Jan Koehoorn

Jan Koehoorn

08/01/2018 06:04:56
Quote Anchor link
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:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
<?php endforeach; ?>


Dan dit:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
<?php } ?>
 
Frank Nietbelangrijk

Frank Nietbelangrijk

08/01/2018 22:51:25
Quote Anchor link
Ik ben het helemaal met Jan eens. Enkel zo een accolade sluiten tussen je HTML is geen pan.
 
Thomas van den Heuvel

Thomas van den Heuvel

08/01/2018 23:52:53
Quote Anchor link
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.
 
Frank Nietbelangrijk

Frank Nietbelangrijk

09/01/2018 08:59:54
Quote Anchor link
@Thomas,

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.
 
Nkamp Kamp van de

nkamp Kamp van de

09/01/2018 21:38:43
Quote Anchor link
Ok, bedankt voor jullie reactie. Het is mij in ieder geval duidelijk dat het functioneel hetzelfde doet, dat is voor mij nu het belangrijkste.

Ik heb persoonlijk liever accolade´s en wat ik overigens altijd doe is dit:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
<?php
if ( $x == $y) {
...
}
//END if ( $x == $y) {


if ( $x == $y) {
...
}
else {
...
}
//END if ( $x == $y) {...} else {...}
?>


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
 
Frank Nietbelangrijk

Frank Nietbelangrijk

09/01/2018 22:31:49
Quote Anchor link
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.
 
Thomas van den Heuvel

Thomas van den Heuvel

10/01/2018 00:09:50
Quote Anchor link
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.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.