Every developer approaches their day to day development tasks from a different angle. In addition to this, each developer “designs” their code to suit their own personal preferences and approaches towards specifics in a project. When developers examine code written by other developers, we’re often critical (sometimes hyper-critical) of the code itself, mostly according to our personal preferences. While there is a place for being critical of code, and it should be encouraged, there are a few aspects of this criticism that should be left at the door… namely, the personal preferences.
While we all have our own preferences, it’s important to solidify a few areas when approaching code and to, ultimately, hone the developer’s mindset into certain guidelines. Below are a few thoughts I have running through my mind constantly while developing:
1. Minimize lookups.
This one is crucial when developing systems with heavy load. How many times are you hitting the database for information and how can you minimize that number? For example, when using the Transients API in WordPress, why would you run get_transient() again after you’ve just set the transient up? You’ve already got the data, so there’s no need.
2. D.R.Y (don’t repeat yourself).
This is a common development practice. Don’t repeat yourself. If you’ve got, for example, two functions that perform API requests, create a function that runs the API request with a few parameters to customise it in each case, rather than coding the request twice.
3. One function, one purpose.
This one helps me every day. It also ensures that your code is kept clean. If, for example, you have to display a collection of posts with specific criteria, why compile one function to do it all, when you could have a small function to get the data from the database and a second small function to output the data neatly? Surely that would make your code easier to read and maintain? Yep, it would. 🙂
4. Do I need this function here?
This one is about load and separation of code. Why load extra functions when you don’t need them in a specific context? Keeping this in mind ensures that you keep your code in “bite size chunks”, for example, splitting admin-related functions versus frontend functionality.
These items, while simple to adhere to, can alter the way a developer approaches a project, as well as creating a better end result. Most are also common development practices that most developers should be familiar with, making it easier for other developers to read and understand your projects.
Do you have any tips and tricks that help you day to day while developing?
Leave a Reply