Thank you for visiting!

Please consider subscribing to the RSS feed or following me on Twitter.

Archive for Rules of programming:

Rules of Programming: Always Backup Your Code

Backups. We know we should have them, yet they're not always there.

What happens if the code you're working on right now is gone by tomorrow? Do you have to rewrite every single line of it? Do you use version control software and do you trust it? (Possible eye opener: Version control will help you but it will not be the sole answer to your problems.)

Use backup tools. Backup, backup, backup. Storage is cheap. Your hourly rate is probably not.

Rule #24 of programming:

Always backup your code

Rules of Programming: Know Your Restrictions

Having self-knowledge is good. Doing something good with that knowledge is even better. And harder.

If you know your restrictions, don't neglect them. Instead, try to improve.

Also: the best team work rarely comes from a group with the best developers. The best team work often comes from a group of different developers with different areas of expertise, where the developers complete each other. In such teams, the outcome will be better and the co-workers in the team will improve their skills even more.

Rule #23 of programming:

Know your restrictions

Rules of Programming: Code For Performance

This is quite an important one. Code with performance in mind. This will probably save yourself some time and your customer both time and money.

However, don't optimize code too soon. It's pretty useful to optimize code afterwards, when you know the code is working.

Also worth keeping in mind: It can be smart to spend some serious bucks on better hardware instead of pushing man hours into optimizing code. The latter may come at a higher cost.

Most important thing though is to always code with performance in mind.

Rule #22 of Programming:

Code for performance

Rules of Programming: Use Checklists

It can be a bit hard sometimes to keep a track on everything you have to do when programming. Enter checklists.

Checklists will aid you and help you understand what has been done and what is left to be done.

Checklists that are particularly useful:

Here are a few more useful checklists.

Rule #21 of programming:

Use checklists

Rules of Programming: Learn From Your Mistakes

It's ok to do mistakes, as long as you learn from your mistakes. Speak to other developers to learn about their mistakes. That way, you hopefully don't have to repeat those mistakes.

Forums and Q&A sites like stackoverflow are great aid here. Going back to some of your previous projects might help you too.

Rule #20 of programming:

Learn from your mistakes

Rules of Programming: Keep Focus

Being in the zone and having a good flow when programming, is more of an exception, rather than a rule. However, you can change that by minimizing the number of distractions.

Kill your email and your Twitter client for a while. Use headphones, everybody will see you're busy.

The better your flow is, the better your code will be.

Rule #19 of programming:

Keep Focus

Rules of Programming: Use Logging To Improve Quality

I've told before that we should handle exceptions first and use logging tools such as log4net and elmah. It's very true.

Using logging not only gives you great control of what exceptions actually occur, but also give you clues on what you can take a further look at and improve. I've seen way too many try catch statements with empty catch blocks. It might be a good idea posting to a logger instead.

A logger will definitely help you. Use it.

Rule #18 of programming:

Use logging to improve quality

Rules of Programming: Be Open To Change

As important it is to leave your code open to change, as important is it that you are open to change. In our world, changed requirements are very common, thus, we as developers, need to adapt.

The dream for any developer would be to have a full specification and start planning and programming from there. However that's very rarely the case. Customers change their minds, you come up with new and great ideas, and so on. It surely can be a pain with these changed requirements, but it's probably for the better good.

If we can't beat them, join them. We have to be open minded and welcome changes.

Rule #17 of programming:

Be open to change

Change, the Optimus Prime way

Rules of Programming: Always Validate Input Data!

This one is often forgotten, yet it's one of the most important and fundamental corner stones in programming.

Validating (user) input data is a must. Always assume the input you deal with can make bad things.

What you should think of:

  • Character encoding
  • Encoding and validating HTML data
  • Verifying e-mail addresses and passwords
  • Security risks like Cross-site scripting

Code for bad input first - good input last. You'll help yourself!

Rule #17 of programming:

Always validate input data!

Rules of Programming: Leave Your Code Open To Change

To be open is a good thing. To leave code open to change is a better thing.

It should be easy to extend existing functionality, without breaking it.

It is trickier than it sounds though. But don't be scared!

To write code that is open to change, you should basically make it possible to inherit and override existing classes and methods. This way you don't have to think of broken functionality, you don't have to deal with re-writing tests for the existing code - since you've not touched the existing code. It'll make it easier to focus at your new code and your new tests. Full of win!

Rule #15 of programming:

Leave your code open to change

Rules of Programming: Be Serious About Testing

Writing code without testing it? Don't use unit testing with your apps? You really should!

Ok, it may not be the easiest thing with some of the techniques out there, but there are solutions.

Why testing is so important? Used in the right way, it improves quality while minimizing the number of bugs, and hey - that's exactly what we want, isn't it? Testing makes sure the job gets done not only well enough, but beyond well enough. Or at least it should, used the right way.

So, grab your unit testing framework right away (here's a list of unit testing frameworks) and start unit testing today.

Rule #14 of programming:

Be serious about testing

Test your apps!

Rules of Programming: Handle Exceptions First

When you write a new function, always make sure to handle exceptions first. Then write the actual function. It's as easy as that.

One of the most common failures: a variable containing something else than expected (either null value or wrong input). Make sure you handle it.

Also: use logging to catch errors. log4net and Elmah will help.

Rule #13 of programming:

Handle exceptions first

Rules of Programming: Use a Real Bug Tracking System

Where there's code, there will always be bugs. Use a real bug tracking system to keep track of the bugs and their state.

A basic bug tracking system should have these features:

  • Submit and close ticket
  • Track ticket status
  • Accessible (web interface)
  • Notifications via e-mail
  • Multi user support
  • Easy to use

An Excel spreadsheet on your intranet won't cut it. In that case, a Google Docs spreadsheet is better. Even better is using a system like FogBugz, which integrates easily with a number of other systems.

Rule #12 of programming:

Use a real bug tracking system

Rules of Programming: Use the Best Tools Available

You should use the best tools available to accomplish your tasks. Really.

This means you should have the latest up to date version of your favourite IDE when programming, this means you should use productivity tools such as ReSharper and CodeRush if you want to, this means you should have (almost) anything you ask for that improves your programming.

If you don't work with the tools you love because of any company policy restricting purchase of necessary tools - make sure the responsible ones get to know what you can do for the company using those tools (probably increased productivity and a happier employee).

When it comes to the tools you use, they're probably worth way more than what you have to pay for them.

Rule #11 of programming:

Use the best tools available.

Rules of Programming: Have Fun!

Have fun!This one applies to more than us developers, but still.

It's very important you have fun doing the stuff you do best, whether it's at work or somewhere else. If you have fun, it's easier to excel and make a great career of your craft, it's easier going to work and you'll find your whole life much more meaningful. You'll probably also produce more quality work if you have fun while doing it!

And if you don't have fun at work, that probably means it's time to make a change.

Rules #10 of programming:

Have fun!

Rules of Programming: Be Consistent

It's difficult for a group of developers to agree on a specific coding style. We can only point in this or that direction and say follow the coding standard.

What is most important though, is that no matter what coding style you agree upon, each developer has to be consistent. Pick a coding style and stick to it. This way it'll be easier to read your code and understand the flow in your application.

Rule #9 of programming:

Be consistent.

Rules of Programming: Keep It Simple, Stupid!

At all times, the best way to solve a problem, is to do it in a simple and clear way. That's where the KISS principle comes in as a reminder. Keep It Simple, Stupid.

Doing the simple thing is not easy though. It requires training and skills. Sometimes it's harder to solve a problem in a simple way, than to actually solve the problem itself.

It may sound like a cliché, but less is definitely more. So, from now on when you write code - think of the KISS principle and try to do things the simple way. You'll thank yourself in the end.

Rule #8 of Programming:

Keep It Simple, Stupid!

Rules of Programming: Fix Bugs Before You Write New Code

If you want the highest possible code quality, code that's easy to maintain and code that actually does what you expect it to do - then you should fix bugs before you do anything else.

Bug fixing might be boring, yet you will thank yourself for taking your time fixing bugs, before writing new code. Why? Because if you write new code, you'll probably have even more bugs in it, and the new code might depend on existing code with bugs, thus making it quite problematic getting your code to work.

Rule #7 of programming:

Fix bugs before you write new code.

Rules of Progamming: Don't Repeat Yourself

If you have to write the same code or almost the same code more than once in a project, there's something wrong.

DRY (Don't Repeat Yourself) is one of the most important principles in software development, aiming at reducing code, making it easier to maintain code.

Next time, if you find yourself copying and pasting code, ask yourself: can I refactor this code and make it more efficient?

Rule #6 of programming:

Don't Repeat Yourself

Hey, you can even get this on a shirt!

Rules of Programming: Always Try New Techniques and Always Try to Improve

As a programmer, it's very important to keep up with what's latest in the programming world. By trying new techniques and by solving the same problems in new ways, you'll improve your skills and become a better programmer.

Giving oneself small challenges is always helpful, whether it's programming or not. Learning a new programming language is a challenge. Trying to be creative is a challenge.

We need challenges to keep improving. And if you don't get challenges in work, then give yourself challenges (or switch job).

Rule #5 of programming:

Always try new techniques and always try to improve

Rules of Progamming: Use Design Patterns When Appropriate

We all know about them, yet we seem to be afraid to use them. Fact is, that design patterns not only improve your code, but also will speed up development time and make it easier to extend code in the future.

Inversion of Control is a design pattern / principle that gets much attention these days, but there are several other design patterns to utilize, such as the the repository pattern.

You also have the presentational patterns, such as MVC (Model View Controller) and MVP (Model View Presenter).

Knowing your design patterns and how they can improve your code, is close to essential if you aim to be a great programmer.

Here are further resources on design patterns:

Rule #4 of programming:

Use design patterns when appropriate.

Rules of Programming: Follow Existing Naming Conventions

To make it as smooth as possible working in a software project, make sure you follow a naming convention. And if you're a team working on a project, it's really important that all team members follow a specific naming standard.

Simply put, know how you should do the naming and make sure to follow it.

IDesign C# Coding Standard Guidelines is a great start for C# developers.

Rule #3 of programming:

Follow existing naming conventions

Rules of Programming: Make Your Code Self-Descriptive

This one is really easy. Make your code clear. If an outsider takes a look at your code, it should be clear to that outsider what the specific code is doing.

How can you make your code more self-descriptive?

  • Use conventional naming. Name your classes and variables so that it's instantly understood what they are there for.
  • Comment code when it's necessary and adds value to the code. Not otherwise.
  • Make other people review your code. Ask for opinions and utilize pair programming if needed.

Rule #2 of programming:

Make your code self-descriptive.

Rules of Programming: Always Try to Improve Code You're Working on

There's always a time when a developer has to work on code that was written before, whether it was by the developer or by someone else. To many developers, this is a pain. A real pain.

However, small improvements can be made, by refactoring the code. Each time the code is touched, it has to be improved. It doesn't have to be something revolutionary, just small bits of refactoring.

This way, after a couple of times, the code will be far more like the modern programming we're striving for, thus making it easier and funnier to work on.

Rule #1 of programming:

Always try to improve code you're working on.

Rules of Programming - Christmas Calendar 2010

On December 1st (tomorrow), I'll start a mini series of blog posts - rules of programming. This series will run Christmas calendar style, meaning there will be one blog post every day until Christmas Eve.

Why? I aim to highlight relevant rules and practices in modern programming - something that is much needed in our community.

So, from December 1st until December 24th!

Here's a teaser:

Measure code quality: WTFs/minute

To the top