Ten basic principles of coding

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand,” said Martin Fowler, the British software developer.

 

Computer programming is the bedrock of digital tech, but for many, it produces a shudder of fear. There is a perception that coding is challenging, robotic, and done solo in a dark room.

 

Despite this reluctance, charities do have various reasons to use coding. From developing charity apps to designing a website, computing is a key skill to have.

 

For those starting out, we sketch out the basic coding principles that good programmers use, and discuss what they mean in simple terms.

 

 

1. Keep it simple, stupid (KISS)

 

KISS means programmers should make code as straightforward as possible. If simple one-lined script is possible, beginners should stick to it. Overly fancy, advanced code can be confusing by making it hard to determine what its purpose is.

 

 

2. Don’t repeat yourself (DRY)

 

Coding often requires circular thinking. As an example, coders might want to re-evaluate outcomes until a threshold is achieved. For counting, summation, and other basic functions, copying and pasting multiple sections of code can work.

 

However, when there are errors, coders will have to waste time checking and changing every pasted section. To avoid this, use the DRY principle and create a single loop or function.

 

 

3. You aren’t gonna need it again (YAGNI)

 

YAGNI is part of the programming philosophy coined by XP (Extreme Programming) co-founder Ron Jeffries. He said: “Always implement things when you actually need them, never when you just foresee that you need them.”

 

In practice, developers should only include code and add functionality when there’s actually a need for it rather than a ‘nice to have’. This principle helps programmers stay focused on what’s actually the purpose rather than on features which aren’t in production.

 

 

4. SOLID design principles

 

This is a big one in computer science. Coined by Robert Cecil Martin (dubbed ‘Uncle Bob’ by those in the industry), SOLID is an acronym for several best practice concepts:

 

S - Single-Responsibility Principle

O - Open-Closed Principle

L - Liskov Substitution Principle

I - Interface Segregation Principle

D - Dependency Inversion Principle

 

While they all apply in practice, we’ll discuss the first two, Single Responsibility and Open-Close Principle, in greater detail below (see steps 5 and 6).

 

The Liskov Substitution principle relates to variables being defined in the computer code. The Interface Segregation Principle helps coders interact with users based on ability or knowledge of the program.

 

The Dependency Inversion Principle has two ideas. The principle separates out high- and low-level logic so that changes in low-level modules don’t affect higher functions. This separation is achieved by an abstraction, or interface, which doesn’t depend on details.

 

In essence, the abstraction acts as sieve between the different levels of programming.

 

 

5. Single Responsibility Principle

 

Another one from Uncle Bob, the Single Responsibility Principle dictates that each module is only ever responsible for one thing. To create clear programs and code, the Single Responsibility Principle means for each module to control a single optionality.

 

 

6. Open-Closed Principle

 

Your final version of code probably includes main functionality and options. When sharing your code, clearly mark sections of code which should and should not be modified. Open code signals to others that those sections can be modified without breaking the programme, whereas closed code lets others know what not to change.

 

 

7. Modularise your code

 

Even beginners can write code with many different functions. Keep your functions separated in blocks or modules. By organising your code by functionality you’ll be able to come back to adjust it or to review.

 

 

8. Separation of concerns (SoC)

 

Similar to ‘Modularise your code’, the SoC principle says that computer programs should be set out in sections by concern. In this context, concern means a set of data that affects the program.

 

Under the SoC principle, each data set dealing with a particular function should be separate. You may end up with a section for controlling user interface and another for output.

 

SoC programs are well organised and each concern can generally be modified. HMTL, CSS and JavaScript are examples of SoC, as each language controls different aspects of webpage dynamics. Equally, each language works independently of each other.

 

 

9. Comment and document your work

 

Document your work, both inside your code and in your filing system. As part of the program, developers’ best practice includes commenting on the code. A short explainer or description of what the code does helps guide other developers around your thoughts.

 

Remember, in your filing system, versioning schemes identify the changes that have been made. Version 0.1 as an example, could serve as your ‘beta’ test prior to launching a Version 1.0.

 

For those not working on the code, versioning directs users to the file in use.

 

 

10. Learn from your mistakes

 

Steve Jobs said: “Everyone in this country should learn how to program because it teaches you how to think.”

 

When coding, accept that you’ll make mistakes and break some code. What’s important in this principle is that you document and learn from errors.