DEV Community: Dedipyaman Das

PHP sucks, can it suck less?

Dedipyaman Das — Thu, 26 Sep 2019 18:39:33 +0000

PHP has garnered a bad reputation in the software market. Many developers hold strong opinions against the language and to some extent, that's correct. Over the last few years, although PHP has gone through an evolution and is it the same "Fractal of Bad Design"?

This post was originally made to my blog: Twodee's Kitchen. I would love for you to visit that and show some love.

Yes, I admit it. PHP sucks.

And I shamelessly write PHP code, so I must suck too, right?

As popularly stated in the famous article PHP: a fractal of bad design :

PHP is an embarrassment, a blight upon my craft. It’s so broken, but so lauded by every empowered amateur who’s yet to learn anything else, as to be maddening. It has paltry few redeeming qualities and I would prefer to forget it exists at all.

The article has only gotten popular over the years, and it's still being circulated over Quora (One of them being the founder himself, Adam D'Angelo).

And while the article came out, yes, it was right. It was badly designed and badly implemented. The users made it worse. While PHP came along, it didn't originally plan to be as massively used as it is today. Since it was so easy to adapt to, people started using it everywhere. It worked to some extent.

As soon as the web got more popular, we changed, our needs changed. PHP didn't. It was still stuck behind, probably due to the community? It was inconsistent with its naming, it had the insecure mysql_* functions built into its design. There were a lot of gotchas in the language, and having used PHP for a long time, I know that it is a pain.

But this is 2019. The article was written in 2012. I am surprised people still keep quoting that article everywhere!

C'mon people, PHP has changed (evolved) a lot, don't tell me the public eye is too blind to see it.

PHP has had some major pushes like the HipHop to HHVM movement from Facebook and PHP 7. Developers have recognized the issues that came along with it, and they have been addressing it so far. If you are living in 2019 and still writing mysql_* functions (or blaming PHP for having that), you seriously need to learn to RTFM.

So why this hatred still?

Well, as long as something's popular - people will hate it. People hate Java, people hate C++. When millions use your product, you cannot expect everyone to be happy customers with every design decisions that you make. There will be people who don't like your approach and that's true for any remotely popular language.

People often compare Python to PHP in the web context. I have nothing against Python, I think it's a great language that fits the purposes it was intended for (scripting?) and purposes it was adapted popularly for (AI/ML/Data Science?).

But here's where Python fails to impress me against PHP:

It's slow. Not a deal-breaker (especially on the web), but I am making arguments for the sake of making arguments. If you still complain about PHP being ugly, I can complain it about being slow.
It needs a framework for anything web. Initially, when I just wanted to get a Python application up and running for the web, I had the community continuously push me over to use Django or Flask. I hate being coupled to a framework, as many others would (and should) be too.
Whitespacing? Not a fan. Again, it's not a deal-breaker, but having whitespace mean something doesn't make sense to me. I understand that it was a design decision to keep the lines cleaner, but when things break because I missed an invisible whitespace - it hurts my feelings.
Its Object-oriented model is alien to me. Access specifiers are done by enforcing conventions with underscores? Okay. No. Maybe it works for some folks, but I like things being implied explicitly rather than implicitly.

But okay, Python is a great language. It works great, it's got a great community and yet - there are people who hate it. And that's okay if you are remotely popular anywhere - you will have people not liking you.

Javascript on the other hand - It's something I really don't like. It's a matter of personal opinion. Especially after the fact that some Javascript dudes who are a few years older than me were trying to shove Node.js down my throat and bashing PHP for the time I was in front of them. Asserting that Node is far superior, safe and faster than PHP (and anything else for the web) and I should learn Node right away.

They went as far as saying that PHP invented SQL injection. I stopped trying to speak at that point.

Coming back to PHP:

Do you still have/write legacy PHP code that follows the arcane PHP 5 approach?

I have a list for you:

Start writing OOP

While you can still write procedural PHP, the community has moved towards an object-oriented approach. It simply fits the new model and works great to have you structure the code well. With object-oriented, several clean coding practices like SOLID and DRY are automatically implied.

OOP silently enforces clean structuring of your codebase and keep things separated better. Of course, it's optional, if you like writing spaghetti code, no one's stopping you. You can make the worst out of PHP and give yourself a bad name. But that's entirely up to you, any language will allow you to do that. Not just PHP.

Strict type as much as you can

While we are at the subject, also use Strict Types. It's as simple as: <?php declare(strict_types=1) at the beginning. Static typing surely helps you keep things consistent and safe. Yes, PHP is a dynamically typed language, and we need to squeeze that feature out of PHP sometimes. But in most cases, going by the safer path with strict types can save you from a lot of weirdness and unpredictability at runtime.

Namespaces, please

The include statements on top of the page are no more common and the community recommends that you use namespaces to "import" modules you need to "use". Its a means of abstraction over your raw PHP files that allows you to encapsulate the include logic.

Yes, it could be weird to use \ as the namespace separator at first, but you'll get used to it. Get rid of those includes and start using namespaces to put things into their correct places. Which brings me to my next point:

Composer

If you are planning to start a PHP project, get composer immediately. It's a dependency management tool which allows you to define your dependencies, your application and test entry points and load dependencies from the central Packagist repository as you need them. It generates an autoloader for you, and that's the only thing you should include in your entire project.

Throw away `mysql_*`

All the mysql_* functions have been deprecated for a long, long time and it has been removed in PHP 7 for good. So if you are still complaining about mysql_* functions being bad, please upgrade your PHP version. The best way to deal with a database as of now is to use PDO with prepared statements. It's a generic API that works quite well with a vast array of databases.

The things that I like about PDO are: it's clean, relatively modern design, object-oriented and consistent. You will move to exclusively use PDO in no time once you start a project with PDO.

Again, don't create DB wrappers like DBConnection extends PDO. Just don't. If you need some sort of abstraction over PDO, check out the Data Mapper pattern and some ORM like Doctrine (and not some evil Active Record variant).

Separate your concerns

Most of the bashing PHP gets today is because new developers mess it up so bad, that it smells worse than Javascript (I am opinionated, sorry). Because its easy to learn and get started with, newbies just can't resist themselves from writing hacky code and deploying it to production.

Other languages don't get this because

a) they have a steeper learning curve

b) they give out a strict design strategy beforehand.

c) It takes time to get them up and running.

Fix this by separating your concerns. I remember once I used to copy-paste portions of long functions to other files to do the same thing, but slightly differently. I understand why beginners do that.

Start off by making your functions smaller.

Break your codebase down to small pieces acting independently doing exactly one thing. Read more on SOLID and DRY principles.

If you have a User class, don't allow it to be able to create a message, encrypt the message and also send the message to another user.

Incorporate libraries from the internet, people solved your problems with better testing well before you did. And they did it better. Whilst we may be tempted to have everything custom made, we tend to deviate from the actual business needs. Focus on your business logic, use what's already available.

But no tight coupling.

PSRs to the rescue

And finally, follow coding conventions and read on PHP-FIG. The PHP Standards Recommendations (PSRs) will allow you to have a consistent codebase that others can easily understand and extend. The standards will help you to write code that can be compatible with other code written by others, and that will save you from cursing yourself 3 months after you write some bad PHP code.

This recommendation applies to every language in general. Follow coding conventions and strive to write better code. Of course, no one can stop you from being a "code-rebel". We don't have the technology to stop you from that yet.

(Yes we do, coding standards checks during integrations can keep idiots at bay)

A few concluding words

Yes, PHP sucks. So does every other language. You just gotta deal with it.

It's up to you and your team to write code that looks like poetry rather than an ugly war cry. You can write severely bad Java code even with its verbosity and static typing.

You were scared about starting your next project with PHP because your coworkers will judge? Go right ahead and do that. It's your job and it's your tool.

Your coworkers are probably too free, maybe their code is still compiling.

Technical debt

Dedipyaman Das — Thu, 26 Sep 2019 06:59:16 +0000

Software development is cursed with an implied cost at any stage, no matter how elegant your solution looks at any point of time. The cost of fixing what you messed up. Humans write code, and code is prone to ugliness. This piles up over time and dealing with it is a challenge every team faces many times in their lifetime.

While building any sensible system with code filling more than a page you start breaking things down to pieces, if you aren't you should. When you start abstracting things away into separate smaller modules, you start thinking about how to put them together. Oftentimes, you need to add one tiny feature and then one more, while trying to keep the initial structure you had in mind intact.

Although the idea was clear at the beginning, the pieces don't simply fit together as easily as you'd want them to be. So, you mess around the structure of the codebase a bit, just fine little harmless tweaks. As features accumulate, you start to see a big change that module's structure.

What starts off as a clean, well-structured module now became this horrible mess of hacky additions of features. At some point, you stop understanding what it was supposed to do, because it's doing too many things.

But it works.

So you leave it behind, put a checkbox in your TO-DO list and move on with the next module. Then days after, your requirements change and you need to modify that module once again. Or maybe you'd like to integrate it with some other module. The confusing module is now hard to read, understand and extend. Moving any further would be an impossible task with it.

You've two choices at this point-

Discard it entirely and start fresh
Fix it

Unless you're building your first application which doesn't do much, the first is usually not the best option. Especially in a project where you put significant amount of time thinking about and developing that module. It works, and it has some clever crafted code inside it, it's just turned messy.

Now you have to take a step and fix it.

This is Technical Debt. As in monetary debt, if you don't repay your dues early on, the interests will accumulate and push you into a hard-to-return-from point.

When you thought, "hey, this works for now, we can fix that later" you fell a little deeper into the debt trap. Technical debt is the additional cost you implicitly added to your project by choosing an easier path that you will have to pay for in the future.

Now what would have taken you 3 days of work, will take you about a week. It's the cost of fixing the code (paying off the debt) + the cost of implementing the new feature.

How do I prevent technical debt?

You don't. You can only minimize it. Think of it as a financial system, and do exactly what you'd do when you loan money off your bank. You pay the dues gradually. Once you are done implementing the first feature in your module, you take some extra time to remove that mess and make it saner.

Yes, you did put extra time into it, but it lessened the burden for the next feature and decreased the overall cost. This gradual removal of mess enables you to fix the parts of your code that needs the most modifications over time, and hence needs to be the cleanest.

Cleaning it off gradually over time will make sure the debt doesn't accumulate to the point of no return over time. And it helps you keep the internal code quality fresh at the points where you need it the most.

Recently, in a system I had used a factory to convert transfer objects to domain entities. It was initially meant to do just that, but I ended up validating the data and checking for redundancy from the persistence layer inside it. All within a factory. It was too smart at that point.

Eventually I kept using this factory in too many pieces, and adding more logic to make it smarter. I started having a hard time connecting the pieces together and that was a clear violation of SRP. I had to take a day off just to dumb the factory down to just be limited to creating the objects and not do too much.

Tight coupling is a major evil in a modular system and can often lead to code smell even in the most initially well thought out business logic. Coupling can end up contributing to the technical debt you accumulate over time, and you simply would be confused when something stops working in the cleaning up process.

When you start paying off the dues at a much later stage in a tightly coupled system, you find yourself breaking things even more than you'd do normally. At that point the paying off process becomes a nightmare and takes huge effort to fix.

Unpopular opinion: Don't fix something that works and you seldom change.

If your co-worker built a module that works perfectly fine and integrates just well enough for you to go on with - don't bother about fixing it if you don't modify it frequently enough. There's little reason to fix something that confusing and doesn't need fiddling with. If it meets your business requirements, leave it alone.

Finally, write more tests. Sometimes, we just need to add a quick fix, inject a hacky piece of code to make something work or to slightly change its behavior. What we don't see at the first glance are the side effects. We tend to look more at whether that quick fix solved the actual problem, and we miss out the side effects it brought along with it. Tests help out with that, you get instant feedback.

That's why I am an advocate of Test Driven Development. It gets you to move those sticky pieces long before you even are done implementing a feature, and hence reduce the cost. A slight cost added is the cost of writing those tests, but you would have to write them anyway.

Technical debt is inevitable in software development, and it will come around. And sometimes we need to trade off elegance for making things work, that being said, paying them off sooner will make your life a lot easier.