Since I’ve been working in the PHP community, I have noticed how there are a lot of “How to become a better developer” talks and blog posts. Starting off with a little spoiler, there is no golden key to become the best. There are however a lot of good practices that will help you improve.
This year was the second time I attended PHPBenelux, and it once again became more obvious how the community is a huge part of the flexible language, PHP. Next to the newest and coolest tools, tricks and frameworks, personal development was a huge topic on the conferences I’ve attended. In this blogpost I’ll be writing about the learnings I took from those sessions and what information I gathered over the years.
Code complexity
Writing good code can’t be done right on the first try. It takes practice. Here are some tips on things you should keep in mind whilst writing new code, that will help you to improve the quality.
- Your code should be self-explanatory:
When reading back your code, you and your college should be able to know how your code works. Code that you may find very logical whilst you’re writing it might confuse a few weeks later (trust me on this one, I’ve been there). You can prevent this using explicit naming in your variable names, not having side effects in your as small as possible functions, and using PHPdoc to show what goes in a function, and what goes out. If you practice this, future you will thank you. - Code SOLID, not STUPID:
In case you haven’t heard of this one yet, try to code SOLID (Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, Dependency Inversion Principle), not STUPID (Singleton, Tight Coupling, Untestability, Premature Optimization, Indescriptive Naming, Duplication). Thank you William Durand for writing a great blog post on that! - Keep indentation as low as possible:
Most of the time when you use an if statement within an if statement, chances are that you can avoid that. Trying to avoid second level indentation will improve your code quality and readability. If you find yourself with second level indentation or even more, you should ask yourself the following; Shouldn’t this logic be abstracted to its own function? Can I make the code easier to understand if I would have returned early? Keeping this principle in mind will make you think more about what and the way you code, which will result in better code. - Try to avoid else:
Starting off, there’s nothing wrong with using else. But, if you would try to avoid it, you’ll find some interesting alternatives that will improve your code quality. This was a real eye opener for me. Often I’ve seen large portions of code within an else, which could have easily been avoided if you would have returned early in the function, if the values didn’t meet the expectations. I’ve written a small example here of it’s most basic use. But in essence, trying to avoid if will make you think more about what and the way you code, which will once again result in better code.
Don’t reinvent the wheel, compose
This might feel like an open door to most of the people who are already used to work with open source code and composer. But before you’re going to create a new product, you should check out what libraries are available to help you create what you need. For me personally I wanted to have control over everything and know every in and out of my code. But when I started to use libraries of others I figured that I saved a lot of time and effort. Time and effort that isn’t wasted in reinventing the wheel, but invested in the product itself. Need something? Search if it already exists, or could support what you want to do first.
Stop starting, and start finishing
This was an important lesson for me, but I think a lot of programmers have the same problem; we don’t tend to finish our personal projects. This because we have better insights every day. We look back at our week old code, and we already have ideas on how to improve that. The thing is, there should be a balance between refactoring and finishing your product. In most cases, good = good enough, and doesn’t have to be perfect.
User groups
If you never have, attend a local user group. Seriously. To keep growing as a developer, you need to see what’s happening around you and see what’s available today. Chances are that someone near you has written some cool libraries which would help you out. Or even help you with brainstorming/working on your project. If you’re up for it, maybe even give a talk?
Is there no user group near to you? Then maybe you should start one? Talk and discuss about code in a non-work setting. It will help you improve and make the PHP community even better.
Even though the points above will not directly make you the best developer, they should at least help you in becoming better every day.
