6 simple rules to write more clean, readable and editable code

I have almost 5 years experience in writing code. I wrote a bad, terrible, good and beautiful code. Of course, on the begging my code was’t good — I wrote with no classes, objects, architecture planning etc.

But now, when I wrote millions (or billions?) lines of code, many big projects for desktop and web developing, learned OOP, used SQL and no-SQL databases, I know how good code should looks like. I want to give you few simple tips which make your code minimum one level higher. It’s important to everyone to create a good code — it’s better for you and for programmers who will get your code.

1. Write in the same style the whole project

It’s very simple rule. When private attributes or methods have underscore prefix — use underscore for every private attribute or method. If you use camelCase, use it everywhere. Your variables have plural names or have not?

When you have defined a style, you haven’t problems when you don’t remember exactly what is the name of variable/metod/class.

2. Elements order in classes

It’s related with previous rule. I keep this order in my classes:

  1. constants
  2. abstract methods
  3. attributes
  4. constructor
  5. getters and setters
  6. other methods

When I want to quick check something (for example abstract methods) from the above list, I haven’t any problems with that, because I know where to exactly looking for. In a simply way I can check if the specific method exists in the class without [Ctrl] + [F] shortcut.

3. Your method should have only few lines of code

When your method contains only 4–5 lines you can easy understand what this method do. Moreover method should do only one thing: login user, send email, write something to a file, fetch rows from db, etc.

When your method is too long, probably it do more than one thing. So you need to split it.

4. There are only two types of methods

This types are command and query.

Commands methods do something with data (updated, inserted, deleted). This type of methods modify state of a object.

Queries methods ask about something and don’t change the object’s state. This kind of methods just fetch data or check something and returns boolean value.

If your method can be names as command and query method, you must refactor it.

5. Avoid “deep” code

Imagine code when you have a lots of ifs and loops. Some part of code is very deep and you must scroll your IDE horizontally. Almost always you can change your code to have less deep lines.

For example this:

function a() {
if (condition) {
        ... part A ...
} else {
        ... part B ...

can be replaced this

function a() {
if (condition) {
        ... part A ...
    ... part B ...

It’s simpler to read and understand. In the future I will write a whole article about more tips how to constrict a code.

6. Use OOP everywhere

OOP is just a set of patters for developers how to write a code. This patterns solve many problems and are tested by a lots of developers. So it’s save to use. Of course there are bad patterns named anti-pattern. You should never use anti-patterns.

Event if you are the best of the world expert in object programming, you must know popular patterns. Imagine that you wrote in the same way parts of code in many projects. Many programmers think in the same way as you, so they solve this problem in the same way. In no-OOP world when you want to tell how you have written it, you should say “I wrote this code in this way… I did classes… I wrote methods… This references here and here…”. Many words and sentences. Thankfully we live in OOP world so you can just say: “I used the factory pattern” and everybody know how you wrote this.

There are my 6 rules. I think every programmer have his/her own rules. Feel free to share in comments.

Thanks for reading!

Like what you read? Give Szymon a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.