Developers are often bombarded with various principles and concepts that you have to remember when writing code.

YAGNI. Open/Closed. SOLID. Law of Demeter. SoC.

There are far too many so it's often tough to remember all of them, especially if you're writing code in functional or object-orientated specific languages.

In this issue, we outline the 4 most universal and important principles to remember that will help you write better and cleaner code by default. From there, you can explore some of the more specific principles mentioned above.

Let's dive in.

KISS (Keep It Simple Stupid)

A fun acronym with a super important principal behind it.

Writing code that is simple, easy to read and even easier to amend is the name of the game. KISS speaks to keeping your codebase as simple as possible so that you, or anybody else, can easily hop in and make some changes.

Building a codebase that is overly complex only adds to frustrations and time wasted trying to understand the code before any improvements or changes can be made.

Don't show off. Focus on simplicity.

Writing simple code is more impressive than complex, massive repositories.

DRY (Don't Repeat Yourself)

DRY aims to mitigate code duplication. Logic, functions or pieces of data should only exist in a single space in your codebase to then be referenced where needed.

Having 2 methods that achieve the same thing creates lengthier code bases, adds unnecessary complexity and will often make debugging far more difficult.

The opposite of DRY is WET (write everything twice). Avoid this at all costs. Nobody wants to be called out for being a WET developer.

Measure twice, cut once

This isn't a principal that is unique to software development, but it's definitely one that needs to be thought of more frequently.

Before you start working on a feature or begin writing some code, plan out your work. Think about what you're needing to achieve, what files you're needing to add or adjust and how you're going to go about building the feature.

Planning out your work will help you gain foresight on any potential issues that you'd only otherwise discover midway through writing the code. Which leads to time-wasting and a messy scenario of having to undo or refactor your code before it's even merged into your main branch.

Avoid premature optimization

Optimization is great when you're looking to speed up some performance or make your code easier to reuse down the line. However, this principle speaks to not performing optimization too early in the development process.

The reason for this is two fold:

1. Having code that has achieved what it's meant to is more important that more performant code that's not complete.
2. Requirements may change while you're writing the code or soon after you've built the feature. Optimizing early means that you'll have to spend time not only adjusting the logic of your feature but also tinkering with the optimization you performed which turns into a time-waster.

Choose to rather optimize out of necessity or when you know that changes to that specific piece of code are never going to happen. So optimizing it now won't have an impact on a potential refactor.

‍

There are so many more principles to think about when writing code, but if we were take the 4 most important, in my opinion, it would be the list above.

These principles also transcend functional or objected-orientated, JavaScript or Python, frontend or backend. Use them in every bit of code that you write.

See you again next week.

‍