I couldn’t remember who said that one of his favorite refactoring techniques is Replace Nested Conditional with Guard Clauses. When I looked into it, it did put a smile on my face despite its simplicity. This is NOT about coding aesthetics, this is all about clarity. A method has conditional behavior that does not make clear the normal path of execution. Use guard clauses for all the special cases.
Refactoring
It is very common in relational database that we have the following structure: A customer table has columns: customer-id, name. And an order table has columns: order-id, customer-id, order-date. See that there is a customer-id in the order table, so that we can use it to get orders belongs to a certain customer. But there is no knowledge about the orders in customer table. This is fine with database, but if we try to map this directly to java classes, we may end up with something like this:
This is from the famous Refactoring book by Martin Fowler. When I was reading it, it feels very similar to the very popular MVP or MVVM. The key idea is that in system that has user interface, the business logic should be separated from the user interface. One example I can think of is the registration form, where there are input fields like username, email, phone number and password. We can have some logic that disable the Register button until all fields are filled and the phone number and email valid.
