The Pyramid of Coding Principles

There are a lot of processes that need to be completed and technical issues to be tackled to make a fully functional application. One of the things we can do to make our apps right, work, and faster is to implement the coding principles.

Reverse Pyramid of basic coding principles made by me

With years of experience working in software houses. I’ve been dealing with a lot of clients' applications that are barely maintainable.

So what’s wrong and how am I identify those apps as “barely maintainable”, If we are used to implementing coding principles to our application then most likely we can identify whether an application is bad from the codebase perspective.

Those are the coding principles I used to use for the majority of my application.

Make It Work

The first rule before implementing any principle is we need to make sure our application work first. What’s the point to have a fully maintainable codebase if the application can’t be used by the users.

Because the user will not care whether the application is built on a top super server and developed using the best coding principles, the user just care whether the application work or not.

After the application works as it is, then we can start working on implementing any coding principles that suit our applications.

You Aren’t Gonna Need It

Oh silly me, back in the day I was a junior software engineer I used to keep unused code, components, comments, etc just because I thought I will gonna need it later.

But the reality is, I never use that piece of code for weeks or even months.

First of all, we need to exclude any unused code from our main codebase, and if you insist to keep it because you will need it later, then just you version control system properly.

If we remove a code from our codebase, there will be history in the VCS and we can easily roll back or copy-paste the old code without keeping that code forever in our codebase.

In the end, The bigger codebase the bigger effort needed to maintain.

Keep It Simple Stupid

example code smells/critics using rubocop

Ya, you heard it right. Don’t make anything more complicated as it is.

If we can a process more straightforward then why would we bother to make that thing more complicated?

The easiest benchmark is our changes lighten the server load or burden it and is our codes are maintainable by others or not.

If our code did not pass the benchmark then it means our codebase is too complicated and needs some refactoring. We can easily refactor the code using an open-source code critic, code smell libraries to automatically make a code changes suggestion for us.

Don't Repeat Yourself

Have you ever needed action or process that need to be done before every action, such as we need to make sure the user already login before it can access any user pages?

As you can see from the above code, I try to call is_user_login? in every controller action, and it should be optimized, because if we need to rename the method or change the logic, etc. This kind of method will be inefficient, but we can fix it.

We can create a constructor/middleware/before action that will call is_user_login? function every time one of the functions is being triggered.

You can see the difference after we refactored the code, the code will more maintainable and readable.

Clean Code

I bet you already heard many times about the clean code principle, and I want to tell you that clean code is a more like general principle.

The first rule of clean code is always to create a clear and concise code with a clear intention for the example is whenever we create a function, method, module, or variable name.

The name should represent its value or its logic as a whole and don’t forget to follow the existing code conventions because every programming language has a different approach.

I can’t write all of them in this article but if you are interested to explore furthermore about this topic, I highly recommend you to read this book

Standing On The Shoulder of Giants

Utilize industry standards and mature technologies instead of building our own standard(s).

There are a lot of resources that already discuss how to create a boiler plate code with some tools, how to code with best practices with a specific tool, and so on and so forth.

I highly recommend you to follow the existing conventions, best practices, and standardization because we should not build any solution on top of such standards unless it gives us a competitive advantage

Boy Scout Rule

What is one of the main causes of the decrease in programmers’ productivity?

Yes, you are right. The main reason for our decreasing productivity as time goes by is when we have to maintain or continue the development of a project that’s built with a messy code.

Surely it will slow us down when we have to deal with someone else’s messy code or even our messy code (shame of us).

So how to deal with it? We can use “The Boy Scout Rule” as uncle Bob said in his book “Always leave the campground cleaner than you found it”.

So whenever we have to develop new features or maintain the existing features, we have to always add some improvement to our codebase. It doesn’t have to be a major fix, we can do a minor fix too. For examples are renaming variables, removing whitespace, making the code have the same indentation, and so on so forth.

Make It Fast

After a tackle the challenge to make our code more maintainable, optimized, and readable, then we can be focusing on making our application faster.

Whether it optimize the database indexing, modify the architecture, add cache strategy, and so on and so forth.

Lastly, The mark of a great craftsman is actually understanding that refactoring costs time and it’s better to balance all the principles concurrently. Don’t just do YAGNI only for phase 1.

Meaning using these principles at the same time within each iteration/milestone, but allocating the least time/care to items at the bottom of the pyramid.

Otherwise, you end up with a mountain of technical debt even before you realize it

you can check one of my articles for reference

An Expert Full-stack Software Engineer with years of experience, adept at developing, scaling software solutions.