Refactoring Day 26 : Remove Double Negative
Today’s refactoring comes from Fowler’s refactoring catalog and can be found here.
This refactoring is pretty simple to implement although I find it in many codebases that severely hurts readability and almost always conveys incorrect intent. This type of code does the most damage because of the assumptions made on it. Assumptions lead to incorrect maintenance code written, which in turn leads to bugs. Take the following example:
1: public class Order
2: {
3: public void Checkout(IEnumerable<Product> products, Customer customer)
4: {
5: if (!customer.IsNotFlagged)
6: {
7: // the customer account is flagged
8: // log some errors and return
9: return;
10: }
11:
12: // normal order processing
13: }
14: }
15:
16: public class Customer
17: {
18: public decimal Balance { get; private set; }
19:
20: public bool IsNotFlagged
21: {
22: get { return Balance < 30m; }
23: }
24: }
</div> </div>
As you can see the double negative here is difficult to read because we have to figure out what is positive state of the two negatives. The fix is very easy. If we don’t have a positive test, add one that does the double negative assertion for you rather than make sure you get it correct.
1: public class Order
2: {
3: public void Checkout(IEnumerable<Product> products, Customer customer)
4: {
5: if (customer.IsFlagged)
6: {
7: // the customer account is flagged
8: // log some errors and return
9: return;
10: }
11:
12: // normal order processing
13: }
14: }
15:
16: public class Customer
17: {
18: public decimal Balance { get; private set; }
19:
20: public bool IsFlagged
21: {
22: get { return Balance >= 30m; }
23: }
24: }
</div> </div>
This is part of the 31 Days of Refactoring series. For a full list of Refactorings please see the original introductory post.