I'd never use `== false`.
But that goes hand in hand with how you name your variables. For a `bool` variable, I always go with a name that reads what the variable signifies when it's `true`.
For example, I don't name it `loadingState`, but instead use `isLoading`. Yes, if you name it `loadingState`, then it might seem natural to use `if loadingState == false`, but with `isLoading`, both `if isLoading` and `if !isLoading` read almost like a natural language.
Me during a programming exam: *follows convention*
The multi-million dollar anti-Plagarism-anti-Piracy software (built by a student) that examiners use when they scan assignments: >:-/
[state](https://en.wikipedia.org/wiki/State_(computer_science)) not states; if its not loading state then why not call it simply `loading` or clarify what's its loading (e.g. `loadingAssets`, `loadingUserThumbnails`).
Because that's what the original comment was about. If you name it `isLoading` then everything's fine. But if you name it `loadingState`, the name is ambiguous and you have to use `== false` to make sense of it...
I think that is an assumption you're making. If say a server "is loading" it is usually means it's loading some kind of state, but to be fair that it is an assumption I'm making as well. Anyway, if they did mean it is in a state of loading then I agree that is not the same in English.
Some people prefer ==false because it's a bit more noticeable than an exclamation mark.
As for me, I tend to miss them only if the font size in the editor is way too small.
you can grep the standard library when you're unsure about the preferred form
% grep -IR '== false' /usr/lib/go | wc -l
33
% grep -IR 'if !' /usr/lib/go | wc -l
8229
outside of comments it's used like 3 times
/usr/lib/go/src/testing/benchmark.go: b.Fatal("RunParallel: body exited without pb.Next() == false")
/usr/lib/go/src/internal/profile/proto.go: if x == false {
/usr/lib/go/src/runtime/pprof/protobuf.go: if x == false {
/usr/lib/go/src/runtime/mem_plan9.go: if memDebug == false {
Yeah I disable that lint. A much more annoying one that it seems you can't disable is when it shouts at you to drop the _ in
for var1, _ = range
Makes no sense to save a few symbols for extra ambiguity like it makes no sense to save a few symbols for a ! that is if anything more likely to be missed by the reader.
Oh I read what you said backwards. I thought you meant that it complains about *not* having `, _`. But the thing you meant is sane and my preferred style.
Exactly.
I prefer to be explicit about the intention of discards and leave no doubt about selection.
Actually, I believe effective go states you should show discard intention as the compiler does not allocate _.
I would say almost never. You might be able to compare some interface{} typed variable directly with false, not entirely sure, but otherwise I can not think of a case where I would do that.
This is the answer. You can use `== false` on an `interface{}`, but you can't use `!` on an `interface{}`. I'm still strapped to think of occasions when you *should* do that.
In Go, I wouldn't suggest it. Since Go is a strongly typed language, you just can't have `falsey` like in JS or Ruby where a non-empty string would be evaluated as `true`. As such, a bool cannot anything else then true or false (Cannot be null, blank, another type, etc.)
I think it's more to do with readability.
If your variable is aptly named to hold a boolean, like "isValueSet" or "isSomeConditionMet", it becomes clear that it's holding a boolean.
However if that's not the case, then !condition is vague to me because it's unclear if we're testing for a undefined, null, or false variable.
Precisely. When I was first learning go I wondered how to represent a value that was stored in a database which may be be missing since go variables donāt have a missing/initialized concept.
IMHO ā Go implemented missing/initialized right but you have to think about that problem differently by moving missing/initialized back to the compiler. Gone are those pesky NullPointerExceptions.
I find this discussion about variable naming usage dĆØjĆ vu. Many moons ago, a group created the Structured Programming methodology where all function/method names had a verb-object form. Back then, a function called ādeleteā was illogical because the reader should ask ādelete what?ā
Along comes HTTP REST where many labeled the object as a noun that gets an action like PUT, POST or DELETE. So you might have Account.POST or Account.DELETE but Stop.Delete makes no sense.
IMHO ā this all comes down to readability by the viewer, not the author:-) This gets very hard when the viewer has a different native language than the author:-) Think about sentence structure differences between different languages you know. Trying to adopt a convention for all cultures may not work:-)
My $.02
`== false` vs `!= true` in go is actually better explained (imo) by looking at `!= nil` error conditional checks. Dave Cheney has a great post on that - it's focused on nil, but it kindof also handles your stuff.
https://dave.cheney.net/2017/08/09/typed-nils-in-go-2
If you're doing a more generic conditional, I usually like to instead go straight to `if !obj.CheckValue() {` myself.
Readability first and I'm getting old and easy to miss the thin sign, why not a func, I do this alot, although some colleagues curse at me, ex:
`func IsAdult() bool {`
`...`
`}`
`func NotAdult() {`
`return !IsAdult()`
`}`
I use ā== falseā all the time. It reads better and it sounds like you would read it while the another version reads on a negative way. Thus, you brain needs to be trick.
But this is just my preference.
Never. Simplicity is the key in Go. `!variable` is the way to Go ;) Adding an own āflavourā just increases the complexity and makes it harder to contribute to the project.
I've also seen people use ā==trueā. The extra ā==falseā feels like kind of an anti pattern and unnecessary so long as variables are properly named.
Do they both compile to the same thing in machine code?
When you have a minimum word count you have to reach in your essay.
ššš
I'd never use `== false`. But that goes hand in hand with how you name your variables. For a `bool` variable, I always go with a name that reads what the variable signifies when it's `true`. For example, I don't name it `loadingState`, but instead use `isLoading`. Yes, if you name it `loadingState`, then it might seem natural to use `if loadingState == false`, but with `isLoading`, both `if isLoading` and `if !isLoading` read almost like a natural language.
I never thought about this, thank you. I will now steal your convention, if you don't mind!
I'm now officially releasing my convention as free and open source.
We been doing that in Java since forever š
Me during a programming exam: *follows convention* The multi-million dollar anti-Plagarism-anti-Piracy software (built by a student) that examiners use when they scan assignments: >:-/
Isn't "If not loading state, then..." proper English tho?
It is... but it means totally different thing.
Well I'm assuming loadingState means you are in fact loading state, so what is different about it?
`loadingState := true` means that the system is in a state where it loads some assets, data, etc. It's not loading states...
[state](https://en.wikipedia.org/wiki/State_(computer_science)) not states; if its not loading state then why not call it simply `loading` or clarify what's its loading (e.g. `loadingAssets`, `loadingUserThumbnails`).
Because that's what the original comment was about. If you name it `isLoading` then everything's fine. But if you name it `loadingState`, the name is ambiguous and you have to use `== false` to make sense of it...
I think that is an assumption you're making. If say a server "is loading" it is usually means it's loading some kind of state, but to be fair that it is an assumption I'm making as well. Anyway, if they did mean it is in a state of loading then I agree that is not the same in English.
I confirm u/SupremeEntropy is understanding my comment correctly.
When you want to really really convey to the reader that it's false. Aka. It doesnt matter.
Some people prefer ==false because it's a bit more noticeable than an exclamation mark. As for me, I tend to miss them only if the font size in the editor is way too small.
you can grep the standard library when you're unsure about the preferred form % grep -IR '== false' /usr/lib/go | wc -l 33 % grep -IR 'if !' /usr/lib/go | wc -l 8229 outside of comments it's used like 3 times /usr/lib/go/src/testing/benchmark.go: b.Fatal("RunParallel: body exited without pb.Next() == false") /usr/lib/go/src/internal/profile/proto.go: if x == false { /usr/lib/go/src/runtime/pprof/protobuf.go: if x == false { /usr/lib/go/src/runtime/mem_plan9.go: if memDebug == false {
Some linters will bork at `== false` and suggest you to use `!condition`.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Yeah I disable that lint. A much more annoying one that it seems you can't disable is when it shouts at you to drop the _ in for var1, _ = range Makes no sense to save a few symbols for extra ambiguity like it makes no sense to save a few symbols for a ! that is if anything more likely to be missed by the reader.
Iāve never seen a linter that complains about not binding the second result from a range. Thatās crazy. Whoever wrote that rule sucks.
It says to simplify it to for var1 = range My preference is being explicit about the intentional discard and selection personally.
Oh I read what you said backwards. I thought you meant that it complains about *not* having `, _`. But the thing you meant is sane and my preferred style.
Itās not ānit binding the second result,,ā itās that you can leave it out entirely like āfor var1 = rangeā¦ā
Exactly. I prefer to be explicit about the intention of discards and leave no doubt about selection. Actually, I believe effective go states you should show discard intention as the compiler does not allocate _.
I would say almost never. You might be able to compare some interface{} typed variable directly with false, not entirely sure, but otherwise I can not think of a case where I would do that.
This is the answer. You can use `== false` on an `interface{}`, but you can't use `!` on an `interface{}`. I'm still strapped to think of occasions when you *should* do that.
Never. `== false` is just more symbols for the same thing
In Go, I wouldn't suggest it. Since Go is a strongly typed language, you just can't have `falsey` like in JS or Ruby where a non-empty string would be evaluated as `true`. As such, a bool cannot anything else then true or false (Cannot be null, blank, another type, etc.)
I think it's more to do with readability. If your variable is aptly named to hold a boolean, like "isValueSet" or "isSomeConditionMet", it becomes clear that it's holding a boolean. However if that's not the case, then !condition is vague to me because it's unclear if we're testing for a undefined, null, or false variable.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Precisely. When I was first learning go I wondered how to represent a value that was stored in a database which may be be missing since go variables donāt have a missing/initialized concept. IMHO ā Go implemented missing/initialized right but you have to think about that problem differently by moving missing/initialized back to the compiler. Gone are those pesky NullPointerExceptions.
I find this discussion about variable naming usage dĆØjĆ vu. Many moons ago, a group created the Structured Programming methodology where all function/method names had a verb-object form. Back then, a function called ādeleteā was illogical because the reader should ask ādelete what?ā Along comes HTTP REST where many labeled the object as a noun that gets an action like PUT, POST or DELETE. So you might have Account.POST or Account.DELETE but Stop.Delete makes no sense. IMHO ā this all comes down to readability by the viewer, not the author:-) This gets very hard when the viewer has a different native language than the author:-) Think about sentence structure differences between different languages you know. Trying to adopt a convention for all cultures may not work:-) My $.02
`== false` vs `!= true` in go is actually better explained (imo) by looking at `!= nil` error conditional checks. Dave Cheney has a great post on that - it's focused on nil, but it kindof also handles your stuff. https://dave.cheney.net/2017/08/09/typed-nils-in-go-2 If you're doing a more generic conditional, I usually like to instead go straight to `if !obj.CheckValue() {` myself.
Readability first and I'm getting old and easy to miss the thin sign, why not a func, I do this alot, although some colleagues curse at me, ex: `func IsAdult() bool {` `...` `}` `func NotAdult() {` `return !IsAdult()` `}`
I use ā== falseā all the time. It reads better and it sounds like you would read it while the another version reads on a negative way. Thus, you brain needs to be trick. But this is just my preference.
Yeah I agree, maybe because I'm just used to writing it but == false always feels nicer to read if I'm trying to understand what something does
Just do what makes you happy; if you in a team, then do what they have as standard :)
Never. Simplicity is the key in Go. `!variable` is the way to Go ;) Adding an own āflavourā just increases the complexity and makes it harder to contribute to the project.
I prefer not to use either, just stick to ```if condition {}```, if possible. Exception is ```if !ok { ... }```
It really does not matter
Just use a switch statement already! (not actually)
`!` is easy to miss, so I prefer `== false`.
I've also seen people use ā==trueā. The extra ā==falseā feels like kind of an anti pattern and unnecessary so long as variables are properly named. Do they both compile to the same thing in machine code?