Better programming

Advertisemen

Reading through www.wildbunny.co.uk/blog/2012/11/01/10-steps-to-becoming-a-better-programmer/ got me thinking about what I do right/wrong when programming.

1. Never ever duplicate code

I think this a bad habit which a lot of newcomers learn because they realise how to make the most out of loops and functions. But since they've become accustomed to doing so, it's hard for them to stop. I know it took me a while. Since using an object orientated paradigm over summer, I've become quite nifty about refactoring duplicate code. I haven't used a procedural language much for a while so I don't know well I could apply it to that, but that will be a stepping stone to take when I next use (most likely) C.

2. Notice when you start distracting yourself

This is quite a general statement and probably applies to anything desk-based. We all procrastinate, I doubt there is anyone in the world who doesn't procrastinate. Sometimes procrastination is good, it's a break from coding and allows you to organise your thoughts a bit better. But the checking social networks every five minutes is a pain in the ass. One I need to stop. I might download some software to block facebook/reddit/4chan during the day over the weekend so I can actually focus on doing some coursework - it's just write-ups left, and they are immensely boring!

3. Don't rush the solution out the door

more to industry work, but if I just apply this to University projects, I tend to be pretty good at not rushing as I try to do the majority of coursework the week I receive it, even if it's due 5 weeks later. This methodology has meant I have never had to pull an all-nighter! Never even been close to pulling one! (It does amuse me when people pull all-nighters, how hard is it to stay organised?!?!)

4. Test your finished code

Let's just say I'm good at handling bad data (null values etc), but full on unit testing. I wouldn't even know how to go about that!

5. Code review

Since I don't have anyone to code with, I usually review it myself. Which means once I've done a module, go through it refactoring and adding proper comments to it.

6. Write less code

There's an equilibrium here, you don't want to write too little code and you don't want to write too much. Usually I make the code into an adequate number of lines (in my opinion) during my refactoring process - get it to work first.

7. Strive for elegant code

This is one that I've been practising a lot lately, it's a nice accomplishment to have your code working and looking pretty at the same time. Since I've been using higher level languages (C# and Java) lately, it makes it hard for me to stomach looking at C++. C is fine. But C++ looks like an ugly beast, even though I'm much more proficient in C++ than C.

8. Write self documenting code

For me, this point should be merged with striving for elegant code and code review. Code that is readable with useful function/variable names.

9. Don't use magic constants

See above.

10. Don't do manual labour

I once wrote a Java program to manually download around 3000 images for me, just by passing the URLs as they were in a consistent format. Saved me so much time.

11. Avoid premature organisation

Make sure the code works first!

Advertisemen