Principle 3 Correct, Clear, Fast & Concise - In That Order

Write code with your colleagues priorities in mind. They need your code to work correctly, and they will have to understand and check it before they can benefit from it being fast or concise.

You Must - Ensure that your code is correct and that it is clear how it functions.

You Should - Make your code fast and concise, where possible without sacrificing correctness, clarity or excessive resource! Record choices made to achieve this balance.

You Could - Use profiling tools to understand resource usage and refactor to improve clarity and performance.

Related Areas:	Demonstrably Correct Easy to Read Code Comments

3.1 Correct

The first priority should always be that the code is correct. See the demonstrably correct principle.

3.2 Clear

It is more valuable to have code that other analysts can quickly understand, than code which runs a little quicker. Your work needs to be quality assured - so at least one other person will need to understand what you have written!

Clarity is made up of many components (e.g. comments, easy to read code and data structures). But don't overlook the clarity of your approach to the problem. Have you done something which will be impossible for someone else to check? Is there a more effective way to do it?

3.3 Fast

You may find that you have produced code which takes some time to run. If you expect to run it many times, then its time to think about how you could make things faster. But don't fall into the trap of optimising before you need to. Ask yourself how much time you are going to save, if it’s a couple of mins, but the optimising takes you several days, is it worth it?

For most languages there are profiling tools you can use to understand resource usage when you need to.

3.4 Concise

Keeping the amount of code you use to achieve a goal at a minimum can often be a good thing. There is less code to go wrong or debug, less to explain, style and document. But, remember that concision is less important than correctness, clarity and speed. Don't make it shorter than it needs to be, and think of the tradeoff with clarity and flexibility.