Archive for Rules of programming:
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
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
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
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
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
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
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
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
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!
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
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
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
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
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.
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!
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.
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!
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.
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!
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
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.
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
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.
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.
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:
