My 4 rules for writing clean code

One of the most valuable skills of any developer is writing clean code. Languages and frameworks put you into certain frames, but when it comes to writing quality code, you need to put the frames yourself and show some self-discipline. Bad code still compiles, that’s why some devs don’t pay too much attention, as long as they can get the program to work.

There are a ton of books and content on the internet with different rules and practices you can follow. They are great as long as you have clarity of what you’re building, but often specs are changed or some parts of the codebase need to be changed. That’s exactly when code starts to stink. Stitching up those classes really gets you frustrated, you just want to get it all to run and call it a day. Refactoring can wait, you can do that tomorrow. Unless of course, some urgent fixes need you attention and you forget about it.

It’s hard to write proper code under liquid conditions, that’s why I created a set of rules that I follow in my everyday coding, to alleviate myself of some trouble when refactoring.

Keep Indentation low

What are the main pieces of code that you write every day? Loops, conditional statements, try — catch blocks and so on. Really often, those have to be nested — you have a conditional statement, to check if validation passes, then you’ve got a loop going through all of the variables. Inside that you’ve got another conditional statement to see if you’ve reached a certain variable in order to mutate it’s value. This happens too often and leads to your code looking like a Christmas tree.

Having high indentation leads to confusion and developers won’t be able to logically separate code at first sight. Not to mention block scoped variables if you’re writing JS. Keep your indentation low when possible, separate logic into other methods and re-structure when able. Here’s something that I like to use in my everyday coding. Instead of writing validation like this (pseudocode follows):

if (validation.isSuccessful()) {

    // do sth.

} else {

    // do sth. else

}

I do it like that:

if (validation.fails()) {

    // do sth.

    return response

}

// do sth. else; if it reaches here, validation was successful

Order your code

I don’t have to tell you how important code structure is, both horizontal and vertical. I never leave more than one blank line to logically separate code. If you have to clarify something, use a comment, but jamming 2–3 blank lines to separate logic definitely calls for making another method just for that. Code gets harder to read and keep track of what you’re looking at.

As for horizontal structure, avoid lines that are too long, but at the same time don’t try to fold everything into less space than it should have. Don’t spare those extra bytes and leave a space before different operators.

Manage method length

I’ve read a lot about how long methods should be and when you should split them. Many people say that a method should be short enough to be able to fit it into the screen without scrolling. The rule that I follow is that a method should do a single thing — whatever it’s name says it does. Yes, whenever a method is storing something into the database, it’ll probably be longer. You need to validate input, prepare queries, execute them and handle errors. Leave the most specific parts of the method in itself and abstract everything else. That allows you to keep methods shorter and reuse the common functionality. Bonus points if you manage to keep the flow of the class, so you don’t jump too much from method to method

Don’t leave dead code

How many times have you gone through someone else’s code and you’ve seen commented blocks. Just standing there, keeping up space. Have you deleted them? Most probably not, after all you don’t know why they’re there. You don’t know if they were temporarily commented out, because they’re not deleted, so you might as well not touch it.

Whenever you comment out code with the intent to delete it later, please do it immediately. In 99% of the times you won’t need that code again, don’t worry about that. Even if you do, we have complex version control systems that take care of keeping your old source code safe if you decide to use it again.

Thank you for the read, I’ll end my rant here. Take a look at my other articles if you want to read more of my thoughts on coding.