22Jan

The missing conversation about anti-if patterns.

Posted by Elf Sternberg as programming

Joe Wright has an excellent blog post about Anti-If Patterns that I naturally believe everyone who write programs ought to read, but there’s a detail that’s missing that I think is absolutely crucial to getting anti-if programming correct.

Types.

Yeah, you can yawn and leave now, if you don’t care. But I’m with Guido von Rossum on this, that once your software reaches a certain size the only way to stave off chaos is to demand more of the programmer up front, and that demand comes in the form of requiring programmers to understand the shape of the data, and to make sure that the pieces being passed between units of code fit perfectly.

Wright glances off the issue in his second pattern, “Use polymorphism instead of switch().” This is a common piece of advice, although it really only works when you have more than one switch statement; at that point, your switch statements are collections of methods that apply to different objects.

It’s his first (Boolean Params) and fourth (Conditional Expressions) patterns where he falls down a little. The most critical issue in both of these is the shape of the data. “Boolean Params” is just “Conditional Expressions” written as a lookup table. If we play the classic programmer exercise of zero, one, or many, a lookup table is a conditional expression taken from the “one” state to the “many” state. It is therefore absolutely critical to put your foot down and state for the record, In any conditional expression, for all sub-expressions, all left-hand values must share the exact same type, and all right-hand values must share the same type.

If this isn’t the case, you’ve created a way to sneak if back into the system, with separate code paths that must be unit tested. And down that road lies madness and unreliability.

2 Responses to The missing conversation about anti-if patterns.

Greg Bell

September 16th, 2017 at 5:08 pm

“although it really only works when you have more than one switch statement”

But one switch statement would still represent one method, right? Or are you saying that’s too simple an object to bother with?

“In any conditional expression, for all sub-expressions, all left-hand values must share the exact same type, and all right-hand values must share the same type”

Can you elaborate on this please? I don’t follow.

In the quest to avoid code that you “have to reason about”, it seems we’ve made perfectly OO code that’s impossible to reason about. Execution paths can only be found using a debugger. Hopefully this was an intentional trade-off.

Greg Bell

September 16th, 2017 at 5:27 pm

“But I’m with Guido von Rossum on this, that once your software reaches a certain size the only way to stave off chaos is to demand more of the programmer up front”

I realize I’m crossing the creepy threshold by posting three comments on your site in one day, but I just can’t help myself. That MIT Technology Review article is so interesting.

Is Guido talking down his baby there? Because demanding “more from programmers up front” sounds a lot like interfaces (contracts) and static typing – two things Python’s missing.

Incidentally, mysql_real_escape_string is gone as of PHP 7.0. In fact, PHP has added so many Java-like “big boy” features and syntax fixes in the last few years that I really think it’s earned respect as a ‘real’ enterprise language.

When I write Python I have the thought “Wow, that’s it? I’m done? It all works?” That’s always amazing.

When I write PHP I think “Right my tests pass, now let’s make this look like the code in the clean code books”.

Comment Form

Subscribe to Feed

Categories

Calendar

January 2017
M T W T F S S
« Dec   Apr »
 1
2345678
9101112131415
16171819202122
23242526272829
3031