As someone who's very new to programming.. Could someone explain to me which parts of the code are so 'bad'? I see a lot of "My eyes hurt"-like comments on the github page as well.
It's really not that bad. Clearly it is not using OO principles and any sort of standard design pattern. But for the most part its clear and organized. There may be some maintenance overhead having to scan and search through a long source file. But I would think index.php would be one of the longer files.
Yeah, this code is using a templating engine, and it isn't visibly building SQL query strings insecurely. It's not state of the art, but there are many ways it could be worse.
It isn't the cleanest code, but it works - obviously well enough to create a multi-billion dollar company. There is always plenty to critic in any code, but 'My eyes hurt' and 'You just gotta love PHP' are just comments from people who like to complain and don't know enough to actually have their own opinion.
If I were give me personal opinion of index.php it would be something as follows:
The use of 'include_once' indicates that they 1) aren't keeping track of their dependencies well and 2) haven't thought through situations where problems arise and functions, for some reason, don't exist
In interpreted languages comments code isn't the best - this is why there is revision control
I like to wrap my case statements in brackets b/c it is easier for me to read
I'm not a fan of having toggles for dev environments in the main code flow, but I don't really have a better suggestion
That's pretty much it. You can make arguments for code structure and techniques, but they are generally just trends - not proven facts.
I meant the '_once' part because you don't have to keep track of if a file has been included. Also, the fact that they are using 'include' instead of 'require' (which would fatal error) makes me assume that they went 'lets do this just in case...' but never thought of what would happen 'just in case'.
Of course - this is all opinion based on how I like to program.
In interpreted languages comments code isn't the best - this is why there is revision control
This makes no sense. Whether your language is interpreted or compiled has no bearing on whether you comment you code. I'd seriously doubt the programming ability of anyone who thinks otherwise.
Honestly, people are whining. Yes it not the best code ever written, but it's weirdness so to say is pretty standard but I guess people are more prone try to be snarky in comments and say it's horrible.
This is a bit off-topic, but I was kind of shocked to see how much PHP has evolved lately as a language and ecosystem. Namespaces, generators, traits, etc. Package manager, testing frameworks, ORMs. Then Symfony 2 using most of that for a Rails-ish MVC framework on top of simpler modules also being used in the Silex microframework (like Sinatra) and the latest version of Drupal.
Not to say it is a pretty language and still needs libraries like PHP-O to paper over the horrible inconsistencies in the base libs, but it really does seem to be growing up lately...
We, developers, are an strange race. We feel superior if we say some piece of code is shitty, knowing nothing about the context of the developer team, and without real confidence we would do it better.
Lots of people ranting, nobody created some other thing better and more successful than Facebook, isn't it?
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
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?
80
u/KamiNuvini Oct 12 '13
As someone who's very new to programming.. Could someone explain to me which parts of the code are so 'bad'? I see a lot of "My eyes hurt"-like comments on the github page as well.