This is in line with 'guard clauses' and this is why it is accepted as idiomatic code.

For this example we only have a single condition but as soon as you add more conditions it start to get out of hand.

I prefer the original code because it makes the codebase as a whole easier to read. But I don't think there are any 'hard facts' to support using either of these styles over the other in these simple cases.

There is one simple hard fact: shorter code is faster to read and understand, period. If someone doesn't understand what the result of `o != Unknown` is then they should probably go back and read more about programming. Sorry to sound a bit condescending.

I would’ve written a shorter letter if I had more time. I’ve also noticed people don’t want to think through Boolean logic enough to write things legibly. Or the other extreme is way too many Boolean operators on a line where it gets very hard to parse. Even worse when there are multiple cases like that in one function

That's clearly not true, and one of the primary design choices Go makes. It trades concise code for more readable code.

A good linter can help people see where their code isn't concise and give nudges toward better style. Clearly, being concise can sometimes mean being opaque, but in this case it's not, the boilerplate dilutes the meaning without adding value.

Go was developed as a highly opinionated language in which this style of imperative code is apparently preferred. Similarly, the ternary operator shines as a way to use a single assignment to obtain a value that follows from a concise boolean expression, but the ternary operator is wholly omitted from Golang.

Although, being opinionated is not in itself a bad thing. If you want to create something, it helps to have a viewpoint that gives you something to say.

I think it depends on your definition of "clean code". I do personally like the more succinct version, but "never use a negative condition" makes people do.... stuff like this

Hey did you read to the bottom of the article. It shows that that was just a temporary solution, the real invalid code is

func (t operation) IsValid() bool { _, ok := strOperationMap[s] return ok }

Tbh it has been updated to us an array instead for string indexing.

They don't use linters either.

Most people aren't good programmers. And most also don't make a concerted effort to improve.

Sorry to say, but that's the simplest truth. Many go years and years in this industry with little improvement to quality/succinctness/readability. If you cared, and tried, you would.

Programming skill is uniquely distinct from domain knowledge, by the way. e.g. all of the research code written by domain experts that is full on spaghetti.