The 10 habits of highly e ective coders
Being a great coder isn’t always about what you know. Darren Yates looks at 10 habits that will improve your coding — whatever language you use.
Over the last couple of years, we’ve been systematically working our way through the nuts and bolts of the Java programming language, covering everything from variables to methods, inheritance to classes, threads to networking.
But while understanding how all of these techniques work is important, there are key lessons worth learning regardless of which programming language you take on. Everyone has different ideas on what makes a good coding habit, so we’ve come up with ten common tips handed out to coding beginners to get you going in the right direction. You don’t have to agree with them, but they should get you thinking about how you write your code, not only for yourself, but for others to read and understand.
WHITEBOARD BEFORE KEYBOARD
Imagine you’ve been given a coding problem to solve. What’s the first thing you do — head to the whiteboard or head to the keyboard? In almost any problem, the last step you should do is the coding. There’s actually a whole stream of study you can do called ‘Systems Analysis and Design’ that covers this problem defining and solving process. The first step (the ‘analysis’ bit) is working out the problem, understanding the needs of stakeholders and what the solution needs to do.
From a technical perspective, you need to understand the scope of the problem, understand any assumptions and error conditions you need to cover and what it will look like from the user’s perspective. Once you’ve got that far, then you consider what the solution might look like (the ‘design’ bit). This often involves, again, consulting with stakeholders — the people who’ll use your code — about what they need and want and how it will all work. When you’ve done all that, that’s when you start coding.
When you’ve got code, you have to test it against your assumptions and error conditions, debugging any logic errors that turn up. Once it has been tested and meets all requirements, you get to deploy it.
Even if you’re not writing code for a big corporation, the simple step of planning how your solution will work could save you huge amounts of time running around looking for unexpected errors later.
...BUT STILL CODE OFTEN
Now all that said, don’t let that stop you from practising your skills. Coding is something you only get good at by doing it often. If you study for a university degree, lecturers will (hopefully) always tell you that it’s much better to do a bit of study or practise each day, than try and cram everything into the last weekend before the exam. Why? Because your brain recalls processes better through repetition. Coding should be the same thing. Researchers say it takes about 10,000 hours to master an activity, so the more time you spend coding, the better you get at it.
You should still plan out your solution to any problem, even if you just nut out a rough idea in ‘pseudocode’, plain-language code that walks you through what you want to do. But practising your coding, learning new skills, putting them into practice are the best ways to conquer coding. It’s not unusual if you’re a newbie to stare at a problem for a while, not quite knowing where to start and not wanting to make a mistake. Sometimes, you just have to start.
Of course, you’ll make mistakes — we all do, but mistakes are not the end of the world. On the contrary, you generally learn far more from your mistakes than you do by getting it right the first time.
USE HUMAN-FRIENDLY VARIABLE NAMES
At the beginning, it can be extremely tempting to just use simple variable names like ‘x’ and ‘y’. They’re quick and easy and take few keystrokes. But what happens when you come back to your code later on, there are 5,000 lines of it and you have to try and figure out what ‘x’ does, or worse, figure out where the bug is.
This is why you should be somewhat verbose when it comes to variable names, method names and class names. For example, a method called ‘calcIR’ may mean something to you at the time if you know what ‘IR’ is, but ‘calculate Interest Rate’ makes it bleedingly obvious. But so as to not make code lines too long, I try and aim
to limit names to no more than three words. Think about what the method or variable aims to do or store and write it down in three words. If it takes more than three words, chances are you might be trying to do too much and it could be worth splitting up that function. That’s my take on it, but certainly, human-friendly variable and method names, in general, are a must. It may not be you who has to tweak your code at some point in the future and anyone who does will thank you for using human-friendly naming.
Use consistent naming conventions too, like camelCase for variables and methods and first-word capitalising names for classes — it’ll make it much easier to follow the code later on.
INDENT YOUR CODE
All modern languages use code-block functions such as loops, if-statements and methods — functions that allow you to divide your code into manageable chunks or ‘ blocks’. But one way to make these functions far less workable is to muck up your indents. Unless you’re working with Python, most languages don’t require you to indent your code. But really, you’re nuts if you don’t. Most integrated development environments (IDEs) take care of this for you and automatically indent your code correctly. You should even be able set the length of the indent in the IDE options area.
The most important thing is to be consistent, especially when you have nested methods or statements. Consider a method with a for-loop and an if-statement inside the for-loop. Having those indented correctly means you’ll be able to fly through that code and understand what’s going on in an instant. It means having braces (the curly brackets that group code statements together) aligned so you can quickly see where code blocks start and finish.
Again, if you’re working in a group, you need to just agree on the tab length, so everyone is on the same page. Two to four spaces is common — just pick one size and stick with it.
COMMENT YOUR CODE
Agile is a popular software development paradigm that aims, above all else, to be time-efficient. One of its most popular mantras is ‘working software over comprehensive documentation’ — the idea is to build working code rather than spend inordinate amounts of time creating letter-perfect documentation. It doesn’t mean you ignore documenting your code completely, but you need to balance what you code and how you document it.
One of the simplest ways of documenting is commenting your code. All programming languages offer in-line code commenting (Java has three different options). You don’t have to write a novel, but comments at the start of a class or a method at least will go a long way to quickly understanding what that code does. And if you’re already using human-friendly method and variable names, along with consistent indenting, your code will be neat and everyone will love you for it.
BE A LAZY CODER
By ‘lazy’, we don’t mean leave it for everyone else to do, we mean don’t have duplicate code. If you’ve been following our coding series for a while, you should be well aware of methods and classes. Make good use of them. Every time you code something, the chances are stacking up that you’ll code a mistake. Code the same thing twice and you may as well put out an open invitation on Facebook for errors to turn up — not just wrong-spelling or ‘syntax’ errors, but logic errors, the type that are much harder to find. That’s why you should always code once. If you need that code to run more than once, at least make it a method you can re-use within your class.
Code duplication will typically occur if you haven’t fully planned out your code beforehand and you’re coding on the fly. So again, it’s important to plan before you code — it’ll save you time and stress later on.
WRITE CLEAN CODE
Consistent indenting, human-friendly variable names, commenting your code — they’re all ways of helping you write clean code. Another one is don’t have long lines of code. A simple rule of thumb is if your code line goes off the screen (or is longer than 80 characters), you either need to shorten the code or simply wrap the bit you can’t see onto the next line. Languages like Java and C# allow this because the end of a code statement isn’t a carriage-return but the semi-colon.
“It may not be you who has to tweak your code at some point in the future and anyone who does will thank you for using human-friendly naming.”
Clean code is code that’s easy to comprehend, but it’s more than just making it pretty to look at and nice to read. You could come up with a supershort, elegant solution to a problem, but the logic might be too convoluted to take in quickly. That will mean you take longer to understand how the code works. With tight deadlines, it may well be better to use common syntax and coding methods to make the code easier to understand.
AVOID THE USE OF MAGIC
Coding might seem a bit of a dark art at times, but really, it just follows logical processes. That said, you’ll probably come across potions of magic in your own code, the most common being ‘magic numbers’. These are integer or floating-point literals that appear in the middle of your source code with no reference to what they mean. For example, you’ve creating a for-loop and the end value is ‘54’ – what does the ‘54’ refer to? That’s a bug waiting to happen. Instead, assign constants at the top of your class or method and use those throughout your code as necessary. This way, if that value needs to change, you change it in the one place, rather than have to follow the code logic to find out where else you’ve used that ‘magic number’.
BE KIND TO FELLOW CODERS No coder is perfect, no coder knows everything, there are always coders who know more than you do and coders who know less than you do. Stay humble and ask questions — that’s the only way you’ll ever learn.
In a very real sense, coding is as much a creative art as it is a science, which means everyone is going to have a different take on how something could be done. That’s why if you’re working in a team and it’s important to have certain standards or conventions in your code, agree on those things at the start. But also be open to different ideas and ways of doing things.
If you need to criticise code, do it rarely, do it privately and if I can
borrow a sporting analogy, play the ball, not the person. If you look at job ads for software engineers at Google, the search giant always wants people who will stand up for their ideas, but it won’t be to the extent of pulling everyone else down around you. These are often the very same people you’ll learn most from.
DON’T BE A ONE-HIT WONDER
Don’t make the mistake that there is one programming language to rule them all and if you know that language, you’re set for life. As many people before me have said, the only constant is change and it’s so true of coding. That’s why it’s not only important to be exceptionally competent at your chosen language, but to also be aware of and at least conversant in a few others.
Different languages have different strengths — for example, Java gets you Android, while Python is popular in Data Science. Depending on the coding task required, your favourite language might work, but there could be an alternative language that already has all the tools ready to go, saving you reinventing the wheel.
Personally, I love Python’s ability to return multiple values from a method and I love that it has libraries available for doing Data Science from scratch. For building Windows apps, C# is a no-brainer, while the open-source ecosystem for Java is just massive.
There is always the argument about specialising in one language versus being a ‘jack of all trades, master of none’, but locking yourself into one language in a world of constant change probably won’t bode well for the future.