Code Like a Pro

Programmers do not just develop software, they contribute to the community. If you are reading this article, chances are you would want to find a job in a professional environment where you can share your knowledge and experience with others. If so, you’re at the right place!

In this article, I have put together a few tips that I think are very important in my daily work and that of my colleagues. They are some basic principles that we should all try to follow in order to code like a pro! Be aware that coding like a pro is not just about you and your code. It’s about how well your code is prepared to be carried on by other colleagues. This makes it easier for you, and those following in your footsteps, to pick up where you left off and continue their work. So here are some of the key things we think are critical.

Tip 1: Indent your code

Code indentation is one of the most fundamental principles to follow in code development. There is a very simple but important reason why we should do this: It makes the code easier to read and understand! And it looks better, too.
Every time a developer takes on a new task that involves reading or modifying code written by others, good code indentation makes the job much easier.

Tip 2: Use intuitive names and adopt naming conventions

Sometimes naming variables or methods seems like a fairly simple task, but we should always remember that our code may one day end up in the hands of another developer. With this in mind, we should always try to name our variables/methods as simply as possible. To facilitate this process, we should adopt naming conventions, i.e. a standardized way of naming variables and methods in our code. If we use this technique, our work will be easier both for us and for other developers.

Tip 3: Comment your code

There are different opinions on the subject of commenting on code. Some feel that commenting out code takes up too many lines and fills the solution with garbage. Others believe that code should be commented from top to bottom to clearly explain what everything is done.
I have mixed feelings about this theory. Personally, I think we should comment our code, but only when necessary. There are parts of the code that, if you name them well, are self-explanatory. But there are also some methods that have complex operations, and in that case it should be well explained what they do. So my advice is: do it, but do it only when it is necessary.

Tip 4: Use try/catch clauses 

When developing software, it happens from time to time that we do not consider a possible wrong output or a possible exception that could be thrown. In such cases, the use of try/catch clauses can be very useful. For example, if there is an error connecting to the database and that part of the code is not handled within a try/catch block, it could output the name of the database to the user. This is a behavior that we do not want. It is very important to handle the exceptions correctly so that we can give proper feedback about the output.
It also makes it easier for the developer to troubleshoot, because when we use the try/catch clause, we know for sure where exactly the error occurred.

Tip 5: Avoid code repetition

Sometimes we developers tend to write the same code over and over again to accomplish a similar task in different parts of our project. We should take this thought to heart, “The third time you write the same piece of code is the right time to extract that logic into a general-purpose helper”. Repeating the same code in the solution unnecessarily increases the complexity of the solution. We should keep things as simple to understand and work with as possible.

Tip 6: Write defensive code

We developers can sometimes succumb to the temptation to write code that does exactly what we want, forgetting that it does not always do what we want. When we write code, we should always keep in mind where it might fail! If we do that, we are sure to avoid many bugs that are discovered later, saving time and money.

Tip 7: Avoid big methods

When we are faced with a task that involves multiple operations, it is easy to take the wrong approach and try to do it all with one method. This almost always means that a large method will be the result of this behavior. Large methods have high cognitive complexity, which means they are difficult to understand and work with. When a method becomes so large, it is time to break it up and divide it into smaller auxiliary methods.

Tip 8: Use and abuse of design patterns

In the daily life of a developer, we encounter problems that I am sure many other developers around the world face. In order to create simplified solutions to some common development problems, design patterns have been developed. With the help of design patterns, we can develop code more efficiently and get a tool that is a universal language between developers. This technique gives us tips on how to create different types of code depending on our needs. Using design patterns not only makes a developer’s job easier, but also allows other developers who are familiar with design patterns to learn your code much more easily.

Tip 9: Write tests always

Building software should not just be about writing code and making it work. It is also about making sure our product is delivered in excellent condition. Testing is an important part of the quality assurance process of any software development and gives us the confidence to be able to tell our customers, without a guilty conscience, that we have a stable and fully functional product. Not only do we ensure the quality of our product, but developers waste less time correcting bugs. The earlier a bug is discovered, the easier it is to fix it. And that’s where testing can make a difference. It is much more expensive for a company to fix bugs when the code is already in production than when it is still in development.

And Final Tip: Don’t write code you don’t need right away

Sometimes a developer writes code to create new functionality and is already thinking about the new features. This can lead to a temptation to write code that you do not need right now but will need in the future.  If you do not need it now, do not write it. Your code should be ready to support new features, of course, but there’s no reason to make it more complex by writing unnecessary code.
In most cases, code written in advance becomes useless because the new feature is not implemented at all or needs to be changed because the use case has changed for some reason. In the first case, it is dead code or garbage, while in the second case refactoring is as much work as writing it from scratch. Neither scenario looks good.
The same is true for the commented-out code. Commented-out code is code that is no longer needed in most cases (except for some rare exceptions). But what happens is that we leave it there anyway. 

Do you have other tips that might interest you? Let us know where we can help!