[IshKebab]

> `do_thing if other_thing`

Yeah I don't get why you would deliberately make the flow control confusing and backwards like that. Python list comprehensions are the same. They make the information flow backwards.

This also has the effect of making nesting really confusing.

[gls2ro]

For me this fits more into how I think or how I say things in my mind.

It might be that I am not an english speaker, but for example when I say to someone a list of instructions I usually say it like this:

"Add more water if the dough is dry"

and I don't usually say

"If the dough is dry add more water"

The same for saying for example:

"stop mixing if the dough is starting to tear"

or

"put the bread in the oven when it is ready"

[greenpeas]

> > `do_thing if other_thing`

> Yeah I don't get why you would deliberately make the flow control confusing and backwards like that.

I like to use this as function guards, where the first lines in the body of a function can be:

  return xxx if some_edge_condition?

example: https://github.com/rails/rails/blob/f95c0b7e96eb36bc3efc0c5b...

[cycomachead]

Guard clauses are great, and when used appropriately clean things up. This is pretty much my only use of the pattern.

(Ending boolean-returning methods with a ? is also a great convention in ruby.)

[bobbylarrybobby]

if some_edge_condition: return x

[msbarnett]

I’ve written both professionally and personally found Python makes it harder to see the early out, which makes it less valuable/explicit as a guard.

The Ruby pattern is clear up front on what it is rather than being a bag of conditions that you have to get to the end of to discover what they trigger.

[mypalmike]

It's even worse when you combine the two complaints:

do_thing unless other_thing

Which of course you find in many Ruby codebases.

Python list comprehensions seem less painful to me because they read almost like the WHERE clause in SQL simple SELECTs. Definitely not the most straightforward thing one encounters in Python though.