In the past couple of years I’m reading and learning how to write a better software and all. It’s ok since everyone is doing it. Right?

Wrong. Learn how to do it it not the same thing as do it. Have you ever read this sentence “Any damn fool can write code that a computer can understand, the trick is to write code that humans can understand”* ?

Yes? What are you waiting to do it?

Even if my rants about it can be expressed just with words it’s always better to show an example just in case. Come along with me and let’s get through a little scenario.

Imagine you were kindly asked to create a dialog by your (client|PO|BA|mommy) to save a document. And there you go writing the code to handle it all (events, data, behavior, tests). And there is a crucial point where the user of the software will instead of pressing the save button chooses to cancel it. For your pleasure, your code:

...
file = dialog.choose_the_file_to_be_saved();
if (file == null) {
  do_not_save_the_file()
} else {
  save_the(file)
}
...

One may ask: “what’s wrong with this code?” Your dialog, which might be a system dependent one, returns null in case the user cancel the save. In order to deal with it we simply check for a null. I have to ask you: will your client knows what does “== null” means? No, she won’t.

Here comes what that sentence is all about: write code that your mom will understand. Let’s change it:

...
file = dialog.choose_the_file_to_be_saved();
if (user_cancelled_to_save_the(file)) {
  do_not_save_the_file()
} else {
  save_the(file)
}
...

You may be wondering what is inside this new method? And I show you:

method user_cancelled_to_save_the(file)) {
  RETURN file == null
} 

At this point you may still thinking: what? Creating one method just to check for a null? And I will necessarily answer to you:

-YES!

Do you know why? Your mom? Exactly! Not saving a file is a business requirement. The user will not save the file if she does press the cancel button. And you need to convey this on your code.

The method to check for a null will be hiding on your code and no one will never ever wants to know what is inside of it. I will be well tested, I trust you. Nevertheless, that is what the code is doing, right? At least the contract of these method says it. By the end you have to trust on methods or do you actually go inside your language API and confirm that your “new” method really creates a new Object?

If you wanna learn more about it, here is the link: Domain Driven Design, page 18-19.

* Fowler, Martin