Concatten
Deze manier zou de beste zijn vanwege het gebruik van enkele quotes wat sneller zou zijn dan het gebruik van dubbele quotes.
Tegenwoordig als ik SQL-queries opstel, gebruik ik echter vrijwel altijd dubbele quotes.
En dat kun je natuurlijk ook doen als het niet om SQL gaat.
En dan is er ook nog het gebruik van accolades voor 'ingewikkeldere' variabelen.
Mijn vraag is ... welke methode gebruiken jullie het meest?
Als ik eerlijk ben, dan leest dit
... een stuk makkelijker dan dit:
Maar hoe zit het met performance e.d.?
Gewijzigd op 12/02/2019 15:09:58 door Ozzie PHP
Als ik mag kiezen tussen 'performance' en 'leesbaarheid', kies ik altijd voor leesbaarheid. Performance van code als geheel zou niet mogen afhangen van het type quotes dat je gebruikt, tenzij er een bug in PHP zit. In mijn optiek mooie ontwikkeling in JS is de zgn template literal in combinatie met de back-tick: `Hallo ${firstname} ${lastname}!`. Niet meer dat gehaspel met de +.
wat gebruik jij dan zelf?
Gewijzigd op 12/02/2019 15:48:50 door Nick Vledder
Code (php)
1
2
3
2
3
$firstname=$oNaw->readNaam();
$lastname=$_SESSION['aRecord']['naam'];
print "<br/>Hallo <b>$firstname</b> <i>$lastname!</i>";
$lastname=$_SESSION['aRecord']['naam'];
print "<br/>Hallo <b>$firstname</b> <i>$lastname!</i>";
Dankzij 'leesbaarheid' krijg ik een betere 'perfomance' van ontwikkeling... :-)
Anders zou het dit worden:
Code (php)
1
echo "<br/>Hallo <b>" . $oNaw->readNaam() . "</b><i> " . $_SESSION['aRecord']['naam'] . "</i>";
En zie dat maar eens in één keer zonder triviale foutjes te schrijven.
Vaker gebruik ik echter :
Code (php)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
writeln('Temp is',$celsius,'graden');
function writeln() {
$aArgs = func_get_args();
foreach ($aArgs as $arg) {
print "$arg ";
}
print "<br/>";
}
function writeln() {
$aArgs = func_get_args();
foreach ($aArgs as $arg) {
print "$arg ";
}
print "<br/>";
}
Gewijzigd op 12/02/2019 16:33:02 door Paul Ulje
Ozzie PHP op 12/02/2019 15:07:35:
Los van waar je vraag over gaat, zou ik in dit geval opteren voor
en dan prepare() en bind() gebruiken om je code wat veiliger te houden.
Performacewinst pak je ergens anders.
Tijdswinst heb je direct omdat je makkelijk kunt lezen wat je zojuist hebt geprogrammeerd.
NB: als het over grotere lappen tekst gaat die een combinatie van PHP(-variabelen) en tekst gaat kan output buffering uitkomst bieden. Je doet dan alsof je alles direct weergeeft maar vangt alle output netjes op in een buffer. Dat is wat mij betreft nog steeds de meest "clutter free" aanpak.
Gewijzigd op 12/02/2019 17:00:39 door Thomas van den Heuvel
>> en dan prepare() en bind() gebruiken om je code wat veiliger te houden.
Volgens mij werkt dat niet met MySQLi.
@Thomas
>> Enkele quotes als het kan, dubbele quotes als het moet.
Oké ... maar ... WAAROM???
Strings met dubbele quotes kun je makkelijk combineren met enkele quotes wanneer je deze nodig hebt, bijboorbeeld als je queries bouwt waarin kolomwaarde worden gebruikt. Dit zodat je dan niet helemaal gierend gek wordt van het escapen van enkele of dubbele quotes, wat tevens de boel compleet onleesbaar maakt.
En omdat je dan met een simpele vuistregel werkt volgens een stramien die je impliciet dwingt tot een eenduidige werkhouding waarbij code leesbaar blijft.
En omdat je dan op zijn minst te werk gaat volgens een plan, en dat is nog altijd beter dan geen plan.
Heb je een andere/betere manier die voor jou werkt: go right ahead.
Gewijzigd op 12/02/2019 18:12:38 door Thomas van den Heuvel
Bij blokken met HTML beëindig ik vaak de PHP-tags en gebruik netjes tussendoor, als ik iets in PHP moet echo'en. In geen enkel geval bouw ik een echo-put met op elke regel en echo. Dat vind ik zo onnodig en onlogisch. het komt over alsof je tijdens een gesprek steeds na je zin een stilte laat vallen en weer verder praat :-P
Oké ... nu volg ik je even niet meer. Jij geeft als stelregel dat je enkele quotes moet gebruiken ... en vervolgens kom je met diverse redenen die het nut daarvan ontkrachten.
Wat raad jij nu aan, want ik zie geloof ik iets over het hoofd of ik begrijp je verkeerd.
@Ariën
>> Ikzelf gebruik vaak de eerste code van Ozzie. Puur omdat het leesbaar is, en de syntax van de string en de variabelen/functies gescheiden zijn.
Dat doe ik dus ook, maar strikt genomen zijn de dubbele quotes eigenlijk duidelijker (mits er niks geëscapet hoeft te worden).
Dit:
lijkt me duidelijker dan dit:
Dus waarom kies je dan toch voor dit laatste? Zelf doe ik dat dus ook, maar is het nog wel handig vraag ik me af.
Alleen het concatneren geeft een beetje een syntax-rotzooitje, maar daar kijk ik gewoon overheen.
Lol :D
Maar weet je ook WAAROM dat zo is? Waarom ze buiten quotes moeten? Kan me er wel iets bij voorstellen, maar in queries zet vrijwel iedereen ze binnen dubbele quotes. Dus het gaat mij vooral om het waarom.
Nee ik leg uit wanneer je wat zou moeten gebruiken, en waarom.
> Wat raad jij nu aan, want ik zie geloof ik iets over het hoofd of ik begrijp je verkeerd.
Enkele quotes als het kan, dubbele quotes als het moet.
En bij erg lange tekst: output buffering.
Ik herinner mij dat artikel van PHPFz nog. Het "bewijsmateriaal" stond jammergenoeg in dienst van de hypothese (dat dingen buiten quotes halen sneller zou zijn). Ze hadden dan misschien wel gelijk, maar niet om de juiste redenen.
Of PHP nog steeds op dezelfde manier werkt, is natuurlijk om te beginnen al de vraag.
Test ging toen om verschillen bij.
Code (php)
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
<?php
$bar = "bar";
$foo = "foo bar";
$foo = 'foo bar';
$foo = "foo $bar";
$foo = 'foo '. $bar;
$foo = "foo " .$bar;
?>
$bar = "bar";
$foo = "foo bar";
$foo = 'foo bar';
$foo = "foo $bar";
$foo = 'foo '. $bar;
$foo = "foo " .$bar;
?>
resultaat wat ik me meen te herinneren:
De eerste 2 waren vergelijkbaar.
Staat er zoals in geval 3 een variabele tussen de " " dan wordt het "trager"
en de optimaalste waren de laatste 2.
Maar ik zet Trager tussen " ", omdat het verschil erg klein was. (toen al)
Ten tweede is ook de vraag hoe betrouwbaar de meetmethode was.
En tenslotte: de methode waarbij de variabelen buiten de quotes staan, geven
a) in mijn editor beter onderscheid in kleuren om de vars te vinden
b) gemakkelijk de mogelijkheid om ipv $bar iets als htmlspecialchars($bar) of escape($bar) toe te passen
Vooral dat geeft voor mij de doorslag om ze buiten de quotes te laten.
Toevoeging op 13/02/2019 10:23:19:
ik heb de link terug gevonden, al geeft het nu een 404 error:
http://www.scriptorama.nl/internals/quotes-battle
en dat googlen leidde weer naar phphulp:
zie ook https://www.phphulp.nl/php/forum/topic/single-of-double-quotes/16000/1/
Damn ... da's een oude post ... nog van voor mijn tijd :-D
Beiden bedankt voor jullie uitleg. We blijven dus gewoon voor single quotes gaan waar mogelijk, en wanneer het handiger is voor dubbele quotes.
Nog een laatste vraagje.
Queries zet ik dus tussen dubbele quotes omdat dat makkelijk te combineren is met enkele quotes, maar wat nu als er geen enkele quotes in een query voorkomen? Zet je die query dan weer tussen enkele quotes? Of zetten jullie een query gewoon altijd standaard tussen dubbele quotes?
Ozzie PHP op 13/02/2019 10:31:55:
Queries zet ik dus tussen dubbele quotes omdat dat makkelijk te combineren is met enkele quotes, maar wat nu als er geen enkele quotes in een query voorkomen? Zet je die query dan weer tussen enkele quotes? Of zetten jullie een query gewoon altijd standaard tussen dubbele quotes?
Om daarna alles toch weer te moeten veranderen als je tóch nog een ' in de query nodig hebt.
Zelf hanteer ik inderdaad query tussen " "
en html tussen ' '
Maar daarbij wel altijd prepared statements als het om variabelen gaat.
en html tussen ' '
Oké helder!
>> Maar daarbij wel altijd prepared statements als het om variabelen gaat.
Ah oké, maar dat gaat bij MySQLi niet.
http://php.net/manual/en/mysqli-stmt.prepare.php
http://php.net/manual/en/mysqli-stmt.bind-param.php
Maar wat is eigenlijk het wezenlijke verschil tussen
SELECT foo FROM bar where id = $id
versus
SELECT foo FROM bar where id = ?
Wat ga ik er met die laatste variant op vooruit?
Maar stel dan het een keer toch een string is, en zeker als het invoer van buiten is, zou dat ook zo maar met opzet kunnen.
script.php?id=123%20OR%201
Dan is $id gelijk aan "123 OR 1"
dus de query wordt: "SELECT foo FROM bar where id = 123 OR 1"
En de vraag is, of dat is wat je wilt, en wat er gebeurt als iemand in plaats daarvan een subquery uitvoert die engere dingen doet.
SQL injectie dus.
En nu kún je wel proberen om $id vooraf te escapen, maar dat kan ook zo maar een keer vergeten worden. En dan missen ook nog de ' ' om $id.
prepared statements voorkomen dat.
En maken het eventueel ook mogelijk een 1x gepreparede query een keer of 100 uit te voeren met steeds andere parameters.
Bijvoorbeeld 1x prepare en vervolgens 1000 meetresultaten ergens uitlezen en wegschrijven. zou ook efficienter zijn. Komt niet veel voor bij standaard websites, maar PHP is niet tot websites beperkt.