DEV Community

Cover image for Watch your Coding Manners

Watch your Coding Manners

Christian Vasquez
Lover of good coding practices, martial arts, videogames and chihuahuas.
Updated on ・4 min read

If I were to recommend just 1 book to read to anyone that wants to improve their code quality, I wouldn't even think it twice to choose:

Clean Code's book cover

I'm not a book addict by any means, heck, I still haven't finished many books I was assigned to read while I was in school!

(Sorry mom, but you probably didn't do it either).

But with Clean Code I took it really slow and even jumped from one chapter to another just by selecting the titles that catched my attention. This is probably the #1 reason why I didn't drop it.

Of course, there are parts of it that I still don't quite understand 100%, but the overall reading experience was really pleasant.

One of my favorites quotes from the author is:

Uncle Bob's quote

Whenever a coworker/friend asks me for help with a piece of code, the first thing I notice is their code structure, how "good" does it look from far away.

There are many things that can be noticed from a few feet away:

  • Curly braces position.
  • Line length and breaks.
  • Indentation levels.
  • Bad Comments.
  • Number of parameters.

Our eyes can detect all these details because of the Gestalt Grouping Principles

Now, I would like you to follow me while we repeat each item with an increased font size:

Curly braces position

Depending on your background, you may be used to doing either

// C#, C++, C...

public void CoolFunction()
    // Something cool
Enter fullscreen mode Exit fullscreen mode


// Java, Kotlin, JavaScript...

public void anotherCoolFunction() {
    // Something even cooler
Enter fullscreen mode Exit fullscreen mode

And whenever I bring this up, the usual response is

"I'm just more used to X style, Chris!" - Imaginary person

Yeah, I get it. But I don't think this is valid reason/excuse. Whenever your code gets pushed to master it is no longer yours. It belongs to the team.

So, we will have to sacrifice our habits for the greater good:

A codebase should look like it was written by only one person.

Line length and breaks

Line length

There's a general rule of thump that says that each line shouldn't be longer than ~80 characters. Which brings us to...

Line breaks

You may have seen code that looks like this:

// Java

SomeBuilder builder = new SomeBuilder();
Enter fullscreen mode Exit fullscreen mode

This can easily get to pass the 80 characters length, so in order to improve readability we can use line breaks:

// Java

SomeBuilder builder = new SomeBuilder();
Enter fullscreen mode Exit fullscreen mode

oh yeah

Yes, it will make your code have a few extra lines overall, but your eyes will thank you later. Now we can read each statement like if it were a list.

Indentation levels

This is probably one of the most common scenario.

Let's say you have to verify some conditions before you do something, like:

// Java

Girl girl = new Girl("Carly Rae Jepsen");
if (girl.isPretty()) {
    if (girl.isTheFlashFan()) {
        if (girl.isGeek()) {
            if (girl.isGamer()) {
Enter fullscreen mode Exit fullscreen mode

I may or may not be listening to Call Me Maybe right now...

We can change this by making a boolean variable that will hold an expression that can replace all the ifs:

// Java

Girl girl = new Girl("Carly Rae Jepsen");
boolean isTheChosenOne = girl.isPretty() && girl.isTheFlashFan() 
                         && girl.isGeek() && girl.isGamer();
if (isTheChosenOne) {
Enter fullscreen mode Exit fullscreen mode

Call me

Not only are we able to make our code more expressive, but also minimize the mental load of the readers of our code with this type of changes.

Bad Comments


Before you go down to the comments section and blast me with your infinite wisdom, you gotta admit that there are some comments that are just bad.

// Java

// Returns name
public String getName() {
        return name;
Enter fullscreen mode Exit fullscreen mode

The method already expresses what it does (specially when you can see it is a Getter method just by it's name).

Getter methods usually follow the get<Something> naming convention.

Good comments should say why something was made that way or at least be informative, rather than saying what the code does. If you can remember that, your commenting game will be 🔥.

// Java

public void complicatedAlgorithm() {
    // This is our best attempt to solve ticket #12345,
    // for more information, please refer to

    // ...
Enter fullscreen mode Exit fullscreen mode

Number of parameters

If you find yourself writing functions/methods/constructors with 2-3 or even more parameters, there's a high chance that you may be able to abstract away some of them with a class that can represent them even better.

// Java

public void moveTo(double x, double y) {
    // ...
Enter fullscreen mode Exit fullscreen mode

We can extract a class out of these 2 parameters and call it Point.

// Java

public class Point {
    private double axisX;
    private double axisY;

    public Point(double axisX, double axisY) {
        this.axisX = axisX;
        this.axisY = axisY;

    public double getAxisX() {
        return axisX;

    public double getAxisY() {
        return axisY;
Enter fullscreen mode Exit fullscreen mode

Then we can refactor our moveTo() method to this:

// Java

public void moveTo(Point point) {
    // ...
Enter fullscreen mode Exit fullscreen mode


And we just scratched the surface, there are plenty of more ways to improve your codebase. But this is the part where I encourage you to read Clean Code to find out by yourself 🤓.

Discussion (4)

codemouse92 profile image
Jason C. McDonald


Yes, comments should describe intent, not restate the code. Well done.

chrisvasqm profile image
Christian Vasquez Author

Thanks Jason! I'm glad you enjoyed it.

jfrankcarr profile image
Frank Carr

"Whenever your code gets pushed to master it is no longer yours. It belongs to the team."

A common thing that happens in dysfunctional teams is the "My Code" syndrome where someone takes offense if code they think belongs to them is changed. Some programmers can get quite vindictive about it and resort to sabotage and other underhanded office politics to get the 'offender' back.

alvarocavalcanti profile image
Alvaro Cavalcanti

Regarding comments, I have never liked them much, but was hard to reason about it. Until I've read this article, where Mr. Fowler speaks clearly why we should avoid having comments in our code.

I've put this advice in practice several times now and my co-workers have thanked me a lot, as everyone now is improve our code base readability little-by-little.