Welcome in my first english blogpost;-) Originally on the binar::apps website.

Every good programmer wants to create a nice code. But what does it actually mean? And what exactly can you do? Let me show you my own list of “Top 5 actions to make your code better”.

First question we should ask ourselves is „Why are we programmers?”. Reasons may be varied: „I can create my own mechanisms!” or „I can change the world through my applications!”. For sure it can be also „I just want to earn money”. In any of this cases you have to create a working application. And quality of this app depends on your code. So it has to be good.

But what does it mean „good/nice/better” code? For me it should be readable, scalable and consistent. Now let me show you my favorite habits & tricks that make up my own list of „Top 5 actions to make code better”.

Pull Requests and Code Review

I assume, that you use repository. One of the biggest temptations is having only one branch. Let me show you why it is wrong. Here is the probable situation:

Three people work on some project. They have problems with conflicts on master branch everyday. „But we can be disciplined! And we can pull branch always when we start working, and…” – ok, yes, you can. But actually, I don’t believe that you will. I propose you a simple mechanism that will give you at least 3 great things:

1. will make your code less conflictable
2. will make your code better (scalable, clear etc.)
3. will make you a better programmer (really, it gives you absolutely a lot of experience)

The mechanism – as I said – is very simple. All you have to have is repository and some mate who can review your code (the best option would be a senior programmer, but it also can be someone with similar experience to yours). Now follow six easy steps:

1. When you start new task always create new branch from master branch (or your default, basic branch).
2. When you finish task, push it on your branch.
3. After that create a Pull Request from your branch to default.
4. Ask your mate to review your code.
5. Treat comments seriously! Change your code when you have to and push it once again.
6. When everything is ok, merge this branch to default.

That’s all! Only a few really simple steps, but you can gain as much as you can imagine.

Be consistent, write clean code

Clean Code is a very popular topic in programmer’s environment. Lets face it – clean code is a huge thing. If you don’t use it yet, you can start with only a few simple rules.

1. Be consistent, always. If you’ve decided to use CamelCase in methods name, use it ALWAYS when you write a method name. If you’ve decided to write comments with description before methods name, do it every time. This habit will help you to write clear, readable code so you (and your mates) won’t have a problem with reading it even after months.
2. Write short methods. If you have a function with 40 lines, there is no option somebody will understand it. If you have too long method, try to divide it into parts (smaller methods).
3. Remove every commented out code before you push branch to repository. Nobody wants to have a mess in the application’s code.
4. DRY (Don’t Repeat Yourself) – you should never have the same code in two places in your app. Why? Because if you will have to change some part of this method, you will have it in two different places. Rather than that, you want to change one line and see effects in whole application.
5. Always try to write down descriptive names of methods. You (and rest of the team) should know what does a specific method do without the necessity of reading its block.
6. And remember to consult all decisions with your teammates, so the code is consistent in the whole project, not only your part of it.

Improve your current method

This is my favorite way to improve my work. This is as simple as possible. Just after writing the method take a short break. After that, sit back down and write the same method once again, but better. It can take a while, but trust me, it will help you and your project. You can say „Oh, ok, but that Pull Requests and Code Review I wrote 5 minutes ago are good!”. Of course, but this trick is so fast and you don’t need second person to help, so just give it a try. You will be surprised with effects it will bring.

Stick to the plan

When you start work, you should define what you will be doing today. Write it down on some piece of paper or in an application of your choice and look at identified goals from time to time during the day. Try to complete the list before you leave the office. You will see few benefits:

1. After few months your work will be more systematic and you will safe a lot of time.
2. When you will start your work next day (or better! after the weekend ;), it will be so much easier! Nobody wants to come back to unfinished work.

Sometimes tasks are too heavy to finish them during one day. Don’t worry! Just split it into smaller subtasks.

Try to crash your application after finishing (Test it!)

Very important but also the most difficult from my „Top 5” (and absolutely valuable). When you finish your application, try to crash it. The better tested app, the grater is its quality. Generally you can use one or more of a several kinds of tests. Here is a few ways to test:

1. Unit Tests. You can write code that will test your methods. This is (in my opinion) necessary. In Ruby on Rails I can recommend you the RSPEC.
2. Integral Tests. It is also a code, but tests the interface by „pretending” to be a user. For example the machine can open up a browser, click through some flow and check if a page element that interests you, exists.
3. Stress tests. Most of the scalability and optimality issues would surface when many testers click through the app on the same server at once, or worse – after releasing your application! There are a lot of load testing tools available at the market, many of them are free to use and open-sourced. They are capable of testing a number of server types. What they do is they generate big load on servers, pretending there are millions of active users at the same time (or fewer, depending on your configuration), and checking if your app crashes in such situation. It can tell you what are the bottle-necks of your app so you can improve them before releasing the app!
4. Just you and your „real-time” tests. Be cruel! It should hurt! Be creative, try to imagine some corner-situation and then check your mechanism.
5. Professional testers. If you have a possibility, don’t think twice. Professional testers have very extensive knowledge and they know how to crush your application. I know, this can be uncomfortable, but it works.
6. Someone from outside your project. When you finish some part of the application, ask somebody to use it. Ask your girlfriend, mate, mother or son. Just let them use your application. I can assure you the effects will be very surprising.

And that’s it! Implementing these five simple rules in your every day work will improve your code and make your life easier 🙂

Have fun & good luck!

My name is Marek Czuma, this is IT-Blog Wolnego Człowieka,

I write to you from Łódź