Little Coding Habits

Want to help support this blog? Try out Oh Dear, the best all-in-one monitoring tool for your entire website, co-founded by me (the guy that wrote this blogpost). Start with a 10-day trial, no strings attached.

We offer uptime monitoring, SSL checks, broken links checking, performance & cronjob monitoring, branded status pages & so much more. Try us out today!

Profile image of Mattias Geniar

Mattias Geniar, September 24, 2008

Follow me on Twitter as @mattiasgeniar

Every programmer has his method of doing things, his own set of rules he follows. Here are a few small things I do, syntax-wise. I’m curious to see what you do, and how often you change other people’s code so it reflects your own syntax.

The following examples all do the same thing – but they’re displayed slightly different. Some even have a slight performance advantage.

Brackets – A

Brackets – B

Brackets – C

Brackets – D

Here, I prefer method B – I nearly always include brackets. It helps keep code organized for me. The last method (D) is one I try to avoid as much as possible – it works just fine, but when you’re quickly browsing over code to find something, you’ll often miss statements spelled out like that.

There’s a small speed-advantage when using the syntax without the brackets, but I feel it doesn’t add enough to remove the (re-)usability of my code.

How you write and display your SQL code, also differs greatly from coder to coder.

SQL Code – A

SQL Code – B

Both methods do the same, but I prefer the first one – where you visually space out your SQL statements. The example is a very short one, but this becomes more important when you start nesting & union-joining several tables. It’ll keep your query organized, and makes for easy changes afterwards.

Of course, when you just do a “SELECT * FROM table”, there’s no need to do anything fancy – it’s a simple statement, treat it like one.

This actually leads to the next thing – basic indenting in your code. I’ve seen horrible cases to debug, like these.

Indenting – A

Indenting – A

It’s obviously easier to interpret method B – yet so many don’t use indenting to space it out, and present their code. How can you maintain anything like that? What if you need to make changes later on, you’ll loose a lot of precious time decyphering/re-indenting your code first …

It’s a lot more readable to type:

$subtotal += $b + ($b - (round($b / 2)));

than it is to type

$subtotal+=$b+($b-(round($b/2)));

Add the necessary space in your algorythms.

Those are the things I often change in other people’s code, just to make it more readable to understand it better. It takes far less time to digg into a lot of code when it’s organized and displayed propery, than it is to start nesting your way through a series of characters that, at first sight, make no sense at all.

What are the things that annoy you? Any specific things you do to keep your code clean & fun to play around in?



Want to subscribe to the cron.weekly newsletter?

I write a weekly-ish newsletter on Linux, open source & webdevelopment called cron.weekly.

It features the latest news, guides & tutorials and new open source projects. You can sign up via email below.

No spam. Just some good, practical Linux & open source content.