Sep/10

27

Making Boolean parameters readable

Recently I was watching a video from Uncle Bob (aka Robert Martin) about craftsmanship and ethics in which he was saying the following:

Do not pass boolean parameters to a method or I’ll find you!

Why? Cos you probably won’t understand following lines of code:

this.DeleteCustomer(true); //what does it mean "true"?
//or even more triky
this.HiglightText(true, false, false);

So while looking on above method calls you will need to hover your mouse or press some hotkeys to get information about signature and actual meaning of parameters. And it works only if you are watching you code through IDE. Boring isn’t it?

Lets assume that first method has the following signature:

public void DeleteCustomer(bool onlyMarkAsDeleted);

Instead of doing this I prefer split this method on two, where each one is more explicit:

this.DeleteCustomer();
this.MarkCustomerAsDeleted();

This is possible only if you own the code, so you are able to perform such refactoring. In other case I prefer to go with one of the following ways:

Define a local variable with a meaningful name and make value assignment right in method call:

bool onlyMarkAsDeleted;
this.DeleteCustomer(onlyMarkAsDeleted = true);
//for the "false" case
this.DeleteCustomer(onlyMarkAsDeleted = false);

Disadvantage: It can be not obvious how it works if you see this for the first time. You just can forget that a result of Boolean value assignment is also a Boolean equal to value assigned.

Define a local variable with a meaningful name and make value assignment before method call:

bool andMarkAsDeleted = true;
this.DeleteCustomer(andMarkAsDeleted);
//for the "false" case
bool doNotMarkAsDeleted = false;
this.DeleteCustomer(doNotMarkAsDeleted);

Disadvantage: This approach requires more care in choosing variable names, this can go tricky sometime.

I think both are a lot more readable and will save a lot of time in future. Surely .NET 4 Rocks with named arguments:

this.DeleteCustomer(onlyMarkAsDeleted: true)

Please, follow these rules or I’ll send your home address to Uncle Bob =)

RSS Feed
  • http://cotoha.info/ COTOHA

    ты всегда можешь менять код, а значит можешь определить и второй “правильный” метод. (хотя бы как экстеншн-метод). да – при этом старый метод _может_ использоваться “неправильно”, но читабельность улучшится

  • http://www.T-L-K.com TLK

    I pretty much like the first way you’re using, but don’t like the following case:

    bool doNotMarkAsDeleted = false;
    this.DeleteCustomer(doNotMarkAsDeleted);

    This is looking like variable ‘do not mark as deleted’ is set to false, an customer _should_ be marked as deleted. But it is not what is really performed in code.

  • http://restuta.net Restuta

    2 COTOHA Нет, не всегда. Что делать если это 3rd party lib или метод из FCL?

    2TLK Yepp, thats why I wrote that this is going tricky sometime =)

  • http://cotoha.info/ COTOHA

    extension methods отменили? :) насколько я понимаю, ты можешь их присобачить и к 3rd party lib и к любому классу из ФЦЛ.

    короче, было бы желание…

  • http://restuta.net Restuta

    Можно присобачить, но для такой задачи плодить дополнительные расширения – по воробьям из пушки. Это очень утомительно. Если же API полностью корявое – лучше написать фасад или адаптер и сделать под себя.

  • http://slynetblog.blogspot.com/ Sly

    Кстати вариант с экстеншен методами мне нравится. Довольно хороший выход тем более не надо менять старые вызовы

  • http://restuta.net Restuta

    yep, this is a tricky part ) I also don’t like second way of doing this, probably it was a bad idea to write this example without pointing that  this is “how you shouldn’t use this”

blog comments powered by Disqus

<<

>>

Find it!

Theme Design by devolux.org