
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:
The difference between a good programmer and a bad one is not necessarily coding skill. In fact, it is something even more basic; bad habits.
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.
Excellent post and you hit the mark with points 2 and 3. I would come across a problem that I set aside to “come back to later”. What happened is I finished another part of the project and was so happy to be (what I thought) finished that I completely forgot about the original problem.
Comments. Yes. Comments are critical, especially to beginners and folks working on multiple projects. It is so easy to forget what a complex block of code does (complex in the eyes of the beholder). I mean, this is your code and you can’t remember what it’s doing.
You’re cooking with gas in these posts. Keep up the great work.
Thank you!
Hi Alex!
Thanks for making out time to give out these awesome tips FOR FREE; I really appreciate.
… Hhhhhhmmmmmmm, I am guilty of four (4) of those aforementioned bad habits. I’m making serious adjustments in my codes and coding skills henceforth.
Once again, thanks for sharing!
Thank you for your feedback, Tino.
Thank you so much for this awesome tips Alex! I’m sharing ASAP to my local FB Dev community!!
Thanks Vic, I appreciate it!
This is a great post. Thank you Alex for this !
Thank you 🙂
Thank you very much Alex, As always sharing the best of PHP
Thank you Hector
Thanx for the wonderful post, Alex. I am working on my latest blog. Learned a lot from your piece.
Always happy to help.
I think lack of comments is not a bad habit. It depends. Code should be broken down to smaller pieces that are self explanatory.
Variable, method and class names should be logical and in charge of one thing only. I think that more than the lack of comments, lack of separation of logic is a bad habit. Cramming everything in one class.
Sure, comments on parts with heavy logic or where something really specific happens. But I prefer clear and logic method names that do only what they are supposed to do.
Great article!
Very interesting, thank you for sharing!
THANK YOU, THANK YOU, THANK YOU.
Being a NEWBIE the very first bad habit mentioned hit me right in the face. I will now begin to make sure that I understand each and every line and what every function is doing.
The second bad habit that really got to me is writing comments. I can’t write good comments if I don’t understand everything the snippet is actually doing.
That’s the way to go, Ted 🙂
I appreciate to blogger for wonderful post. will definitelyshare this blog to my group.
Bad habits are hard to break and even harder if you don’t realize that what you’re doing is undermining your work. If you know but don’t care—that would be the worst. But you’re here, aren’t you?
Good point. 🙂
Thank you sir, about scaling web apps does it’s depends on the database coding or something else bcux most posts av come across keeps relying the web app scaling on database architecture or something can u please brief me about this issue
Both the database design and the PHP code play a role in scalability.
Optimizing the database design is a complex topic. It’s about choosing the proper table indexes, query optimization, views, and so on.
PHP code optimization is somehow easier. Avoid creating loops with huge memory consumption, slow operations (especially on big arrays or large strings) and try implementing efficient algorithms when possible.
The most challenging bad habits now is TDD (Test Driven Development). Since we just write (amazing) code and never test using Unit test cases. As a developer we only consider the working part of the code and never think of any failure at run time.
It’s better we should start practice for writing PHP unit test cases for each piece of code we write.
Yes, test-driven development is by far the safest and most secure programming paradigm.
Being relatively difficult and time demanding it’s not used often in web development, but I agree with you that it would lead to much higher quality code.
Thanks for sharing your thoughts.
I have some questions for an application involving multiple classes and scripts.
1. Files. I’ve historically defined file paths at the start of each script. Now I’m thinking I should have one class that defines every file path that everything in the app uses. ??
2. Error checking. Should every method ensure the validity of all its input every time?
Seems really repetitious. ??
3. When do you rely on built-in functions throwing exceptions, like PDO or file_put_contents, and when do you write your own exception handlers. ??
Hi John,
About files: if you have many classes or “inc” files you always include, then it’s definitely a good idea to create a single script with all the include (or, better, require) statements. Better use absolute paths (__DIR__ is very helpful for that).
About validity checks: it depends on your app workflow. Functions dealing with untrusted data must always validate their input; on the other hand, functions dealing with already validated data can safely avoid that step.
I suggest you write specific validation functions and use them for input validation every time is necessary.
About exceptions: if you are ok with the error details provided with build-in exceptions, it’s ok to use them. User-defined exceptions are useful when you need to pass more information about the error to the caller, or when you want every exception to use a user-defined Exception-inherited class.
Great article. Thank you for it!
I really like the advice about writing comments – first comments, then code. I usually do it in the opposite order.
I usually have one more issue that lowers my productivity: Watching YouTube videos while programming. Especially those with words or clips. I sometimes want to look at it just for a second, but then, five minutes later I realize I am watching it for quite some time.
But on the other hand, there are videos on YouTube that help me concentrate, not only when I programme, but also when I learn something for school. Those are usually songs without video and words, the only melody. One of my favourites is Kurzgesagt soundtrack.
Thanks for your comment, Jan!
I suggest you avoid distractions while working. It’s perfectly fine to listen to some music (as you said, just music without words) which often helps concentration, but shifting focus from your work (such as programming) to other things like YouTube, social media and so on, is a productivity killer.
The best thing is to do only one thing for a slice of time (30 minutes, 1 hour, 2 hours…) and do just that, without interruptions of any kind.
Look into “Deep Work” by Cal Newport, it’s a amazing book on this topic.