The Ten Commandments of Programming
What makes a great programmer? Is it the thirst for coding? Is it the thrill of solving problems? The ingenious solutions to complicated issues? In truth, a great programmer values people more than code. In the words of Martin Fowler,
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”
Programming is an art, but it is not just individual art. It is a collaboration between people with different skills and levels of understanding. It is not a place to showcases how cryptic, short or clever code one can write, but how much of the code is maintainable, extensible, and easy to understand. Regardless if you are a beginner or an expert in the field, there is always room for improvement. This article outlines ten principles that every programmer should follow to make their code better.
KISS (Keep It Simple, Stupid)
KISS is probably the first thing that every developer needs to understand and factor into their coding. KISS states that most systems work best if they are kept simple rather than making it complicated. More often than not, sophisticated design and logic tend to be prone to bugs and errors. It takes a great deal of effort and time to understand complicated code logic and debug it. No one wants to be stuck debugging a complicated piece of code that breaks often. When starting with an idea, write it down, simplify it, and repeat till it can no longer be simplified. Coding comes after all the logic has been simplified and polished. Always remember,
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” — Antoine de Saint-Exupery
DRY (Don’t Repeat Yourself)
One of the most common problems in a piece of code is duplication, be it logic, data, or function. Repeated code tends to make the software lengthier and also takes extra effort to debug and maintain. Imagine changing one misspelled variable name 40 times in repeated code blocks at different places or changing one part of logic in all of those blocks. The DRY principle states that a given code should only be implemented at a single place in the source code. The opposite of the DRY principle is WET (‘Write Everything Twice’ or ‘Waste Everyones Time’). As the name suggests, WET wastes a lot of time on both the original developer and also others who contribute to maintaining and extending the project.
Suppose you are developing a website. On the ‘home’ page, you have the code for the navigation bar. On the ‘about’ page, you have the code for the navigation bar. On the ‘contact’ page, you have the code for the navigation bar. Consider abstracting the code for the navigation bar to a separate place (or the overall template) and calling it as needed in the different pages. After abstraction, you can update or edit the code for the navigation bar in one place without bothering to change it for all the pages.
Single Responsibility
The ‘Single Responsibility’ principle states that every class/module in a program must concern itself with providing a specific bit of functionality. Most classes/modules start like this and then end up amassing more functionality and evolving into ‘God classes’ or ‘God modules’ with over thousands of lines of code. It is better to break these ‘God classes/modules’ into separate and smaller pieces. Smaller pieces make the logic clearer, and the code easy to debug.
Separation of Concerns (SoC)
The ‘Separation of Concerns’ principle is like the ‘Single Responsibility’ principle but on a more abstract level. It states that every piece of software should be divided into different non-overlapping encapsulations that shouldn’t know about each other.
An excellent example of SoC is the MVC (Model — View — Controller) paradigm. Web applications or GUI interfaces generally follow the MVC paradigm. The paradigm divides the whole program into three parts, Model (“data for the application/interface”), Controller(“logic of the program”), and the View(“what the end-user sees”). Each part performs its function and is related to other sections but is also independent; this makes the code modular.
In the future, if the code for the logic(‘controller’) needs to be rewritten, it can be done without affecting how the application renders data to the user; this makes the code easy to update and debug.
YAGNI (You Aren’t Gonna Need It)
The YAGNI principle states that one should never code for ‘functionality’ you may need in the future. There are high chances that you would end up not needing it! Bloated code makes maintenance hectic.
As a specific example, I made this word generator for playing Pictionary with friends. I had a hunch that we may need to track words that were done, so I included a feature called ‘previous words,’ which were a list of words that had been generated previously. We ended up not using it; instead, what we needed was a dictionary to look up for the meaning of some of the words produced. I had to revisit my code twice to delete the unnecessary functionality and add the dictionary feature. I realized that it is difficult to predict what functionality may come in handy in the future. Thus, code should be minimalistic with capabilities for an extension in the future.
Open/Closed
The Open/Closed principle is mostly used in OOP(Object Oriented Programming), but it can be extrapolated to many other scenarios. It states that code should be open to extension but closed to modification. One needs to preserve the core behavior of a program and prevent people from modifying them. However, the program should also be open to extension, and users/other programmers should be able to add additional features.
It provides multiple benefits; the software is more stable as users can’t accidentally break the code, also more maintainable as users only need to worry about the extended functionalities and not the core functionalities.
Avoid Premature Optimization
Many of my friends (also me at some point in time) tend to optimize our code as they write it. This behavior is not only wrong, but it also eats up many hours that can be used to complete the code. Optimization does help in making an application faster, but one can only realize the bottlenecks in a program after coding the whole program and running tests. You can always guess which functions or classes are slow. But, more often than not, you end up optimizing functions that aren’t as slow as you think or don’t get called as often as you feel.
Don’t live with broken windows
“If a window is broken and left unrepaired, people walking by will conclude that no one cares and no one is in charge. Soon more windows will be broken…”
The ‘broken window’ here refers to bad design and poor code. Relevant code should never be left to rust and rot. Incorrect code needs to be fixed as soon as it is discovered. It makes other collaborators and users realize that the developers are active and value the code that they have written.
Clean code triumphs over Clever code
We all have seen clever code; Code that looks more like a riddle than a solution. A perfect example of it is to cram a large amount of logic into a single line or two. Another example may be to write down strange but functional statements exploiting the intricacies of a specific language. Clever code can be used to show off how much you know or how meticulously you know a language, but it is a huge mistake to use it everywhere. While writing an open-source software or a program in which many people collaborate, leave your ego at the door and forget about writing clever code.
Good programmers and readable code go hand in hand. Comment when necessary. Adhere to guidelines dictated by specific languages (e.g., Python) or companies (e.g., Google), and make sure the code is simple and easy to understand. No joy is greater than receiving praise for the beauty and elegance of a piece of code.
Refactor
Possibly the most critical point of all is to refactor your code often. Code refactoring refers to the restructuring of existing computer code — changing the factoring — without changing its external behavior. As an inexperienced programmer, one of the hardest things to accept is that code rarely comes out right at the first attempt. It may feel great and right while implementing a new feature successfully in the first try, but as a program grows in complexity, the same code may hinder the addition of new features. Thus, one often needs to revisit code that is already written and change its structure to make it easy to maintain in the long run.
“Things change, requirements drift, and your knowledge of the problem increases. Code needs to keep up.”
Software development is a continuous cycle, as your code evolves you need to rethink the way you had implemented older functionalities and continuously update the codebase.
Conclusion
Programming is an art, and one needs to express oneself while making sure that people around you understand and appreciate your code. The above points highlight means to achieve code that is human-friendly, extensible, and maintainable.
