Anyone can write code, you say. What about good code? This is where the difficulties begin. We’ve all heard those horror stories about incredible if-else chains, programs that crash when just one variable changes, incomprehensible methods, and so on.
This happens when creating a product, when there is only six months of training behind them. Don’t make it your goal to write code that just works. The goal should be to write code that can be updated and changed – even if the changes are made by another person. It is important to understand and apply the following principles in programming:
Basic Principles of Programming
1. KISS
The principle of “simplicity” (“keep it simple, stupid” principle) is especially important for projects of medium complexity. If you think you’ve simplified enough, simplify the code one more level, but remember to start small so you don’t create a whole mountain of problems.
When you start writing code, try to keep it as simple and readable as possible. More complex code will take longer to write, and is more prone to bugs and bugs, making it much harder to change in the future. Wise words of Antoine de Saint-Exupery:
“Perfection is achieved not when there is nothing to add, but when there is nothing to take away.”
2. DRY
The “don’t repeat yourself” principle is crucial when writing clean and easy-to-change code. When writing code, you should avoid duplicating data and logic. If you notice that the same piece of code is written over and over again, the principle has been violated.
The opposite of the DRY code is the WET code: “duplicate”. One of the best ways to diagnose WET code is to ask yourself: in order to somehow change the behavior of the program, how many areas of the code would need to be changed?
3. Open/Closed
Code should be open to new areas but closed to change, whether you’re writing objects in Java or modules in Python. This applies to all kinds of projects, but this principle is especially important when releasing libraries or frameworks intended for use by other users.
4. Principle of Single Responsibility
The Single Responsibility Principle states that each class or module in a program should deal with only one set of specific functions.
Classes and modules are created according to this principle, but as the functionality expands, they turn over time into classes and modules that “can do everything” and take hundreds or even thousands of lines of code. If this happens, you need to break them down into smaller classes and modules.
5. Separation of interests
The principle of separation of concerns is the principle of single responsibility, but at a more abstract level. Essentially, a program should be designed to have many different non-overlapping encapsulations, and these encapsulations should not interact with each other.
A well-known example of this principle is the model-view-controller (MVC) paradigm, which divides a program into three distinct areas: data (the “model”), logic, and what the end user sees. For example, the code that handles loading and saving data to a database should not be responsible for how that data is displayed on the web. This principle simplifies maintenance. And in the future, if you ever need to rewrite all the code, you can do so without worrying about how the data will be stored or how the logic will be processed.
6. YAGNI
The principle is based on the fact that you never need to implement any functionality that you may need in the future. Most likely you won’t need it and it will be a waste of time, it will also complicate your code.
Often inexperienced programmers try to write the most abstract and general code to avoid WET code, but too much abstraction ends up being unmaintainable in the future. The trick is to apply the DRY principle only when you need to.
7. Avoid Premature Optimization
The principle of avoiding premature optimization is not similar to the YAGNI principle. The difference is that YAGNI prevents features from being implemented before they are needed, while the anti-premature optimization principle aims to prevent algorithms from being optimized before they are needed.
The problem with premature optimization is that you can never know where problems are in the program until they show up. Of course, you can guess, and sometimes you can even be right. But more often than not, you’ll be wasting valuable time trying to speed up processes that aren’t as slow as you think.
8. Refactor, refactor, and refactor again
One of the hardest truths for an inexperienced programmer is that it rarely works the first time. You might think you’ve written the perfect code implementing a certain feature, but as your program gets more complex, writing future features can be quite tricky because you’ve implemented a specific feature early on.
Codebases are constantly evolving. It’s perfectly normal to revise, rewrite, or even redesign entire pieces of code – and that’s not just okay, it’s the right thing to do. After all, later on you will know more about the specifics of your project than at the beginning of its creation, so you must constantly refactor your old code.
And don’t put this place off until later. Once you realize there is a bug somewhere, don’t put off fixing it. If you ever need to check or fix old code, try to improve it and make it cleaner and tidier.
9. Clean Code > Smart Code
Speaking of clean code, leave your “smart” code somewhere far away. Smart code refers to a type of code that is more like a puzzle than a solution, and exists only to show how smart you are. In fact, no one cares.
An example of “smart code” would be to fit as much logic as possible into one line. Another example is the use of specific language features to write strange but working operations. An example of smart code would be anything that can make someone say “Wait, what is that?” when looking at your code.
A good programmer and readable code go hand in hand. Make comments as needed. Stick to a certain style, whether it’s dictated by the language (like Python) or by the company (like Google). Watch out for language idioms and stop writing Java code in Python or vice versa. See our article on tips for writing cleaner code.
What makes a programmer effective?
Ask five people and you’ll get 10 completely different answers. For me, a good programmer is one who understands that writing code should ultimately benefit the end user, a good programmer is easy to work with in a team, because he finishes his projects to all specifications on time.
If you are just starting out, don’t think too much about it. Focus on how to write stress-free code. If you feel stuck at some part of the code, there are some solutions, but you can check them out here. And if you’re just not happy with your job, read our article on the signs that say programming isn’t for you.