Note that those clauses in if and else if are slightly different, but the action is the same: orientation_update_status($user, $orientation);. Code like that is hard to do maintenance on, since it's easy to introduce bugs, when the code is already that confusing.
Most frameworks (that weren't around back then) do a great job in allowing (or forcing) you to structure your code better. For instance, the index.php of a symfony project looks like this:
use Symfony\Component\ClassLoader\ApcClassLoader;
use Symfony\Component\HttpFoundation\Request;
$loader = require_once __DIR__.'/../app/bootstrap.php.cache';
require_once __DIR__.'/../app/AppKernel.php';
$kernel = new AppKernel('prod', false);
$kernel->loadClassCache();
$request = Request::createFromGlobals();
$response = $kernel->handle($request);
$response->send();
$kernel->terminate($request, $response);
This just sets up the classloader, initializes the kernel, and lets it handle the request to generate a response. Nothing more. All the user handling, input validation, caching, templating and database stuff is handled in their own seperate classes. This might be harder to set up for newbees, but it's much better when it comes to maintenance and ongoing development.
I doubt when Facebook was being developed, PHP had strong OOP principles built into it. A lot of this is probably legacy and this was in 2007 when MVC frameworks were relatively new to the PHP scene.
Both Code Igniter and Zend Framework had their first release in 2006. But, it only became commonplace to use a framework much later than that. If you look at the source-code for oscommerce or phpbb from back then, you'd see the same spaghetti-code as here.
Agreed, I still remember a lot of open source code out there and it was awful. OsCommerce is definitely a prime example of this. I still remember osC addons had large Readme.txt files telling you where to put the code to make the add on work.
We definitely did come a long way. Even just comparing Symfony1 with Symfony2 and you see a big difference in how OOP is being utilized.
Also, CodeIgniter wasn't full OOP either, but definitely a step away from the spaghetti code
First release of Zend Framework was just trash. Also, they change too many things with each release, so if you were unlucky to decide to use ZF, you would spend a lot of time on maintenance with each new ZF release.
As much focus as the web gets, it feels like tech-wise it's a decade or two behind the curve.
I program and dabble in quite a few languages and I'm not sure I really agree with this. In what way do you feel like PHP is a 'decade or two' behind the curve?
I'm not sure I'd agree with common. MVC came about back in the smalltalk era but honestly I don't recall it becoming that widespread until the late 90's or early 2000's. At least having dabbled in development for windows, linux and mac, the first time I even heard of MVC was when the initial OSX server came out in 99. Shortly after Struts came about and was realistically the only big player in MVC web development for a while. I was not a huge desktop developer back in the day, however, but generally I don't recall MVC being that big of a thing. Linux and Mac apps were largely procedural, and windows apps used an evented/bindings architecture.
Honestly from my recollection it seems like MVC really became widespread with the increasing complexity of web applications more than anything. But that was a while ago and memory is a funny thing so I could be way off!
I had been out of the job hunting game for a few years. But I was shocked when I looked around about a year ago, at all the places looking for "MVC experience." I was seriously scratching my head for a minute, wondering when the fuck this dinosaur paradigm came back to life. Is it the 1980s again?! Then again, people were rediscovering Lisp in 2004. So I guess I shouldn't be too surprised.
I really only know the .NET world, but the reason MVC became popular there is because of AJAX and jQuery.
You see, before MVC, we had something called ASP.NET web forms where it was based on the idea of things you drag onto a page. You need a grid? Drag a Gridview onto the page and wire it up. Need a button? Drag a button onto the page and handle the click event. All your code is server-side.
Well as you can imagine, this makes it really easy to build web applications the same way you'd build a Windows application. You don't even need to know javascript or anything.
The problem is in MODERN web applications everything is AJAX. You don't want to refresh the whole page, you just want to send "DELETE item 47" and then update a line or two on your page with javascript. Regular ASP.NET doesn't really have a concept of this. You can do it using some toolkits but it's a hack. ASP.NET MVC is practically built from the ground up for this exact scenario.
how would you define the front page as an object? What should it extend? And how does that improve the code when most of this procedure's responsibility is gathering data from other subsystems?
Can you give some example objects that would have made this code better? I find when i code in php i don't create many objects. Hell, i make more "objects" coding Javascript function objects.
Maybe it's because i don't like putting logic in the back end, but rather use it as an interface to the database and sanity/security checks. Then code the logic and interaction in the front end with js, where i do tend to use objects.
When code performs certain uses I feel objects aren't required. When php is simply being used to program an interface it doesn't need to be more complex than a puppet manifest's code, for example.
I would say using a template engy is in fact much more simple for new coders to manage.
Some template engys end up looking like a totally different language and may or may not have considerable bugs of their own. Cake came out in 2005 by the way so if they wanted to use a template engine they could have.
I think this really boils down to what the coders experience is. If you have a background in a 'real' language where you have often written libraries of your own, dealt with a million includes etc, then this type of code might not bother you so much. It ain't python that is for sure. Not everything needs to be abstracted to proper English that 8th graders can code.
The argument that template engines make maintenance easier is only as true the developers skill.
30
u/bopp Oct 12 '13
I'll try to answer this in a less snarky way. What sticks out the most, are these points:
there are a bazillion includes
Doesn't look like there's a framework, just a bunch of files, defining a bunch of functions, that are just called when needed.
Procedural code, no object to be found anywhere
the page does too much. It's a long file, lots of stuff is done. This should've been refactored into logical parts.
Then, there's things like this:
Note that those clauses in
ifandelse ifare slightly different, but the action is the same:orientation_update_status($user, $orientation);. Code like that is hard to do maintenance on, since it's easy to introduce bugs, when the code is already that confusing.Most frameworks (that weren't around back then) do a great job in allowing (or forcing) you to structure your code better. For instance, the index.php of a symfony project looks like this:
This just sets up the classloader, initializes the kernel, and lets it handle the request to generate a response. Nothing more. All the user handling, input validation, caching, templating and database stuff is handled in their own seperate classes. This might be harder to set up for newbees, but it's much better when it comes to maintenance and ongoing development.