[/caption]In this article, we're looking at some more principles that can be very helpful when you're writing computer code. These are themes that underpin everything you do as a programmer and can make a huge difference to the quality of code you produce and the time it takes you do so!
Don't Repeat Yourself (DRY)
The concept here is that anything you use in your code should have a single, unambiguous representation. This means if you are storing a number, only store it in a single place (don't have PI stored in three different places). Not only is multiple storage wasteful, but it multiplies your effort if you want to change, especially if you have to go hunting through several files to find where the numbers are defined. Multiple representations are also a great way to generate bugs if you forget to change some of them. This also applies to code; don't repeat chunks of code that do the same thing - have a single version and put it in a function.
Keep It Simple, Stupid!
The simpler your code is, the easier it is to construct and maintain. So, subject to the constraints of our objectives, the simpler you can make your code the better. This has a connection to premature optimisation (see this post ), because optimised code tends to be less simple. We think a reasonable rule-of-thumb is that unless most simple way of doing something will be obviously too inefficient, it's worth trying. you can always change it later and, because it's simple code, this shouldn't be too hard. One way to describe this is to paraphrase Albert Einstein: Code should be as simple as possible, but no simpler.
Tidy up after yourself
Once you start to leave one or two things unfixed, it becomes much easier to leave "just one more", and soon your code is a wreck. There should not be a single "broken window" in the code you're building (the phrase "broken window" comes from a study that showed that a major indicator of the state of a building was a single broken window; once one is broken, people care a lot less about maintaining the rest, it seems). The book "The Pragmatic Programmer" has a nice description of this.
Learn new tools
If all you have is a hammer, then all your problems tend to look like nails. The way to avoid this is to have more than one tool. In general, you want to have a good, broad selection of tools with which to write your code. A good way to acquire this is to try to learn the occasional new tool as you go along. These can be useful pieces of software, new techniques or whatever; the important thing is that it gives you at least one more good option for writing your code.
Maintain your flow
Flow is a psychological state that you get into when you're absorbed in your work (sportsmen call it being "in the zone"). Have you ever gotten really into your work, so much so that suddenly an hour has passed without you noticing? That's flow! In this state, you tend to be very productive and very focused on the task at hand. Therefore, you want to try to stay in this state for as much of the time as possible. It can take as much as 15 minutes to get into the flow, so it's important to minimise things that will pull you out of the flow (once you're out, that's 15 minutes largely wasted). That means try to avoid distractions, turn off the e-mail alert beep, listen to music to block out background noise, turn off your web browser. Whatever it takes!
Make your code unsurprising
When someone glances at a chunk of code, they can often form a quick impression of what that chunk of code does. It is convenient when this impression is accurate; it can be a real problem if the impression is misleading and they makes changes to the code before they realise. The ‘principle of least surprise' is that you should try to make your code's actual functionality as close as possible to the typical quick impression. Or, to put it another way, you should try to write your code so that it communicates its functionality accurately in a very short (pain-free) amount of time. This means doing things like picking informative variable/function names, writing informative (and succinct) comments, and making the layout easy to read.
Don't program by coincidence
'Programming by coincidence' is what happens when you "just get started coding" without thinking about what it is you actually want to achieve. You write some code and it seems to work. Great. So you write some more. That also seems to works. So you keep on doing this until one day you add some code and your software falls over. And you have no idea why. Think of this as the coding equivalent of a random walk; sure, you're moving, but are you going to end up in the right place? To avoid this, realise that a bit of planning and careful thought (including as the project progresses) is a very good thing.
Code entropy
Disordered code is bad, because it's more likely to contain bugs. Being scientists, we tend to think about this in terms of the entropy level of our code. Higher entropy is more disordered which is bad. So you should try to keep the entropy of your code as low as possible. This means taking care to keep things neat and tidy as you write the code. It also means fixing bugs and refactoring messy bits of code. One important aspect of code entropy is that any time you make a change to your code, the level of entropy will tend to increase (unless you're very careful; fixing a bug, for example). If you're constantly re-writing your code, you'll be introducing new bugs all the time and invalidating the testing you've done on that code. So bear in mind that a bit of stability in your code is a good thing.
None of these principles are vital for developing good software, but some are pretty close! Find the ones that suit the way you work and try to adopt them. We think you'll really notice the difference!
No comments:
Post a Comment