To celebrate National Coding Week, we chatted to the development team at Code Enigma who shared some of their favourite coding tips.
Don’t crystal ball. In other words don’t try and guess every possible improvement your client might need. If you prefer that as an acronym, YAGNI (you aren’t going to need it).
Build the simplest thing that works or if you prefer an acronym KISS (Keep It Simple, Stupid!)
Use commenting to your advantage. You might know what something is for now, but you might not later. There is no need to comment the obvious, your code should be clear and readable anyway, but - by way of an example - if you load a variable by calling a method, it might benefit you and your future colleagues to comment what it is and why you’re calling it, just to save future head-scratching! Similarly, you should always put a coherent documentation block above any methods and functions stating:
-
what it does
-
why it does it
-
what inputs it accepts (including type and if they are optional!)
-
what outputs it returns (again, including type)
A good example of this is the Javadoc format, which is quite widely used:
Follow a standard for code formatting (things like indentation, comment format, line lengths, etc.) - many programming languages will work without proper standards applied (some will not, for example, Python enforces coding standards and gives you an error message if your code does not conform) but it is very important for the readability of code. Many projects or languages have accepted standards. Find out what they are and apply them. Here are Drupal’s coding standards, by way of an example.
Always look for ways to make your code reusable. For example, if you find yourself writing something more than once in different places, it should be a function or a method. Pull it out of your inline code and make it a function or method you can call when you need. Reuse it.
Break the problem down into small pieces and solve each piece in turn.
Really give thought to what you call things, avoid obscure names for things!
It has been said that code is read many more times that it is written, so code for readability.
Test first - red, green, refactor.
Use (small, single-purpose) libraries.
Keep things as simple, short and single-purposed as you can. It doesn’t have to be pure functional programming or getting to hang up on principles, just follow simple rules like: any function/method that spans more than a dozen lines should be split.
Don’t forget to eat, drink and sleep. At least once a month as a minimum.
Try to think defensively. Things will break. Once again, you don’t always have to actually program each and everything defensively (in fact, you might want to avoid in order to ‘fail early’ in some cases), but to ask yourself the question: what should (or not) happen if I’m being passed unexpected data or a query endpoints fails to answer.
Related, make sure you do verbose logging - and make sure it’s simple to turn the verbose logging off! Wherever information may be pertinent, log it somewhere so you can review it if something goes wrong. The more you log, the easier debugging will be. Though you should also only log to a detailed level if you’re in a “development” mode and bug-hunting, so having a variable to quickly disable verbose logging is also important. There are many examples of patterns like this. Here’s one - note especially the setLogLevelThreshold($logLevelThreshold) functionality, so you can set the “importance” of a message you’re logging and then easily reduce the level of logging by changing the threshold: https://github.com/katzgrau/KLogger/blob/master/src/Logger.php
Find an IDE that you like working in and it helps you be productive. Here are a few of the most common in the Open Source World.
- PHPStorm
- Atom
- Eclipse
- Sublime Text
- Netbeans
- Vim
- Emacs
- Nano
Figure out how to use debugging tools: xdebug, Chrome inspector tools, etc.
Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live. Code for readability.
Learn one programming language well before trying to learn another. Don’t get too caught up on trying all of them, there’s a fair few!
Don’t be shy - join online and actual communities. Ask questions and don’t be scared about seeming stupid.
When you can answer a question, contribute your knowledge back. If people then ask you silly questions, don’t give a rude reply; you were once just as ignorant as them.
Keep your code always in repositories (eg: github, bitbucket) and try to use branches for each task. Moreover, you should use descriptive comments in your commits. It will be easier if you have to rollback to previous commits.
If you get stuck trying to implement something, try explaining the problem to someone else. Very often, this helps a solution to pop up in your head!
Don’t get held back by imposter syndrome; even development rock stars feel it.