Slowly reworking an "MVC" framework website that was written by a Java guy who liked to make things way to complicated.   Get Req-> some-page.php -> require_once( someController.php) -> require_once(someControllerBean.php)-> require_once(someControllerHelper.php)... controller is 12 lines of boiler plate code, the bean handles views but no logic, and the helper is a mix between a controller, a view, and a model.... then require_once(viewPageEverythingUses.php) which is this amazing puzzle/maze of exceptions and one of conditions.   Don't forget the require paths are bizarre '../../libs/../models/.././libs/'   that has to be a joke right?

Meanwhile the website was developed in 2006.  When I migrated the entire mess off the old server and onto a new machine I found all sorts of attempts to use php5 that were commented in the code but no changes or attempts to change the httpd conf files.  Also I found one sad attempt to get tomcat running on a long forgotten vhost conf file timestamped to a month before they started coding in php.   I don't have a problem with php, especially php5 but I'm getting tired of all the "Senior" php5 developers who don't know anything else but what they googled.

All time favorite line of code.

Unset($arrayVariable);

foreach($someOtherArray as $line)

   $arrayVariable[ = $line;

unset($arrayVariable); 

$arrayVariable = $someOtherArray; 

2nd place goes to:

bottomImageTag.php

<?php

   print ("<img src=\"/path/2/images/img.jpg\">");

?> 

 The bottom one may be justifiable. There may have been plans (or the dev had foresight) to include more html/code/logic regarding that image. Instead of updating every file that referenced the tag, they just have to update the one file. It really depends on context though.

movzx:

 The bottom one may be justifiable. There may have been plans (or the dev had foresight) to include more html/code/logic regarding that image. Instead of updating every file that referenced the tag, they just have to update the one file. It really depends on context though.

Exactly.

Ion9:

Exactly.

Just a tip that I find useful: you can omit the final closing PHP tag in a file if there isn't any HTML that will follow.  It's completely valid PHP, it guarantees there is never whitespace after the closing PHP tag (which can destroy XML docs) and it just looks cleaner, IMHO.

   $arrayVariable[ = $line;

...you realize that the parser will choak on this line, right?

rohypnol:

   $arrayVariable[ = $line;

...you realize that the parser will choak on this line, right?

$arrayVariable[$i] = $line;

morbiuswilters:

Ion9:

Exactly.

Just a tip that I find useful: you can omit the final closing PHP tag in a file if there isn't any HTML that will follow.  It's completely valid PHP, it guarantees there is never whitespace after the closing PHP tag (which can destroy XML docs) and it just looks cleaner, IMHO.

Why use any PHP at all? You can just omit the PHP tags and place the HTML directly...

rohypnol:

   $arrayVariable[ = $line;

...you realize that the parser will choak on this line, right?

You realize "choke" isn't spelled that way, right?

mrprogguy:

rohypnol:

   $arrayVariable[ = $line;

...you realize that the parser will choak on this line, right?

You realize "choke" isn't spelled that way, right?

I didn't, until you pointed it out to me. But we're not all native english speakers; there are other people "out" there, if you haven't noticed...

Not at all the same software, but I once worked with a group that had something like $rev on the dev server, $rev - 1 on the QA server, and $rev + 2 on the production servers, with no plans to upgrade either the dev or QA servers - but they were looking at upgrading the prod servers.  To add to the fun, there were definitely 'correct' bits of code for each of the revisions involved that would cause problems on one or both of the other revisions involved.

I managed to convince the manager to direct his employees to fix the situation.  Unfortunately, that was only after they had a production crash due to rolling out a change that they'd tested in dev, tested on QA, modified to get it working right on QA, and in so doing, changed the code so that it would crash the production servers after several hours of apparent correct operations (that is, just long enough for the code to be deployed on all the prod servers.)

dtech:

Why use any PHP at all? You can just omit the PHP tags and place the HTML directly...

I am slapping you with my mind.  *slap*  *slap*

Yes, I know that is the WTF.  However, it is rare for someone to post an entire PHP file (with opening and closing tags) and seeing this reminded me of that useful little tip.  Leaving off the closing tag is something I never thought to do on my own, but the parser is fine with it.  If you've ever had to deal with another developer leaving a space or LF after the closing PHP tag and having it screw up some XML, then it's quite the awesome little trick.  I used to have a script that would scour our source and clean up trailing whitespace after closing PHP tags, but when I encountered this tip, I just dropped the closing tags altogether.

rohypnol:

   $arrayVariable[ = $line;

...you realize that the parser will choak on this line, right?

The missing bracket was a forum syntax error.   For the second code snippet, the WTF is that they printed out a HTML tag with php and that they closed the PHP scope in the file, increasing the likelihood of seeding the calling code with useless whitespaces.  I was sick a few years ago for a few months and ended up reading the PHP source code and found it immensely interesting that the parser looks for ?> or EOF to terminate the PHP scope.

Ion9:

For the second code snippet, the WTF is that they printed out a HTML tag with php and that they closed the PHP scope in the file, increasing the likelihood of seeding the calling code with useless whitespaces.

Plus it's just pointless complexity.  Instead of directly printing literal HTML it re-enters PHP mode and parses the string just to print it out.  Add the annoying escaping that must be done with double-quotes.  Seriously, why do people not use single-quotes wherever possible?  It's faster and easier, dammit!

Ion9:

I was sick a few years ago for a few months and ended up reading the PHP source code and found it immensely interesting that the parser looks for ?> or EOF to terminate the PHP scope.

Hence the nifty "omit the closing PHP tag" trick, as prescribed by Dr. Wilters¹ above.

morbiuswilters:

Seriously, why do people not use single-quotes wherever possible?  It's faster and easier, dammit!

I ran this through a somewhat brutal benchmarking test and found that echo is faster then print, and that "Hello {$username}, we haven't seen you since {$login_date_last}" is just as fast and seems more readable to me then 'Hello ' . $lastname . ' we haven't seen you since ' . $login_date_last.    Still either way is faster then using print for some reason.   And overrall the differences are only in the hundreds of milliseconds after the test cycles get into the millions.

http://www.phpbench.com/ 

Also, for MVC's class_exists('myClass') or require('myClass.php') generally runs faster then using require_once... just got to watch out for recursive requires of doom  myFile->requires(ThatFile)->requires(myFile).

Ion9:

morbiuswilters:

Seriously, why do people not use single-quotes wherever possible?  It's faster and easier, dammit!

 

 

I ran this through a somewhat brutal benchmarking test and found that echo is faster then print, and that "Hello {$username}, we haven't seen you since {$login_date_last}" is just as fast and seems more readable to me then 'Hello ' . $lastname . ' we haven't seen you since ' . $login_date_last.    Still either way is faster then using print for some reason.   And overrall the differences are only in the hundreds of milliseconds after the test cycles get into the millions.

http://www.phpbench.com/ 

I hate micro optimalisation like that with a passion. I'm all for fast code, but when people focus on such stuff i generally think they miss the big picture. If you want to make your application faster you should just profile it and find the biggest gain, not go mucking about with quotes.

I understand  you nor morb implied doing that, but it's just a mayor pet peave of mine, that i need to rant about whenever i hear someone mentioning the faster single quotes.

Ion9:

I ran this through a somewhat brutal benchmarking test and found that echo is faster then print, and that "Hello {$username}, we haven't seen you since {$login_date_last}" is just as fast and seems more readable to me then 'Hello ' . $lastname . ' we haven't seen you since ' . $login_date_last.    Still either way is faster then using print for some reason.   And overrall the differences are only in the hundreds of milliseconds after the test cycles get into the millions.

This stuff is all really minor, I agree with Stratos on this point, but I don't see why you'd go for the more complex double-quoting rather than single-quoting.  I don't quite buy your benchmark results, either -- it's hard to do good benchmarking.  echo is faster than print because print returns a value (and hence can be used as part of a complex expression) whereas echo does not (somewhere in the PHP manual this is explained).  I still would think that single-quoted strings would be faster since nothing inside has to be parsed, but they really are close enough not to matter.  However, to me double-quoted strings are much irritating because you have to escape double-quotes (which I use in output far more frequently than single-quotes), as well as handling escape sequences.  I think the inline variable expansion looks sloppy and has so many gotchas in it it's best to avoid (like having to use braces sometimes but not others).  Take a look at the following two examples:

'<a href="' . $url . '">' . $price . '</a>'

and

"<a href=\"$url\">$price</a>"

I think the first is easier to read, but consider if some function has to be added to format the price before it is concatenated with the string.  It would be a lot easier to just drop the function around the $price variable in the first example rather than digging into the second example and trying to modify it.  Eh, I dunno, maybe it's just me...

For the loading solution, there's an even easier way: register your own autoloader and have that called.  Then instead of using class_exists, just keep a static array of loaded files and check against that.  That should be faster than doing class_exists().  The autoload lets you get rid of circular dependencies by stripping all require or require_once code out of everything but the autoloader.  Then the load method is only called when an undefined class is encountered during execution.  This also makes using code easier: just use the class and don't worry where it is included.

morbiuswilters:

For the loading solution, there's an even easier way: register your own autoloader and have that called.  Then instead of using class_exists, just keep a static array of loaded files and check against that.  That should be faster than doing class_exists().  The autoload lets you get rid of circular dependencies by stripping all require or require_once code out of everything but the autoloader.  Then the load method is only called when an undefined class is encountered during execution.  This also makes using code easier: just use the class and don't worry where it is included.

This is what all the cool kids are doing. It's fast, it works, and by god it's cacheble. File operations aren't cheap you know, 5 cents to the platter.

stratos:

morbiuswilters:

For the loading solution, there's an even easier way: register your own autoloader and have that called.  Then instead of using class_exists, just keep a static array of loaded files and check against that.  That should be faster than doing class_exists().  The autoload lets you get rid of circular dependencies by stripping all require or require_once code out of everything but the autoloader.  Then the load method is only called when an undefined class is encountered during execution.  This also makes using code easier: just use the class and don't worry where it is included.

 

This is what all the cool kids are doing. It's fast, it works, and by god it's cacheble. File operations aren't cheap you know, 5 cents to the platter.

I've played with the class autoloader before, but I had problems figuring out a sane way to find the right class.    Say my library is spread over multiple folders and subfolders... would I have to scan that entire mess to find the one file I need or should I encode my classes with some sort of hungarian notation? ( mClassName for model, cClassName for controller, etc).

        Also what if for some stupid reason you have two classes both called the samething ( sucks but not unheard of for very large projects ). Even worse is losing a dependancy record in your code, "This construct came from this file"  and then its nice to embed a tiny bit of documentation by directory structure.  models/users/admin.controller.php for instance... I know this is a data interface for administrative users just by looking at the path.    Sure you can work around the initial costs by dumping a class:filepath in memcache, but isn't it easier to just include/require the files you need?

Ion9:

I've played with the class autoloader before, but I had problems figuring out a sane way to find the right class.    Say my library is spread over multiple folders and subfolders... would I have to scan that entire mess to find the one file I need or should I encode my classes with some sort of hungarian notation? ( mClassName for model, cClassName for controller, etc).

Yes you would have to scan the entire <perfectly structured> project. However trough the wonders of caching you will only do this once. (until you change something, then you have to remember to throw away your cached file :P )

I don't know what this is about class names, but i would suggest that having a sane naming strategy for classes is a accepted practice, and generally thought of as a good idea. If you think hungarian notation is a sane way of naming your classes then go ahead.

Mostly however you will see stuff like this

file name:  class.rssreader.inc

class name:  RSSReader

        Also what if for some stupid reason you have two classes both called the samething ( sucks but not unheard of for very large projects ). Even worse is losing a dependancy record in your code, "This construct came from this file"  and then its nice to embed a tiny bit of documentation by directory structure.  models/users/admin.controller.php for instance... I know this is a data interface for administrative users just by looking at the path.   

If you have two classes that are named the same you where going to hit a wall at some point anyway. Some projects solve this by implementing a poor mans namespaces like a class named Zend_Feed_Reader (example, don't know if it actually exists) Which will be located in Zend/Feed/class.reader.inc  or something. (don't feel like checking my facts, but it's the general idea)

The above also solves "losing" what your loading, because when you instantiate Zend_Feed_Reader you're going to have a general idea of what's happening. Also

Debug loggin, trust me, it works.

Sure you can work around the initial costs by dumping a class:filepath in memcache, but isn't it easier to just include/require the files you need?

Your loader can keep track of what's loaded and what isn't. This was the whole point of the tip.

Nothing wrong with require and include, but on large scale projects you want more control over what get's loaded and such.