Correct, Clear, Fast & Concise - In That Order {#correct_clear_concise}

(ref:correctclearconcise-intro)

You Must - (ref:correctclearconcise-must)

You Should - (ref:correctclearconcise-should)

You Could - (ref:correctclearconcise-could)

|Related Areas: | Demonstrably Correct
Easy to Read Code
Comments | |--------------- |------------------------------------------------------------|

Correct {#ccfc_correct}

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

Clear {#ccfc_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?

Fast {#ccfc_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.

Concise {#ccfc_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.



DataS-DHSC/coding_principles_book documentation built on March 11, 2020, 4:13 a.m.