What are the "Bad Parts" of PHP?

In a security sense, the "Bad Parts" of PHP are simply bad habits that formed around conveniences included in PHP 4 and earlier. Many hosting companies still run PHP 4 or run insecure versions of PHP 5, mostly because they don't want to break applications that their clients built using these conveniences. I'm talking mainly about auto escaping user input and automatically registering POST and GET variables in a global scope. These are widely discourages, often disabled and will soon be phased out completely from PHP. As with any language, a PHP script will only be secure if its developer is security-conscious. Plenty of other languages can be programmed insecurely, too.

In a general sense, I've seen really crappy PHP code and really beautiful code, both using procedural and object oriented techniques. The truly beautiful code used one or more accepted design patterns which made it easy to navigate. (I'm thinking mainly of MVC, but plenty of other good design patterns exist too.)

In a technically sense, I've hear that committing a patch or new function to the core PHP team is cumbersome.

Otherwise, it's a very flexible language that has plenty of support and is easy to get started with.

That's true about trade-offs. You sacrifice one thing to make something else easier. One of the first things that comes to mind when I think of trade-offs and PHP is the lack of typing. By sacrificing type information, I can more quickly get a prototype written. However, I'll eventually suffer from difficult-to-find bugs later on, and if the codebase eventually becomes large, the lack of type info will make refactoring more difficult. So that's one.

The other parts of PHP that have, in the past, been needles in my neck are slowly being integrated into the language: namespaces and object-oriented semantics. A single namespace means putting literally thousands of chefs into one kitchen. Even if they do somehow manage to get along, you run into the problem of function identifier collisions. OOP still isn't really there, though. I hope to one day see 99% of the global functions get pigeonholed into their own namespaces. It would not only reduce the potential for collisions but also make code more readable since namespaces provide CONTEXTUAL information to developers, letting them know the applicability of a given method. Example: a sort() method in a String class is different than a sort() method in a Color class.

PHP has no "Bad Parts"

Just too many bad developers because it's so easy to make it go.

inconsistent_function_naming() && order(of, prototypes);
ini_set("register_globals", true) && ini_set("magic_quotes", true) // halfway gone
if (phpversion() < 6) { $unicode = false; }
$ternary_associativity = "php" ? "left" : !"right";

I agree with trachtenberga : until PHP6, unicode support is the big problem developers have to manage.

inconsistent_function_naming() && order(of, prototypes);
ini_set("register_globals", true) && ini_set("magic_quotes", true) // halfway gone
if (phpversion() < 6) { $unicode = false; }
$ternary_associativity = "php" ? "left" : !"right";







Seo Course Delhi