54

Is there an advantage or disadvantage to concatenating variables within strings or using curly braces instead?

Concatenated:

$greeting = "Welcome, " . $name . "!";

Curly braces:

$greeting = "Welcome, {$name}!";

Personally, I've always concatenated my strings, because I use UEStudio, and it highlights PHP variables with a different color when concatenated. However, when the variable is not broken out, it does not. It just makes it easier for my eyes to find PHP variables in long strings, etc.

People are confusing this about being about SQL. This is not what this question is about. I've updated my examples to avoid confusion.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Michael Irigoyen
  • 22,513
  • 17
  • 89
  • 131
  • 1
    Duplicate of way too many questions, including http://stackoverflow.com/questions/1311368/which-is-better-on-performance-double-quoted-strings-with-variables-or-single-qu (this is more of a single vs double quote question, but then curly braces can only be used in double quoted strings anyway) – BoltClock Jan 13 '11 at 03:08
  • Yeah I seem to be the only one here who realizes your question isn't specifically about SQL (hence me saying "off-topic"). – BoltClock Jan 13 '11 at 03:49
  • 1
    PhpStorm correctly highlights the variables inside quoted in quotes separately. – nawfal Nov 06 '15 at 03:05

3 Answers3

58

All of the following does the same if you look at the output.

  1. $greeting = "Welcome, " . $name . "!";
  2. $greeting = 'Welcome, ' . $name . '!';
  3. $greeting = "Welcome, $name!";
  4. $greeting = "Welcome, {$name}!";

You should not be using option 1, use option 2 instead. Both option 3 and 4 are the same. For a simple variable, braces are optional. But if you are using array elements, you must use braces; e.g.: $greeting = "Welcome, {$user['name']}!";. Therefore as a standard, braces are used if variable interpolation is used, instead of concatenation.

But if characters such as tab (\t), new-line (\n) are used, they must be within double quotations.

Generally variable interpolation is slow, but concatenation may also be slower if you have too many variables to concatenate. Therefore decide depending on how many variables among other characters.

Amil Waduwawara
  • 1,632
  • 1
  • 16
  • 14
  • Thank you for the detailed explanation. I believe I'll continue to concatenate over curly braces. – Michael Irigoyen Jan 13 '11 at 05:15
  • 6
    Boah, really. @mririgo The single quotes micro optimization myth has been thouroughly [debunked](http://stackoverflow.com/questions/3446216/difference-between-single-quote-and-double-quote-string-in-php). Unless you have a 2GB php script with millions of strings in it, you will not be able to measure it - as it lies solely in the tokenizer. Use xdebug and find something real to optimize. – mario Jan 13 '11 at 09:52
  • 1
    When we develop web sites for concurrent access, we must optimize coding/web pages as much as possible. – Amil Waduwawara Jan 14 '11 at 05:54
  • 6
    Curly braces are not required with array elements. Simply take out the single quotes: $greeting = "Welcome, $user[name]"; This is the only time $user[name] will not result in a notice. – Luke Dec 22 '11 at 19:12
  • 1
    http://www.php.net/manual/en/language.types.string.php says you don't seed to wrap array elements with curly braces – Popnoodles Nov 27 '12 at 11:41
  • Regarding 3 and 4, 3 is easier to read but 4 is more explicit. 3 is shorter, but 4 will give you more consistent style. In the end it is personal preference. I like syntactic sugars, so I like 3 – nawfal Nov 06 '15 at 03:09
  • Thank you for the explanation, very helpful – faid Sep 21 '16 at 07:17
  • Could you elaborate on why 1 is bad? – Hashim Aziz Jan 21 '21 at 00:53
3

With pre-comiled PHP (Bytecode Cache) it makes no difference.

This feature come with PHP 5.5 (Zend Optimizer+).

alexwenzel
  • 2,361
  • 2
  • 15
  • 18
3

Although not dealing with injection attacks (including SQLi), it should at least be noted -- especially for PHP devs -- that using any of the above techniques without first encoding and validating all inputs will lead you to an injection-based attack.

It is important to remember security at the beginning of coding -- not the end when all of the code needs to be redone to comply with security requirements. Or, when you finally get this dang " vs. ' war down and realize that it doesn't matter because you are susceptible to XSS using either technique without properly encoding and validating all inputs.

  1. Encode using urlencode() or htmlenities() to normalize the input(s).
  2. Use data-typing for non-strings OR dictionary-lookup and/or regular expressions for strings to validate.
  3. Profit?
  • 5
    urlencode() and htmlenities() should not be used to normalize inputs. Rather, they should be used before outputting to the browser user-entered data that should not contain HTML, JS, or CSS. – dotancohen Jan 21 '12 at 19:13
  • 1
    If your doing SQL, *always* use prepared statements. Even the most well intentioned string santizers have been thoroughly thumped over time by various attacks. Prepared statements cleanly separate the logic from the data ,giving much more efficient data insertions and retrievals, and the security has been scrutinized by experts in the database field. Alternatively use a battle hardened ORM (preferably of the data-mapping rather than active-record variety, if you value performance and type safety) – Shayne Aug 07 '17 at 07:32