Formatted variables within strings

[racmaster]

I would like to see the variables within strings formatted the same as the ones outside strings, according to the user's custom settings. It makes the variables much easier to find!

[pixo]

That's something that suprise me using Notepad++.
But for skilled programmer, I think, it is just a joke.

Why?

Because it it good practise (and speed up for PHP) not to have variables in strings..

this is bad:

Code: Select all

$var = "why should PHP parser look for $var in this line?";

this is good:

Code: Select all

$var = 'why should PHP parser look for ' . $var . ' in this line?';

Find yourself why. There are more reasons

PS: Would be nice if this forum have syntax highlighter for code blocks. Or if HTML work as should...

[racmaster]

Agreed, though I have seen many a "skilled programmer" not use that convention all of the time. Why should the editor assume how we "should" code in all circumstances, making it a rule?

I'm not going to type it all out, but we all ceate apps where we have coded hundreds of lines of "good" coding in order to create a large personalized output. For the amount of speeding up it does for the PHP parser, it's not worth it to type out something like:

Code: Select all

$header = $title . ' ' . $firstname . ' ' . $lastname . '<br>' . "\n"
. $address1 . '<br>' . "\n" . $address2 . '<br>' . "\n"
. $city . ' ' . $state . ' ' . $ZIP . '<br>' . "\n";

$decline_message = 'Thanks, ' . $title . ' ' . $lastname . ' for your application.  However, on ' . $incidentmonth . ' ' . $incidentday . ', ' . $incidentyear . ', Resource Report #' .  "{$repor['num']}" . ' entitled ' . "{$report['title']}" . ', records an incident stating ' . "{$report['summary']}" . ', which you did not claim on your application." ...

When I could take half the time to type out (with no appreciable affect to the PHP parser):

Code: Select all

$header = 
"$title  $firstname  $lastname<br>
$address1<br>
$address2<br>
$city $state $ZIP<br>"; 

$decline_message = "Thanks  $title $lastname for your application.  However, on $incidentmonth $incidentday, $incidentyear, Resource Report # {$repor['num']} entitled {$report['title']}, records an incident stating {$report['summary']}, which you did not claim on your application."

I think you get the idea. My point it is that we just don't always code in "good practice," and custom syntax coloring should do just that: color acceptable syntax, whether or not the author thinks it is "proper" coding.

As long as it is syntactically correct, my dang variables should be colored how I want my dang variables colored.

[llbbl]

I agree it would be nice to have variables inside strings with proper syntax highlighting. It is not always the quickest or easiest to have append them onto the strings, esp with larger queries.

[racmaster]

I don't think it is an author-preference issue with Blumentals since WeBuilder only allows HTML conversion to PHP within double quotes. Even for huge blocks, there's the option for "print" or "echo," but no option for double or single quotes.

They would know that the HTML parser would have to search the entire block of whatever, and there might only be HTML in the whole block - no variables at all...

[fuzzylogic]

Doing string appends, besides creating unreadable error prone code is also a very expensive operation involving memory allocation/deallocation and copy/move operations. If you poke around the php website you will find some documentation about this. php's string handling is highly optimized. There is nothing "bad" about putting variables inside of strings.

Beware of over optimization, it is far far better to have the computer do a little bit of extra work than it is to write a program that is hard to read and maintain.

as I mentioned in this post putting variables inside of quoted strings is a legitimate part of the php way of doing things.

consider the following:

$txtOut = "$First, $Last: $Code.$Title. $Other\n";

versus

$txtOut = $First .', '. $Last . ': '. $Code .'.'.$Title.'.'.$Other."\n";

now you tell me which one is more readable, and also did you notice that there is an error in the second version? can you spot it? I think not easily. The second version is much longer and the result is much harder to comprehend. The mistake was unintentional, but I decided to leave it in as an example of how much harder it is to format a zillion pieces. If this is the wrong approach to creating a formatted string, then why would designers bother with constructs like sprintf ?

Also please don't forget about color coding for HERE DOCs.