@benjojo in my last go project at my last job, i banned "if err == nil" from the codebase

made everyone write if err != nil { // pass } else { ....}

@benjojo see also, i used to mandate "if timestamp < timesamp" and always check older < newer in python, for exactly the same reason

@tef @benjojo for me it's always something like I'm measuring something A, and want to compare either a constant or some other value I got earlier B, it's always `if A OP B`.

@tef @benjojo why?

@aljaxus @benjojo the post above the one you're replying to demonstrates the problem

@tef @benjojo I understand that, but one could argue the same to always enforce `if err != nil {} else {}`

I would argue that, at least in my exp. you much more often need to catch error, handle it and return.

compared to other way around where you would quickly get multiple levels of nested `if`s.

What I am asking is why specifically `if err == nil` and not other way around.

'Because I feel like it' is always a good enough answer too, dont feel the need to defend yourself.

@benjojo @tef now that I re-read, I saw that I misred Tef's statement with (somehow) "... I enforce if ..." instead of "... I banned ..."
Sorry for this whole debucle, seems like we're on the same page from the get go.

@aljaxus @benjojo yeah. this is the problem i'm talking about

@benjojo err != nil, my favourite force of habit

@benjojo rust rust rust rust

@benjojo at my very first internship I was tasked with setting up Nagios. Nobody ever bothered to teach me alert tuning. Or testing, really. So I got it running and thought “gee, I bet my boss would like to be notified if there’s a problem!”

So anyway I sent well over 15,000 emails to his Blackberry, which he had to pull the battery out of to get it to stop vibrating.