Programming 101: Raising the bar

There’s a lot of bad code about. We’ve all seen our fair share of it, and we frequently still do when we inherit projects from elsewhere.
By Sam Holman
18th February 2011

We work with a lot of PHP, which has quite a reputation for bodgy hacked together, frankly horrible code - not entirely undeservedly, but that’s not the fault of the language - at least not anymore. The really low barrier to entry is both a blessing and a curse, but it’s surely our mission, as members of the PHP community to help raise that bar in terms of the standard of output. Some of the worst code happens when it’s author(s) haven’t stopped to think and analyse.

Programming is all about problem solving.

Every project, big or small, is full of them. The first encountered is probably the justification for writing the piece of software in the first place - some business case, or perhaps it’s just for fun. Either way, you’ve decided to make something. So i’ll presume that you know what your goal is, but you’ll stumble across all sorts of issues getting there.
A problem is basically any small task, and at every point, if you don’t immediately know how to achieve it, you should ask yourself
“What’s the problem domain?” - It’s usually one of two things.
1. Generic
For example, “I need to send an HTML e-mail”
2. Application specific
ie. “How should i manage the interactions between these two particular objects in my app?”
If 1, start by looking into the specifications, RFCs, etc. You’ll come up with the best solution when fully clued up on the problem.
If 2, look up some design patterns and see if one fits. There's even some design pattern based posts on our blog in the dev section.
In either case, if the problem seems a simple one, implement the solution yourself. I’m not saying reinvent the wheel every time - there’s a reason that frameworks and libraries exist and it’s a great idea to use them, but if you don’t try things yourself then you’ll never really learn.
If you end up looking for example implementations on the net, don’t take anything at face value.

The first result on Google isn’t always (or usually) right.

Find a few examples and evaluate them. And never copy and paste any code without fully understanding it. Do your research, you owe it to yourself, and anyone else you might be working with.
If you’re really passionate about what you’re doing, and/or want to improve yourself or further your career, then there’s a few other points and questions to consider:
Always strive for quality
  • Is this my best work?
  • Is it secure?
  • Don’t trust anything, especially inputs (from anywhere)
  • Don’t make assumptions
Is there a better way of doing what i’m doing?
  • Clean, understandable code with clear execution paths
  • Maintainable
  • Self-documenting (but include comment blocks where appropriate)
“Just works” != “Works well”
  • Attention to detail
  • Spelling, get that right at least!
  • Code standards. (Consistent use of braces, casing, etc)
Just a few starting points. All basic stuff, and it’s really just about getting into a good mindset, to be focused on quality output. And if none of this has been new to you, try passing on your experience to those with less.
Ooh, and follow us on Twitter. ;-) Sam out.

Like this? Sign up to our newsletter for more!

Add your own comment

© 2014 Label Media
We are recruiting