How do you define a good programmer

10 Basic Programming Principles Every Programmer Must Follow

Anyone can write code. But good code? It's going to be tough there.

We've all heard horror stories of spaghetti code, massive if-else chains, entire programs that can be broken by changing a variable, functions that appear to be obscured, and so on. This happens when you are trying to make a shippable product with just one semester of programming experience.

Don't fool yourself into writing code is working. The goal is to write code that can do that to be kept - Not just by yourself, but also by anyone who will work on the software at some point in the future. To this end, there are a few principles that will help you improve your act.


The "Just keep it stupid" principle This is true for almost all of life, but is especially necessary on medium to large programming projects.

It starts at the beginning when you define the scope of the area to be created. Just because you're passionate about game development doesn't mean you can create the next one World of Warcraft or Grand Theft Auto. When you think you've simplified enough, simplify it one step further - feature creep is inevitable, so start small.

But even after programming begins, keep it simple. Complex code takes longer to design and write, is more prone to errors and mistakes, and is difficult to change later. In the wise words of Antoine de Saint-Exupery, "Perfection is achieved not when there is nothing left to add, but when there is nothing left."


The “Don't repeat yourself” principle is critical to having clean and easily changeable code. When writing code, you want to avoid duplicating data and duplicating logic. If you find the same code being written over and over again, you are breaking that principle.

The opposite of DRY code is WET code: “write everything twice” (or “waste all time”). One of the best ways to diagnose WET code is to ask yourself: In order to change the behavior of the program in any way, how many areas of code would you have to change?

For example, let's say you're writing a podcast directory app. On the search page, you have code to get the details of a podcast. On the podcast page, you have code to get the details of this podcast. The same access code on the favorites page. Consider abstracting everything into one function so that you can do it in one place later if you need to edit it later.

3. Open / Closed

Whether You Write Objects What is Object Oriented Programming? Basics Explained in Layman Terms What is Object Oriented Programming? Basics Explained in Layman's Terms Most modern programming languages ​​support the "object-oriented programming" (OOP) paradigm. But what exactly is OOP and why is it so useful? More information in Java or in Python modules should be aimed at building your code open for expansion, but closed for modification. This applies to all types of projects, but is especially important when publishing a library or framework for others to use.

Suppose you maintain a GUI framework. You could publish it as it is and expect end users to modify and incorporate the shared code directly. But what if you put out a big update four months later? How do they implement all of your supplements without throwing away all of their work?

Instead, share the code prevented direct change and encouraged Extension. This separates the core behavior from the modified behavior. The advantages? Greater stability (users can't accidentally break core behavior) and greater maintainability (users only worry about extended code). The open / closed principle is the key to a good API. What are APIs and how are open APIs that are changing the internet. What are APIs and how are open APIs that are changing the internet. Have you ever wondered how programs appear on your computer and the websites you visit "talking to each other?"

4. Composition> Inheritance

The “Composition via inheritance” principle indicates that objects with complex behavior should do so by containing instances of objects with individual behavior, rather than inheriting a class and adding new behavior.

An excessive reference to heredity can lead to two main problems. First, the inheritance hierarchy can get messy in no time. Second, you have less flexibility in defining special case behaviors, especially if you want to implement behavior from one branch of inheritance into another branch of inheritance:

Composition is much cleaner to write, easier to maintain, and allows almost unlimited flexibility as far as what behaviors you can define. Each individual behavior is a class of its own, and you create complex behaviors by combining individual behaviors.

5. Individual responsibility

The Principle of individual responsibility says that each class or module in a program should only be concerned with providing a specific functionality. As Robert C. Martin says, "A class should only have one reason to change."

Classes and modules often start out this way, but as you add functionality and new behaviors they can easily evolve into God classes and modules that take up hundreds or even thousands of lines of code. At this point, you should break them down into smaller classes and modules.

6. Separation of Concerns

The Principle of separation of concerns is like the principle of individual responsibility, but on a more abstract level. In essence, a program should be designed to have many different non-overlapping encapsulations, and those encapsulations should not know each other.

A well-known example of this is the Model-View-Controller Paradigm (MVC), which divides a program into three different areas: the data (“model”), the logic (“controller”) and what the end user sees ( “View”). MVC variations are common in today's most popular web frameworks.

For example, the code that loads and stores data in a database doesn't need to know how to render that data on the web. The replay code can accept input from the end user, but forwards that input to the logic code for processing. Each part treats itself.

This leads to modular code that greatly simplifies maintenance. In the future, if you need to rewrite all of your rendering code, you can do so without worrying about how the data is stored or the logic processed.


The “You won't need it” principle the idea is that you will never code for the functionality you need can need in the future. The chances are yours habit You need it and it will be a waste of time - and not only that, but it will unnecessarily add complexity to your code.

You can see this as a concrete application of the KISS Principle and an answer to those who take the DRY Principle too seriously. Inexperienced programmers often try to write code that is as abstract and generic as possible to avoid WET code, but too much abstraction results in bloated, impossible to maintain code.

The trick is to only use the DRY principle when you need it. If you notice chunks of code being rewritten over and over, abstract them - but never from yours think A piece of code is written over and over again. More than not, it won't be.

8. Avoid premature optimization

The no premature optimization principle is similar to the YAGNI principle. The difference is that YAGNI addresses the trend Implement behavior before they are necessary, while this principle tends to Speed ​​up algorithms before it is necessary.

The problem with optimizing ahead of time is that you can never really know where the bottlenecks in a program will lie until then. You can guess, of course, and sometimes you are right. Most of the time, however, you are wasting valuable time trying to speed up a function that isn't as slow as you think or isn't called as often as you'd expect.

Reach your milestones as easily as possible Profile your code recognize real bottlenecks.

9. Refactor, Refactor, Refactor

One of the hardest truths to accept as an inexperienced programmer is this Code rarely comes out right the first time. It can feeling Right, if you implement this shiny new feature, but as your program grows in complexity, future features may be hindered by the way you wrote this earlier version.

Code bases are constantly evolving. It is perfectly normal to rework, rewrite, or even redesign entire sections of code - and not only normal, but healthy too. They know more about the requirements of your project now as if you did that begin, and you should regularly use this new knowledge to revise old code.

Note that it doesn't always have to be a big process. Take a page from the Boy Scouts of America who thrive on these words: "Leave the campsite cleaner than you found it." Whenever you need to review or change old code, always clean it up and leave it in better condition.

10. Clean Code> Clever Code

Speaking of cleaner code, leave your ego at the door as well forget about writing clever code. You know what I'm talking about: the kind of code that looks more like a puzzle than a solution, and is just there to show how smart you are. The truth is, nobody really cares.

An example of clever code is packing as much logic as possible into one line. Another example is taking advantage of a language to write strange but functional statements. Anything that could make someone say something, "Wait what?" while crawling your code.

Good programmers and readable code go hand in hand. Leave comments if necessary. Stick to style sheets whether they are dictated by a language (like Python) or a company (like Google). Notice the idioms per language and stop writing Java code in Python or vice versa. Check out our article for tips on writing cleaner code. 10 Tips for Writing Cleaner & Better Code. 10 Tips for Writing Cleaner & Better Code. This is how you can write cleaner code today. Continue reading.

What makes a good programmer?

Ask five people and you will get 10 different answers. For me, a good programmer is someone who understands that ultimately the coding should serve the end user, with whom it is easy to work in a team and who completes his projects on time and precisely.

If you're just starting out, don't worry too much just yet. Focus on learning how to code without the stress. If you're feeling stuck, check out our article on the Programmer's Block. And if you're not exactly happy with writing code, check out our article on Signs That You Aren't meant to be a programmer cut out to be a programmer. If you're not entirely sure whether to be a programmer, here are some pointers that might point you in the right direction. Continue reading.

How would you define a good programmer? Do you have any tips for inexperienced programmers looking to improve? Let us know in the comments below!

Learn more about: programming.