You're crazy.Call me crazy but perhaps if we use less lines of text, that could effectively increase fasting loading on a browser? Of course the speed most likely won't be a huge difference, however if a lot of lines are to be shortened, then perhaps we could save seconds?
Google's Page Speed threw a fit when I didn't minimize the whitespace in HTML.You're crazy.
kidding aside, not really.
The code I wrote above are PHP code, which is back end. If executed, both of them would provide the same output "true", or "false" based on $some_var. The HTML output is generated as result of the PHP code. When vrtsouls ask how many lines of code, I'm under the assumption he meant code in PHP because code in HTML he can just count by viewing the source code of each page and sum up.
As for the speed difference in HTML... not really again. Gzip compression is used, so the difference as result of the blank lines will become so small that it'll probably differ in less than a few bytes. Most people have decent connection that is capable of handling at least 10,000+ bytes per second, so the difference would be less than fractions of a second
Call me crazy but perhaps if we use less lines of text, that could effectively increase fasting loading on a browser? Of course the speed most likely won't be a huge difference, however if a lot of lines are to be shortened, then perhaps we could save seconds?
$is_happy = true;
$happygolucky = $is_happy ? 'true' : 'false';
I prefer the second examples (code blocks) for organization, personally. But really, the two syntaxes are just a matter of personally preferences.Ahh right, well thanks for the replies. I'm not too good with php, just a beginner. I'm more experienced with HTML and CSS. Anyhow, the only other thing I can say for having shorter lines of text is to keep the document organised?
if($a == $b) massiveFunction($input,$output,$variable); else reallyMassiveObject->longFunction($a,$b,$c,input);
Same. To me, it's much more logical than the first example.I prefer the second examples (code blocks) for organization, personally. But really, the two syntaxes are just a matter of personally preferences.
There's nothing illogical, unclear, or confusing about the ternary operator. Use it where it's appropriate and use an if statement where appropriate.Same. To me, it's much more logical than the first example.
Additionally, when it comes to someone reviewing the code for whatever reason, it's much more clear to them what you are doing. This is also why I always use XHTML Transitional.
Most of the time, when I use the shorthand versions, its to to assign variables where that's all I'm doing. (See last post for the example) If I didn't, the code would be come more unwieldy and unmanageable for a time. Imagine having 9 variables being assigned values based on a few variables are set. That's quite a lot more by using the block syntax.Same. To me, it's much more logical than the first example.
Additionally, when it comes to someone reviewing the code for whatever reason, it's much more clear to them what you are doing. This is also why I always use XHTML Transitional.
Well... the whole point I was trying to bring out is that lines of code doesn't really make any difference in a software as there are different ways to code exact same thing... I guess the same idea is if I do either of these in HTML:Ahh right, well thanks for the replies. I'm not too good with php, just a beginner. I'm more experienced with HTML and CSS. Anyhow, the only other thing I can say for having shorter lines of text is to keep the document organised?
<html><head></head><body><table><tr><td>Cell 1</td><td>Cell 2</td></tr></table></body></html>
<html>
<head>
</head>
<body>
<table>
<tr>
<td>Cell 1</td>
<td>Cell 2</td>
</tr>
</table>
</body>
</html>
To me, it just doesn't feel natural. However, this is the first time someone has presented to me, a piece of code with ternary operators. Having said that, I've just read the manual pertinent to this, and it seems like a suitable, workable alternative.There's nothing illogical, unclear, or confusing about the ternary operator. Use it where it's appropriate and use an if statement where appropriate.
But extend this to the whole page, and whitespace does and can make a difference. As you've shown, it can be almost double the size of the equivalent minimized file (uncompressed).Uncompressed, they'd be 94 bytes and 193 bytes; passing through gzip and they're down to 91 bytes and 105 bytes. The 14 bytes difference isn't going to break anyone's internet connection... even the 100 bytes isn't really going to show up as much of a delay anyways
To me, it just doesn't feel natural. However, this is the first time someone has presented to me, a piece of code with ternary operators. Having said that, I've just read the manual pertinent to this, and it seems like a suitable, workable alternative.
They shouldn't if you have a proper DOCTYPE. Unless I'm missing something...andHTML:<span>A</span><span>B</span>
HTML:<span>A</span> <span>B</span>
Will render differently though.. annoyingly
Ternary Operators were probably one of the first things that came up when I was learning PHP after things such as if(), else if(), and else(). Probably because I learned through vBulletin and that used them.To me, it just doesn't feel natural. However, this is the first time someone has presented to me, a piece of code with ternary operators. Having said that, I've just read the manual pertinent to this, and it seems like a suitable, workable alternative.
I was going to ask you how useful it was for conditional branching. Once I get my paws on XF, I'll be reviewing it, simply because I want to break away from the traditional way of doing things, and learn alternative ways. I've finally got my head around basic OOP.It's useful for assigning variables, but not so much for handling conditional branching in a script.
When they are cleanly indented, the tab/newline counts as whitespace to be output, causing a space between them on the second exampleThey shouldn't if you have a proper DOCTYPE. Unless I'm missing something...
We use essential cookies to make this site work, and optional cookies to enhance your experience.