How do you know your code is bad?

Bob — Sun, 23 Jul 2017 14:01:14 +0000

The other day, I was watching this video of Robert Martin where he mentions the three symptoms to spot a bad code. And I couldn’t have agreed more.

1. Rigid Code

Your code is rigid if you can’t change a piece of code without changing the other modules that are irrelevant and have no relationship to the code you try to change.

Rigid code is the code that has dependencies that snake out in so many directions that you cannot make an isolated change without changing everything else around it. — Robert Martin

For instance, you try to change some low-level detail in the data layer, and all of a sudden you get a compile error in the class that does the formatting for your View.

If you often find yourself touching almost all the modules of your project, whenever you make changes in a single class, it might mean a symptom of rigid code.

2. Fragile Code

Fragile code is a lot worse than Rigid code. At least we get a compile error in a rigid code.

In fragile code, if you change a small piece of code in a module, you break an entirely different feature in an entirely different module. And there is no easy way to find these errors during development.

Fragile code breaks in bizarre and strange ways that you cannot predict. — Robert Martin

If you often get customer tickets saying a feature is broken, whenever you push a fix for an entirely different use case, it might mean your code is fragile.

3. Non-reusable code

Non-reusable code is, as the name suggests, the code that cannot be reused.

For instance, you might want to implement a feature in your project that is the same as the one your colleague has done for a different project. But you cannot easily reuse the code from that project because that code depends on some other irrelevant feature of their project which in turn depends on some framework or database system which you don’t want in your project. And you better off writing your own implementation for that feature.

This is the famous Gorilla-Banana problem:

You want a banana but what you get is a gorilla holding a banana and the entire jungle with it. — Joe Armstrong

How can we avoid these 3 flaws?

When you write code, ask yourselves these questions:

Is this code too rigid? Is it possible to change the internals of this module in the future without touching the code in other modules and other layers?
Is this code too fragile? Will it be hard to find all the places to refactor for any changes in the future?
Should this feature be reusable? If so, does this code depends on any unwanted modules or frameworks that can be avoided?

If we look closely, the common thread of all the above three problems is coupling. The modules depend upon each other in undesirable ways and that results in spaghetti code.

The code should be decoupled across the modules and layers. High-level policies and the abstractions should not depend on low-level details. Invert the dependency of the modules at the necessary places. And write classes that do only one thing and have only one reason to change.

Good code should explain what it's doing. It should be boring to read. Everything is perfectly obvious. That is good code. — Robert Martin

Also published in my Medium publication.

Use Optional / Nullable Reference Types Judiciously

Bob — Sun, 16 Apr 2017 09:17:41 +0000

Languages such as Swift, Kotlin has a distinction in the reference types — Optional and Non-Optional references or Nullable and Non-Null types — where only an Optional or Nullable type can hold a nil or null reference.

Java SE 8 also has support for Optional, but the difference is that in Swift and Kotlin a normal field cannot hold a null reference. It has to be declared an Optional type to hold a null. Java is not that strict that it allows null reference to normal fields also, but it is possible to write better APIs in Java also using Optional.

All these type systems try their best to avoid the null references — the billion dollar mistake as the inventor of null reference Tony Hoare called it.

If you are switching from a language that doesn’t have Optional — like Java 7 or Objective-C — to a language that supports Optional, chances are that you merely translate all your fields to Optional. But that’s not a very good practice.

It is very important to understand what problem this Optional type solves. The advantage compared to the normal null references is that the Optional types forces you — or the client of your API — to think about the case when the value is not present.

That’s it. By declaring a field as an Optional you declare that it is possible that the field can be empty and it makes the clients of the API handle the empty value case.

Let’s assume there is a class, Customer and it has two fields: customerId and customerName. And for any customer, these two fields cannot be empty, logically.

If you declare these two fields as Optional, you declare that these fields can be empty. And this creates a potential for having a customer object in an invalid state in the runtime — that is a customer object that has empty id or name but which cannot be empty based on your business logics.

Having an object in an invalid state is more dangerous than a Null Pointer Exception as the invalid object will not crash your app but make your app behave in a weird manner and it is very hard to debug the cause.

So think hard before declaring a field as an Optional whether that field can be empty logically. If some fields cannot be null based on your business logics, don’t declare it as an Optional. If you need to declare some field that cannot be null logically as an Optional for some special use-cases, you may first have to think of other possibilities or restructuring your code rather than using Optional as the first choice.