|
|
|
Current Projects: PHP on XP Guide — NFO Viewer — Easy Reflections — Photon Storm — HotWire — FileGlider
Friday, November 4. 2005PHP Tips, Apparently
I saw this article over on evolt.org today, offering up the evolt php'ers some hot tips to save time, cpu cycles and effort. Great in theory, shame about the actual advice though. First up is the classic "use $var++ instead of $var = $var + 1". While technically I'd agree with this, in the example he was giving it should really have been ++$var, otherwise the actual difference is insignificant. What worried me more however were the "tips" that followed...
After some string concats next up was using single quotes and not doubles. This is sound advice, although I would imagine the processor savings on swapping from " to ' are very small. Even so, it's good advice because it's good code structure. That is a far more important reason than processor overhead. Sadly the next tip breaks this structure advice (even if unintended) and recommends swapping out well formed if/else blocks for "if ($gollum == 'halfling') $height --;" single line affairs. Sometimes there is a good reason for doing this, but not in production code. When you're just hacking something together for a proof of concept or quick tool, then yes, but otherwise code readability should be your number one priority, and this just doesn't help in that regard. The same can be said for the next nugget - use (!$var) instead of ($var == false) (and similar for a true boolean check). This isn't bad advice, and I don't believe it's bad practise either - even the php manual recommends you save some time by doing it this way. What I do believe is that the easier code is to read, the quicker you understand it. And by read, I mean read - in an English context. If you're scanning a piece of code and it says "if ($bankrupt == true)" then, in your own head, you've read out exactly what the line is doing. If you remove the "== true" part, the code still reads the same way, but there are a few precious extra brain functions to fire off before you make that association. I firmly believe that the quicker you can read the code, the quicker you can understand it. In line with the readability topic, the next tip tells you to use tabs instead of spaces - because 4 spaces = 4 bytes, whereas 1 tab = 1 byte. Ok so you'll shave a few bytes off your scripts, but you'll render them non portable in the process as different editors display the tabs as varying widths. Stick to the pear guidelines on this one, use spaces. Then you *know* what your code will look like, even if you move IDE. The final gem tells us to use $_POST and $_GET instead of relying on register globals being available. A fair comment if it wasn't for the fact it's followed up by telling us to instead loop through the PGCS arrays and create variables from them all: "foreach ($_POST as $key => $value); $$key = $value;". This of course un-does the benefit of actually having register globals turned off, and as well as being a security nightmare worthy of making Chris S bang his head on his keyboard in dispair. It's also a complete waste of processing. If you really must do that, at the very least use extract() instead. I don't mean to slam this guys work, the Internet is a good place to impart your learnings, findings and skills with others - but just be careful where you get your advice from, because it's not always all that great. Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Awesome article man. I almost posted something myself on my blog in response to that former article. They got it way wrong, and you said exactly what I would have. Kudos.
Thanks! I felt quite guilty when writing it, but then I just re-read the evolt piece and thought "sorry, no way man, this is whacked advice!"
Actually, use of extract() is depreciated. Since you can overwrite other var values. You would have to mention to use the correct parameter, because without it it's a big security hole
That was my whole point! If you're going to do something as insecure as loop through the $_POST array making variables from it, you may as well use extract. Not because it's any safer, just because it's quicker!
I don't advocate doing it for a second.
Geeze there have been so many of these types of articles out there on the web. I think the community would benefit more from article like those from Chris S or most of the folks at planet-php.
I think it would really benefit the community as a whole to re-imagine the php.net site. I think that if (similiar to the zend site, but with more real world examples) it had articles or tips or something from leading developers, we could hopefully bring up the overall level of people checking into PHP.
I have to agree. There are sites that do offer some quality tutorials, but often they are so covered by ads that it makes them totally unappealing (take devshed.com for example, I love the content, I utterly loathe the design / advert pollution). But something presented on php.net itself would have that "official" stamp that might make people sit up and take notice.
Thanks for the response - I was shocked to see that article myself.
The single-quotes/double-quotes thing has been debunked for a long time ( there's that excellent phplens article on it among other things ), not using brackets is just bad form ( speaking from experience - you'll ALWAYS regret it later. ), and the tab vs. spaces "argument" is utterly insane. --Simon
I have to play the devil's advocate here on the tabs issue. Over the years I have gone back and forth between tabs and spaces. In the end, I think the argument you cite as being the reason *not* to use tabs is the very reason why people *should* be using tabs.
Editors are customizable to display tabs at whatever size the viewer prefers. If everyone uses 4-space tabs (like PEAR suggests), then the guy who likes 8-space tabs (they do exist) won't be seeing it in his preferred manner. And the guy who uses 2-space tabs (me) will be in the same boat. If you use tabs, then any decent editor will display the file with the correct indenting, it will just be larger or smaller indents as the case may be. I hate 4-space indenting because I find it to be a waste of space when 2-space indents are fully readable and save precious columns for those of us who keep our lines under 80 chars. The only legitimate argument I have uncovered against tabs is that *some programs* don't display the tabs correctly when it comes to partial width tabs. Specifically, I mean if you are using 4-space tabs and you write 2 chars and then tab and then 2 more chars you should have this: "cc--cc" Apparently some *lesser* editors would view that as a full tab and would render it thusly: "cc----cc" That would be incorrect. However, I feel that accommodating the falacies of programs who are doing it wrong is counter-productive. Also, 80% of the arguments I hear against tabs is simply because "PEAR Standard says use 4 spaces". Well, just so everyone's aware: PEAR isn't the law. It's a set of guidelines which have been put together for consideration. For the most part I agree with them, however we should be willing to question these guidelines if we think they could be improved just like we are willing to question the law when something seems to be in need of change. I'd really like to see the tab/space rule in the pear standards changed...
I guess the problem is this - a space is always a space, any editor, no matter what it is, on whatever platform, will render it as a space. Whereas tabs are open to interpretation on a much much wider scale. I.e. they can -never- be consistent, in the same way as a space is. I think this is why the pear standards on it will never change, but I do understand your point.
Ok, help me out here. (And yes, I realize this is a newbie question.)
*foreach ($_POST as $key => $value); $key = $value;* is bad? If I create a form and use the above syntax to get the values of each key in $_POST, those values won't be overwritten by adding ?=field1=xxx to the URL. Assuming you're validating everything anyway, why is the above line dangerous?
Because you can't trust form data. You are blindly extracting all values from the form into your script. Should a value already exist, it will be overwritten with whatever was in the form. Validating everything you expect to receive is one part of the equation, checking you receive nothing else at all is the other. It's best to use a white-list approach to this, extract only that which you should and take it from there.
And is there a better way to do that (besides the obvious way of using $_POST['variablename1'],$_POST['variablename2'], etc)?
I'd start with this: http://shiflett.org/articles/security-corner-may2004 specifically the "Where Is the Trust?" section towards the end.
*lightbulb going off* ok ... now the dots are starting to connect. (funny how you know things -- like how to spoof a POST request -- but never make the connection to other things -- like spoofing $_POST form data.) merci.
Hi Richard,
it may be helpful for the PHP community as a whole if you post a summary of these comments under the actual evolt article, or at least link to it? I scanned the comments on evolt and couldn't see anything from you....
Somehow I do not feel the majority of people there will take too kindly to my comments, but you're right, it did ought to be added, especially as this is still a front-page topic.
Ha!
Great to see this article. In fact, I'd already pointed that problem out in the comments section with: "This is effectively the same as turning register_globals on defeating the purpose of keeping them off in the first place" but it's nice to see it being backed up
1. Why do you think there is a performance difference between ++$var and $var++? I just compared these two
time php -r 'for ($i=1;$i<9999999;++$i);' time php -r 'for ($i=1;$i<9999999;$i++);' and found no significant difference. 2. How is using ' better structured than " ? 3. I would be mildly surprised if the PHP manual recommends using !$var instead of $var==false for performance. I looked at http://us2.php.net/manual/en/language.operators.logical.php and did not see anything about this. Certainly it is possible, but I think the language implementors would have to be pretty brain-dead to handle these two constructs very differently. 4. I don't understand how you can think "if ($bankrupt == true)" reads more naturally than "if ($bankrupt)". Listen to yourself -- "if bankrupt equals equals true" vs. "if bankrupt". The second one is an actual English language clause while the first is a bunch of syntactic gibberish. Same goes for "if (!$bankrupt)" which would be read "If not bankrupt". But this is fairly subjective, unlike points 1-3 where I suspect you are just plain wrong
By the way your website sucks because I just lost my whole comment since I had a less-than in the second line. Basically it went on to ask how using single quotes yields better-structured code than double quotes, and points out that I can't find anything in the PHP manual recommending !$var instead of $var==false for performance reasons.
The performance between a pre and post increment is to do with the leg work PHP needs in order to complete the operation. A pre-increment will update the value first, while resident in memory, then return it. A post increment will retrieve it, update it and then have to store the updated result again. A simple timer expo on some random incs will not demonstrate something this granular.
Using single quotes *when required* is better code structure because it is a firm indication of the content, i.e. static. Double quotes signify dynamic content. $array['a'] is clearly a static 'a' key. Is $array["a"] guaranteed to be the same, or did you perhaps missing out a $? ($array["$a"]) - there's no clear way to tell. Code structure is about removing ambiguity. No-where do I say that using $var == false is better than !$var for *performance* reasons. Try reading the article properly?
Hey your website is not so bad; my text shows up now!
-- A pre-increment will update the value first, while resident in memory -- It's hard for me to know if you are being serious here, without any smilies. It sounds like you think you are programming in assembly. "Resident in memory"? As in, whether $i is in a register or RAM or in swap? Do you really think you are exerting some kind of control over PHP's memory management by using ++$i vs. $i++? -- A simple timer expo on some random incs will not demonstrate something this granular. -- Alrighty, just let me know what "granularity" this effect becomes noticible at so I can try it. -- Using single quotes *when required* is better code structure -- Ok, I take your point here about it's nice to know if a string is static. I wouldn't call this code "structure" since that word usually refers to flow control, modularity, separating code from data, etc. But the quotes thing is a nice convention. http://en.wikipedia.org/wiki/Structured_programming -- Try reading the article properly? -- Hrm, in case it was not clear I am referring to the statement -- even the php manual recommends you save some time by doing it this way -- when I say, "I would be mildly surprised if the PHP manual recommends using !$var instead of $var==false for performance". Capiche, paisan?
I meant saves time in the traditional sense, i.e. the time spent typing in fewer characters using the short-hand notation. If I'd meant performance I would have said so, but I didn't because it would have been incorrect.
If you wish to take the meaning of code structure back to the 1970s then yes, it would have made more sense for me to say the quotes issue gives way to a better 'programming style'. Although there is a certain degree of ambiguity, and a large dollop of personal interpretation, whichever way you want to look at it. Personally I believe the definition of 'structure' to have evolved somewhat, to encompass more than the traditional meaning (when it truly did cover goto's and the like). Some of the elements you describe in my mind at least would be better categorised under software architecture. Application flow control / modularity certainly would, whereas code flow control sits further down the chain, but one will always influence the other (well, hopefully at any rate!). Perhaps one day someone will coin a term that encompasses *everything* - from the architecture right down to the minutiae - the tabs used, the way comments are placed, quotes or not, etc. But with modern day principles taken into consideration. Or maybe they already have (links/evidence welcome)
I'll bite. Excellent article, good critique, good points. J. Random has a point for the wrong reason, however. The example on the page _should_ have been a post-increment, not because of performance but because it is technically correct.
If I recall, the article suggested changing something like: $myvar = $myvar + 1; into $myvar++; and then offered some examples of that happening. The code being translated is a post-increment. That is, $myvar takes the new value _after_ the line is executed. The fact is, ++$myvar is _not_ the same as $myvar = $myvar + 1, whereas $myvar++ _is_ the same thing. Now whether the difference is significant is another issue.
It really is true that PHP is the language of choice for people who don't know how to program...
FWIW, if you have a line such as f(++$x); this is the same as; $x = $x+1; f($x); while f($x++); means f($x); $x = $x + 1; SO if you have a line which does NOTHING except increment $x, the following are EXACTLY equivalent. $x++; ++$x; $x = $x + 1; Only if we have to use the RETURN VALUE of the expression, such as $y = ++$x; THEN we see a difference.
"SO if you have a line which does NOTHING except increment $x, the following are EXACTLY equivalent."
The end result is equivalent. The steps PHP had to make *internally* to get there however will differ in each case.
I think the whole preincrement-vs.-postincrement and single-quotes-vs.-double geek-battles are, in this day and age, frankly crap.
Especially when the people who fight them most ferociously are most likely the ones who don't understand why their code is so slow after they've 'optimized' all their variable increments and quoted strings and completely failed to notice the big O(n^4) performance sink expressed in a half-dozen foreaches in a function that gets called on every page load.
I too was of the opinion that the processor overheads were of first importance when the single and double quotes are used in string defenitions... but your view about readablity.. does usage of single quotes with concatenation for variable substituiton help readablity.
$message = "Hello $full_name, it is $today, and you are expected $another_day"; $message = 'Hello '.$full_name.', it is '.$today.', and you are expected '.$another_day; tell me which one is readable, actually if you have more than a couple of hundred string additions, the page generation times is affected noticably, when the latter is used.
in my point of view, there are 2 types of code I matain.
Code in applications: Easy to understand Code for libraries: Built for speed In my applications, if is never without the {} but in my libraries, :? are often used if there is only one statement. |
QuicksearchCategoriesSyndicate This BlogMy AS3 Blog
Photon Storm Great PHP links
C7Y PHP Podcast CorePHP is hosted by |
