Many echos
Moderator: General Moderators
Many echos
Just a quick little question...Should one use as few echo statements as possible for performance, or is it not of a matter?
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
Doesn't really make a significant difference, but more calls to echo will affect performance on one level or another. Looks a lot cleaner when doing
rather than
It is even better practice to capture all your output through the generation of the script and only output to the browser once execution is complete. Which is how most templating engines work. 
Code: Select all
echo 'this is a multi line echo
and it is much cleaner';Code: Select all
echo 'this is a single line echo';
echo 'Im very ugly :\ arn\'t i?';- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
I don't think you should put whitespace in the middle of code unless theres a good reason for it. As my editor has wordwrapping, I don't need to add extra returns for code readability. Plus, I always find people expect a carriage return in the code to be displayed to the user as a carriage return, and they're not.Jcart wrote:why
I think heredoc is the way to go, but I'm from the same school of thought as JCart...carriage returns in echo statements are no biggie...word wrapping or not this:onion2k wrote:I don't think you should put whitespace in the middle of code unless theres a good reason for it. As my editor has wordwrapping, I don't need to add extra returns for code readability. Plus, I always find people expect a carriage return in the code to be displayed to the user as a carriage return, and they're not.
Code: Select all
echo "<table>
<tr>
<td> </td>
</tr>
</table>";Code: Select all
echo "<table><tr><td> </td></tr></table>";- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
I love HEREDOC's. Mainly because you still get variable injection but don't need to escape quotes. Wonderful for building dynamic HTML.
I also dislike multiline quoted strings (whether its being echoed or assigned to a variable, etc); for some reason
HEREDOC's don't bring out that feeling in me, but there's no good reason for that. But I that both my dislike of multiline quoted string and like of HEREDOCs are just personal preference and not something I'ld argue for or against in others.
I do wish that php-mode in emacs would stop messing up the indenting in HEREDOCs, but that project seems to have died. (Please no editor wars here)
I also dislike multiline quoted strings (whether its being echoed or assigned to a variable, etc); for some reason
HEREDOC's don't bring out that feeling in me, but there's no good reason for that. But I that both my dislike of multiline quoted string and like of HEREDOCs are just personal preference and not something I'ld argue for or against in others.
I do wish that php-mode in emacs would stop messing up the indenting in HEREDOCs, but that project seems to have died. (Please no editor wars here)
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
I didn't say it was bad practise to use carriage returns in code, I just said I don't like them. I'd much rather write code that I find easy to maintain than use a standard I don't like. At the end of the day, how long I spend maintaining something is directly related to how much I earn, how easy the code is for other people to maintain has no affect whatsoever.Jcart wrote:I might be off but what about heredoc?-- carriage central. Would you consider heredoc bad practice then?
I ought to add that my coding shares a lot of similarities with things like the Pear standard, I'm not completely whacky.
Just a little whacky.
Well I'll try to answer, but its bound to be slightly unsatisfying (as it feels that way to me...)
Multiline string statements come in two kinds:
The former format, a shown by burrito and Jcart, preserves the editor's code indenting, by adding significant
white space. However the view source output is rather screwed up (as the first line isn't indented.
The latter format is often slightly jarring to the programmer as the "trusted" indenting is broken, but the resulting HTML is "cleaner".
I've seen some applications that do:
All as ways of addressing these problems -- the first two version in this batch show correctly in both the
browser and the view source. However, I do feel that they "clutter" the source and make simple functions look huge. If ths style is going to be variably indenting it often requires an str_replace of \n with \n$tabs after string assembly, not bad, not too clean either... The final method is trivial to allow nested indenting, but still breaks the editor.
Now the unsatisfying part.... Why I'm not bothered by HEREDOCs breaking the indenting? And I don't know. Maybe just because there were directly designed for multi-line string use? Still that doesn't answer... It does explain why I do like the PhraseBook pattern or simple string constants -- move all multiline strings outside the "real" code.
Multiline string statements come in two kinds:
Code: Select all
echo "<table>
<tr>
<td>Hi Mom!</td>
</tr>
</table>";
//
// OR
//
echo "<table>
<tr>
<td>Hi Mom!</td>
</tr>
</table>";white space. However the view source output is rather screwed up (as the first line isn't indented.
The latter format is often slightly jarring to the programmer as the "trusted" indenting is broken, but the resulting HTML is "cleaner".
I've seen some applications that do:
Code: Select all
echo " <table>
<tr>
<td>Hi Mom!</td>
</tr>
</table>";
//
// OR
//
echo "
<table>
<tr>
<td>Hi Mom!</td>
</tr>
</table>";
//
//OR
//
echo "
$tabs<table>
$tabs <tr>
$tabs <td>Hi Mom!</td>
$tabs </tr>
$tabs</table>
";browser and the view source. However, I do feel that they "clutter" the source and make simple functions look huge. If ths style is going to be variably indenting it often requires an str_replace of \n with \n$tabs after string assembly, not bad, not too clean either... The final method is trivial to allow nested indenting, but still breaks the editor.
Now the unsatisfying part.... Why I'm not bothered by HEREDOCs breaking the indenting? And I don't know. Maybe just because there were directly designed for multi-line string use? Still that doesn't answer... It does explain why I do like the PhraseBook pattern or simple string constants -- move all multiline strings outside the "real" code.
as onion said, it's all a matter of personal preference...there's no right or wrong way to do it as long as it works...and in this case everything posted does.
to touch on nielsene's points:
I code it so it's readable by me and any other potential future coders who might be reading/modifying my work (source)...not for end users who "view source"....therefore the indents etc only need to be kept in tact within my editor. Don't get me wrong, I understand the value of end users being able to view source and seeing the code as it was "developed" to be, and again this is just personal preference, it's not as important as being legible by the people who are actually going to be manipulating it.
to touch on nielsene's points:
I code it so it's readable by me and any other potential future coders who might be reading/modifying my work (source)...not for end users who "view source"....therefore the indents etc only need to be kept in tact within my editor. Don't get me wrong, I understand the value of end users being able to view source and seeing the code as it was "developed" to be, and again this is just personal preference, it's not as important as being legible by the people who are actually going to be manipulating it.
Well I view the "view source" as a developer's tool, not an end-users one. Its secondary to me if my users look at the source. When I have a funny layout bug, I want to be able to see and understand the source, therefore the indenting of the source matters to me. In fact most functions that generate significant amounts of HTML inject <!-- BEGIN CLASS:FUNCTION --> and <!-- END CLASS:FUNCTION --> comments into the code around their output to help localize where the problem can occur as well.Burrito wrote:as onion said, it's all a matter of personal preference...there's no right or wrong way to do it as long as it works...and in this case everything posted does.
to touch on nielsene's points:
I code it so it's readable by me and any other potential future coders who might be reading/modifying my work (source)...not for end users who "view source"....therefore the indents etc only need to be kept in tact within my editor. Don't get me wrong, I understand the value of end users being able to view source and seeing the code as it was "developed" to be, and again this is just personal preference, it's not as important as being legible by the people who are actually going to be manipulating it.