“Any fool can write code that a computer can understand. Good programmers write code that humans can understand,”  –Martin Fowler

Writing code is easy! But it takes a lot more to write code that is clean, maintainable, extendable and easy to understand. It requires lots of practice and dedication. 

But why do we need to write clean code first of all? The answer to this question lies in the fact that large softwares is developed by hundreds of software developers collaborating with each other. 

A machine can understand a code that is even without line breaks and spaces, but a human can’t.

When working on a real-world project, collaborating takes place with different teams and business units, one must write clean, maintainable and optimised code to ensure smooth collaboration between various developers and teams. 

If you want to get hired for a real world job, you must invest your time learning techniques that would improve the quality of code that you write, and stop you from writing spaghetti code.

In this article we will look at some of those principles that will drastically improve your coding quality.

1. DRY

DRY stands for Don’t Repeat Yourself. In layman terms, it means to not repeat the same chunk of code again. 

What this principle says is that, use abstractions instead of repeating chunks of code. Whenever you find yourself copy pasting code, stop there and think how it can be optimised.

While writing coden, often we repeat the same code at multiple places and this is a terrible mistake to make. 

The problem with repeating code is that it kills the matintaibliby. If in the future, a change needs to be made and If some code is repeated for eg at 10 places in the codebase, you would have to make changes to all the 10 places.

Also writing redundant code are basically wasted lines. Resources are wasted.

Writing repeated code also has another flaw: there are extra lines of code that need to be checked in the debugging phase. You have to make sure to go through those extra lines of code to check if the code is bug free.

Therefore it is highly recommended that you follow the DRY principle of writing code.

Whenever you find yourself writing lines of code that have been written elsewhere, stop and refactor there itself. Try to use functions, loops or classes to allow reusability of code.

2. Single Responsibility Principle

This is a sub principle of the 5 SOLID programming principles. In software engineering SOLID is an acronym for five object oriented design principles intended to make software writing more understandable, flexible and maintainable. 

Robert C Martin or popularly known as uncle Bb in the programming world, who is an American engineer instructor and best selling author was the one who introduced these 5 SOLID principles. 

In the single responsibility principle, we just have to focus on having a single class doing a single thing. 

A class should only be focused on completing one single thing at a time. Though this sounds very vague, the essence of this principle is that we should avoid creating a class that becomes way too lolong. 

For eg if we have a car class. It would be terrible to include gear, wheels, stereo systems, engines and exhaust inside that same car class. 

Instead you can create different classes for engine, stereo, tyres. Rather than stuffing everything in one single big class and making it extremely long, break it down. Each class should do one thing at that time and do it well.

Though it may sound absurd when you are doing your weekly project at home where the size of the application is small, but when you get into the real job, where you have to maintain and add to a million lines of code database, these principles are crucial.

It would be beneficial if you learned the other 4 principles as well nevertheless here is a short intro to all the rest.

The 5 SOLID principles are 

• The single-responsibility principle: “There should never be more than one reason for a class to change.” In other words, every class should have only one responsibility.
• The open closed principle: “Software entities should be open for extension, but closed for modification.”
• The Liskov substitution principle: “Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
• The interface segregation principle: “Many client-specific interfaces are better than one general-purpose interface.”
• The dependency inversion principle: “Depend upon abstractions, [not] concretions.”

3. Open/Closed SOLID Principle

This is another principle from the SOLID code principles coined by famous uncle bob. 

According to this principle your code should be open for extensions but closed for modification. Whenever you need to add  a new feature, you don’t have to re-write the code and it should be easy to add various functionality to your code

This is one of the neat and amazing principles that helps in writing better and clean code. 

You will fall in love with it when you realise that your program or code is scalable without the need to modify the code.

Consider the below example. You are making a class for vehicles. In the same vehicle class you have added car function.

Now later on the road you have decided to extend this class to accommodate something like an SUV or a jeep. 

You would have to modify the vehicle class to accommodate the new features. Doing so will break the open closed principle and also your code, if lots of other classes are depending on it. Instead what you can do is, create subclasses for individual vehicle types.

Now your code can be extended with how many types of vehicles you wish. Though this is a very simple example, the ideology remains the same regardless of the size.

The only takeaway you have to remember is to write code that is extendable modifying the present code.

4. KISS- Keep IT Simple, Stupid 

This principle suggests to not use any complicated and unnecessary lines of code that makes your code look pretentious.

Often junior developers write complicated lines of code to impress their senior developers, or friends write complicated code to seem cool and tech savvy.

This is something one must stop at all costs. If you can write something that is easy and simple, do it. Please don’t get into writing code that is difficult to comprehend. 

When you write complicated code, the other developers may or may not understand what you have written. Even yourself, when you revisit the code after a month or two won’t be able to understand and comprehend. 

Try to use existing libraries if you can, use good variable names that are meaningful and self explanatory. Stop using names likes bigggg instead of turn_into_uppercase.

Practices that go against kisses will only hurt you in the longer run. Therefore write code that is simple, easy and stupid. Code That anybody can read and understand.

Anyone can code, but writing comprehensible code is very difficult and that is what the current software industry is striving for.

5. Commenting and Documentation

We have talked alot about SOLID code, DRY principle. But documenting code is as important as writing clean code. 

Documenting is the part of software engineering where a person writes about what the code does, how it does. Simply put, documentation is the process of writing brief human readable text that explains the code. 

Developers often consider documentation the least important tasks of all, though this habit hurts in the long run. Surprisingly, documenting code is one feature which can make a big change with very little input. 

No matter what you are developing, someday you or somebody among your colleagues will revisit the code, and it is very important to have a well maintained and documented code.

Not only will your code be easy to understand but also other fellow developers will thank you for your efforts.

Try to add meaningful comments at the start of your code that are short in length but explain well. When writing code that is confusing, the need for comments gets even more crucial.

When writing the documentation for your program, try to write in depth about what your program does without sacrificing details. Include all the terminal command lines used, the prerequisites. Write about the libraries used, the way some decisions were made, the logic used. In short, the more time you spend documenting, the better it will get. 

Conclusion

In this article we looked at some of the principles to improve the quality of code that you write. 

One must not forget that learning how to be a good programmer takes a lot of time, dedication and effort. 

A good programmer is someone who writes code that is clean, easy to understand, maintain and extend while keeping it optimised at the same time.

Only a good programmer can ensure smooth collaboration with the different teams, developers that are working on the same product.