3 ms·
I agree the check_foo() duplication was bad, but was this workaround really so bad? while 1: foo = check_foo() if not foo: break do
by mehrdadn 8y ago
I agree the check_foo() duplication was bad, but was this workaround really so bad?
while 1:
foo = check_foo()
if not foo: break
do_foo(foo)
Its only downside was taking 2 extra lines, not actual understandability.
- int_19h 8y agoIt makes the intent of the loop less clear, since now the condition is tucked away somewhere in the middle of the body, even though it's really a precondition.
- mehrdadn 8y agoI'm torn on this, because although it's easy to say that for a toy example like this, when these "preconditions" evolve over time, you get things like: while 1: now = time() if now > prev_time + UPDATE_TIME: report_progress() foo = check_foo() if not foo: break if foo < 0: print_error(); break do_foo(foo) prev_time = now Now, was it really dictating a precondition? Or was it actually dictating a postcondition? Or both or neither? Would you really want these responses to dictate the locations of the condition in the syntax? Because it seems to me that forcing yourself to put these conditions in the loop condition just makes the code extremely ugly and difficult to evolve (requiring you to duplicate code or have very convoluted expressions with assignments).