Writing code can be boring sometimes, whether you need some new features, but don’t like them or the process itself has somehow become tedious. You cannot focus and you are at a dead-end. The only thing you want is to get this thing working and finish it already. Sometimes what you need to get done is so simple that two lines in your theme’s functions.php file would probably do the trick, and the code for the header of a plugin alone is 10 lines. Why bother coding a plugin at all?
The usual excuses
We all have used any combination of these at any given moment:
“It’s just the two lines”
We develop large plugins or small pieces of code. For the small pieces, we just need to add them to the functions.php file. Pretty easy, why complicate?
Consider child themes, for instance. As you know, your functions.php file belongs to a specific theme, not your whole site. If someone updates it, your changes will be lost. If you are the only admin or developer and you have a good memory, you can probably risk it, but isn’t it just easier to not have to remember and have a plugin that you can activate and deactivate without having to touch anything else?
“I’m not going to reuse it”
The code is for this one specific client only. You’re not going to use it again. Never. Ever. You’re absolutely sure.
Right. The truth is that if you have a piece of code that is simple and useful, you are going to use it again. If you have spent a lot of time developing it, you’ll be proud of it and will end up using it again in your next project. Take a look at the examples below; they were all originally developed for a single use-case. Then they were transformed into plugins, and reused in many projects.
“I’m not going to use it in another language, no need to make it translatable”
When you are developing for clients, your main concern is their needs. At first, you think to yourself “my client is from Spain, and Spanish people only use stuff in Spanish, why bother?”, “I’ll do it in English only, anyone can use it” or even “I’m going to show off my geekiness, I’ll do it in Klingon”.
I myself have some plugins and code whose HTML on the frontend is in Spanish only. Despite it being very common, however, it doesn’t make it right. Internationalization looks difficult at first, even tricky. With little time, you will notice that it is actually quite easy and just another step in your development cycle. Your plugin will be translated by many and will gain a visibility that it wouldn’t have if you hard-coded its strings.
Plugin beats functions.php
I hope it has become clear that there are benefits in writing plugins instead of using disordered pieces of code. It’s not alway easy to remember in which project you used a piece of code that you need in the new one. If you have everything neatly packaged, it will be good for everyone – and great for you. Your first couple of plugins will be a bit messy and sometimes difficult to get to work. You’ll need to write clean, nicely indented code and prepare a header for your plugin, but the Codex makes it easy to get started. You could even use another plugin’s code to start your own.
Community
When you write code, you have a community of developers that can help you. If you are working with php there’s php.net to solve your questions, for instance, or even Stack Overflow. If you share your code in public repositories such as GitHub, people can see it, fork it and help you improve it.
Keep in mind that you are coding PHP, a programming language that has one of the biggest developer communities. You are coding for WordPress, too, not only for you, but for the whole community. If you need to write a plugin about anything, you will probably find a plugin that can help you get started, in the repository. They share, you share, all under the GPL. This why you are never alone in your corner, churning out code; there are literally thousands of developers ready to help. Really. Just take a look at these archives.
When writing code for WordPress, here are your best resources:
- The WordPress Codex. It’s not complete and lacks information on the newest functions, but it’s still the perfect starting point for everyone.
- The Plugins directory —If you are going to develop something, look for a similar plugin and improve it to satisfy your needs.
- The IRC channels — There are a few IRC channels where other developers can help you with more exotic your issues.
- The forums — Where you can talk about code 😉
- The mailing lists — Some of them are very active and can become addictive. Use at your own risk!
Security
One of the greatest features of Free Software and Open Source is security, i.e. if you are the only one using a particular piece of code, you could have a security problem and not realize it until it’s too late. However, if your code is being used by many, they can help you in finding issues (and trust me, they will), much in the same way you sometimes find issues in their code. Also, if you are going to release your code to the world, there is a greater probability that you’ll look at it twice, before releasing.
Acknowledgement & Reputation
When a client of yours has a problem that can be solved with software, your job is usually to help him identify the problem and look for the right solution. If the solution doesn’t exist already, you will probably develop it for your client. What just happened? Your client is paying the time you need to code the solution. The code itself, however, should be free as it is itself based on Free Software. Why? Because everybody wins. The whole community will see and possibly use your code. It will notice, if you have included the information on the plugin’s credits, that your client is using it, that they’ve helped in its development. Because you are offering it back to the community that helped you to learn and develop it, they can improve it, helping you and your client to reach an even better solution. And finally, because it looks good on your portfolio. Good karma all-around.
The three R’s
You already know the three R’s. They are not only for glass and plastics. You can use them for software, too.
Reduce
Always reduce your code. Optimize it. If you are going to publish it, try to reduce the code, and make it as simple as possible. If you don’t do it, someone will do for you. In my first commit to WordPress core I made a 20+ line snippet of code to solve an issue. Two days later, filosofo changed it to a 7-line patch, covering all the possible issues, and not only mine. This is how community collaboration works ;).
Reuse
If you are going to reuse a piece of code, the best way to do it is to have your plugin in the WordPress repository. You will then only need to access your plugins’ area, search for yours, install and activate it. There’s is a double benefit in this, of course; if you improve or change your code, you can easily update it in all your installations.
Recycle
Yes, recycle. It’s Free Software. Use other people’s work as a starting point for your own. Take pieces of code. Read them. Learn from them. And please, always acknowledge the work of others. They will acknowledge yours :).
How do you see it? Is there a compelling reason to not use a plugin and add your code to functions.php instead? Let me know in the comments, below.