Basic Programming Practices Every Programmer Must Follow
Anyone can write code. But good code? That’s where it gets tough.
We’ve all heard horror stories about spaghetti code, massive if-else chains, entire programs that can break just by changing one variable, and so on. That’s what happens when you try to make a shippable product with only a semester of programming experience under your belt.
Don’t settle for writing code that works. Aim to write code that can be maintained — not only by yourself, but by anyone else who may end up working on the software at some point in the future. To that end, here are some good programming practices to help you clean up your act.
#DRY
Don’t Repeat Yourself(DRY) is a principle of software development aimed at reducing repetition of software patterns, replacing them with abstractions and several copies of the same data, using data normalization to avoid redundancy. When the DRY principle is violated it is called as WET solutions, which stand for either Write Everything Twice or We Enjoy Typing.
Suppose you’re writing a podcast directory app. On the search page, you have code for fetching a podcast’s details. On the podcast page, you have code to fetch that podcast’s details. On the favorites page, the same fetching code. Consider abstracting all of that into a function so that if you need to edit it later, you can do it all in one spot.
#KISS
Keep It Simple Stupid!!!(KISS) principle states that most systems work best if they are kept simple rather than made complicated. Therefore simplicity should be a key goal in design and unnecessary complexity should be avoided.
Some of the world’s greatest algorithms are always the ones with the fewest lines of code. And when we go through the lines of code, we can easily understand them. The innovator of that algorithm, broke down the problem until it was so easy to understand that he/she could implement it.
Many great problem solvers were not great coders, but yet they produced great code!
#YAGNI
You Aren’t Gonna Need It(YAGNI) is a principle which states that you should implement things when it is actually needed, never when you just foresee that you need them.
By using this principle, your code is better, because you avoid polluting it with ‘guesses’ that turn out to be more or less wrong but stick around anyway.
For example, it’s a common practice to abstract the database access in a layer that handles the differences between various drivers, like MySQL, PostgreSQL and Oracle. If you’re working on a corporate website that is hosted on a LAMP stack, on a shared host, how likely is it that they will change the database? Remember that the concept was written with budget in mind.
If there’s no budget for database abstraction, there’s no database abstraction. If the unlikely event of a database change does occur, it’s a natural thing to charge for the change request.
#SoC
Separation of Concerns (SoC) is the process of breaking a computer program into distinct features that overlap in functionality as little as possible.
Concerns are the different aspects of software functionality. For instance, the “business logic” of software is a concern, and the interface through which a person uses this logic is another. Progress towards SoC is traditionally achieved through modularity and encapsulation, with the help of information hiding.
Model-View-Controller (MVC) design pattern is an excellent example of separating these concerns for better software maintainability.
#TDD
Test-Driven Development (TDD), also called test-driven design, is a method of implementing software programming that interlaces unit testing, programming and refactoring on source code.
Before any new code is written, the programmer must first create a failing unit test. Then, the programmer creates just enough code to satisfy that requirement. Once the test is passing, the programmer may refactor the design, making improvements without changing the behavior.
TDD gives a better understanding of what you’re going to write and enforces the policy of writing tests a little better.