5 Bad Habits of PHP Developers (and How to Break Them)

A few days ago, I came across this article on Medium: 5 Bad Habits of Absolutely Ineffective Programmers.

One of the author’s statements got my attention:

Indeed, bad habits can be so harmful they can turn a potentially very skilled developer into a mediocre one.

And this is very true in web development too, no matter if you are an experienced developer or if you just started learning PHP.

So, I asked myself:

What are the 5 worst PHP programming habits I’ve actually seen or experienced during my work? And how can you break them with easily and effectively?

Let’s find out…

#1: Using PHP Code Without Understanding What It Does

Admit it: you’ve done it at least once 😉

I certainly did (even more than once…)

It’s a common shortcut when we just want to make a web app work: just copy a code snippet that works, make a few changes here and there… and voilà.

I know, it’s tempting to just leave it at that.

But that’s a bad habit that you really should break. You should never mark an app as done unless you completely understand how it works.

How can you improve, fix or even debug a piece of code you don’t understand?

Breaking this habit is quite straightforward: 

before using a code snippet, be sure to understand every single line and to learn what every single function does.

It takes time, but it’s definitely worth it.

#2: “I’ll Fix This Later…”

Sometimes, you find out that a piece of code has a serious bug or a logic mistake that only get triggered in some cases.

Maybe that code doesn’t work under certain conditions or cannot handle some specific input, or maybe it has a security flaw.

It happens, right?

In these cases, you may be tempted to say: “Ok, I’ll Fix This Later…”

But you should never say that. Because, you know… we all know that’s not going to happen.

Here’s what will really happen:

As long as the bugged code is still around, you will be forced to write workarounds and temporary fixes anywhere in your app… until it will be too late to fix everything.

Eventually, you will just forget about the bug. Which is not good.

Of course, not every single bug needs to be fixed immediately.

But it’s important not to keep adding workarounds instead of eating the frog and fixing the code for good.

How do you break this habit?

The best thing to do would be to fix any issue right away, but I know that’s not always possible. In these cases, mark the bugged code with a tag (like the classic /* Bugfix */) and add a review process very soon in your schedule.

Very soon means either in 2-3 days (more than that will make you forget about the bug details!) or as soon as you finish your current job (which, again, should be over in no more than a couple of days).

#3: Not Writing Comments

Developers often do not write comments because commenting takes time.

However, while it’s true that writing comments takes some time, in the long run it actually saves you a lot of time.

Writing comments forces you to understand and review your code logic; a process that lets you catch potential bugs and mistakes right away. It’s like a pre-debug.

Comments are also strictly related to code reusability.

Reusing your own code can save you hours, days, even weeks of coding time.

But…

have you ever tried looking at the code you wrote months earlier? If it’s not commented, chances are you won’t understand very much about it.

This is why commenting is the key to code reuse.

Comments have many other benefits as well, including providing code references to other developers. 

Nonetheless, surprisingly few PHP programmers comment their code properly. And I admit it: I had this bad habit too.

But believe me: if you break this bad habit and start writing comments as you code, you will very soon benefit from it.

My #1 strategy to start using comments is this: write comments before writing code.

For example. You’re going to write a function? Start with the function comment, describing its purpose, its arguments and its return value; then, write the actual PHP code. 

#4: Underestimating Security

Web applications can be used by anyone over the Internet, including malicious users.

And every operation executed by web applications can potentially cause harm in some way.

A common example are SQL injections. DOS attacks and privilege escalation are other examples.

Too often, developers underestimate this risk, leaving their systems vulnerable to different kind of attacks.

The most common security errors I’ve seen are about input validation.

That is: checking, validating and sanitizing data from the request string (and other sources as well, including databases, local files and remote resources).

SQL injection attacks are also very common. In fact, they still were the #1 web security risk in 2017.

If you want to know how to properly use MySQL with PHP, this is the tutorial for you: How to use PHP with MySQL: the complete tutorial (with examples)

You can also learn how to properly save passwords here: PHP password hashing tutorial.

Underestimating security issues is, unfortunately, a very common bad habit of PHP developers.

To break this habit, ask yourself this question:

“Do I know exactly what happens when my application receives any possible combination of inputs? Am I 100% sure that everything will work fine and that my system will be safe, no matter how the app is used by remote clients?”

Your app will only be secure when your answer will be Yes.

If you want to know everything about PHP security and really improve your skills, you can enroll in my professional PHP Security course.

#5: Not Caring About Scalability

The last bad habit I have for you is ignoring scalability.

Which means: not caring about how well your application will behave when it will grow.

An app may work fine when dealing with 10 users, when fetching 10 items from a database or when serving JSON data to 10 remote clients.

But…

will it still work fine with 100, 1000, 10000 users? Will it still work fine when the database will contain 10000 items, or when the remote clients retrieving the JSON data will be 100 times more?

Will the database support that workload? Will the response time still be acceptable? And how much will the system memory consumption increase?

Now:

You don’t need to write 1000x scalable code right from the start.
Maybe your app won’t even need to scale that much.

However, it would be a mistake not to think about scalability at all.

In fact, a bad habit of many developers is to make applications that “just work” under the current circumstances, without asking themselves if their app will keep working fine in the future.

How do you break this habit?

Add a scalability test in your testing/debugging phase. Run your application using 10x, 100x or 1000x the dataset you used in the development phase, and see how it goes. This dataset can be a database set of items, the number of users, etc.

Look at some scalability metrics to check whether your app is still working file, including:

• loading time
• system memory consumption (this is how you can check a script’s memory usage)
• database footprint

Conclusion

In this post, you learned about 5 bad habits of PHP developers and the strategies to break them.

I have seen or even experienced myself these bad habits during my work, and I know they can cause a great deal of damage.

What about you?
Do you know of any other bad habit we should be aware of?

Share your thoughts in the comments!

P.s. If this post has been helpful to you, please spend a second of your time to share it… thanks!

Alex

The images used in this post are Designed by Freepik.