I stumbled upon a new word today: Boolshit
I stumbled upon a new word today: Boolshit
It immediately reminded me of code like this:
if myBoolVar = True then
...
else if myBoolVar = False then
...
else
//oh shit!
It immediately reminded me of code like this:
if myBoolVar = True then
...
else if myBoolVar = False then
...
else
//oh shit!
Likely an old mainframe programmer. I used to see stuff like that all the time when retraining them in the 90s.
ReplyDeleteDon't work during the week end!
ReplyDeleteThere is interesting BoolToStr function in SysUtils:
ReplyDeletevar
Boo: Boolean;
begin
Writeln(BoolToStr(Boo), ' = ', BoolToStr(Boo, True));
Writeln(BoolToStr(not Boo), ' = ', BoolToStr(not Boo, True));
Readln;
end.
I can see why you'd call it that, but I am not sure you'd be right in all cases.
ReplyDeleteA loooong time ago, Delphi changed the underlying True and False constants and, overall, Boolean is a fragile type. There is always the possibility that a rogue value is used where a proper value should be.
That said, I'd expect it to be Boolshit in the vast majority of cases.
Andrea Raimondi Actually I didn't invent that name by myself. Someone used it in another forum, but probably just spelled it wrong. It was just that this coding style came into my mind at that moment.
ReplyDeleteAndrea Raimondi "Boolean is a fragile type. There is always the possibility that a rogue value is used where a proper value should be."
ReplyDeleteFUD until you provide some example where this can be (and no, hardcasting something like 2 to Boolean does not count)
When non binary, false = 0, true <> 0. This is standard practice and how it works in a lot of assembly code too
ReplyDeleteby checking the Zero flag.
Chad Hower This is Bool, not Boolean; Boolean true is binary 1 and IMO always been 1.
ReplyDeleteThere are several:
ReplyDelete1) JSON value changed from flag(0 and 1) to multiple values
2) Binary file written using old constants instead of new and never changed for whatever reason
3) Different boolean management across languages with resulting issues (speaking of JavaScript, any value > 0 is considered true, therefore more JSON potential issues).
And it's worth noting that this isn't just a Delphi problem, but one that spans all platforms and languages for which there aren't established rules for edge cases. C and to a degree C++ suffer from the same problem and other languages, too, new and old.
Boolean types are fragile by their very nature because, while modelling them isn't difficult, catching and catering to all edge cases is a nightmare.
Andrea Raimondi For sure when interfacing with other systems and languages you find definition implementations of boolean typing, but the Pascal Boolean type itself isn't 'fragile'. It's the same in Delphi Tokyo as it was in Turbo Pascal 1.0 - a special predefined enumerated type where the fact Ord(False) =.0 and Ord(True) = 1 is (in principle...) an implementation detail (Pascal enumerations in the first instance are ordered identifiers, not named integers).
ReplyDeleteStefan Glienke Datasets that return fields as variants are an example (this actually happened to me).
ReplyDeleteIf a database doesn't support booleans it will use integers instead. Typically 0 is used for false and any non-zero integer is true.
Assigning such a variant to a boolean can result in a boolean containing an integer such as -1 which is not equal to "true".
Arthur Hoornweg That's why one should never compare to True, which actually was the underlying message of my post.
ReplyDeleteSergey Kasandrov No. You are absolutely incorrect.
ReplyDeleteTrue is not 1 when not binary. In fact, -1 is more common.
Bitwise not of $00 is $FF (if Byte), which is -1 as signed.
1 is "true" if a bit.
True is <> 0, and False = 0 and its been this way eternally in CompSci.
This is why "1" and "-1" are the most common values "seen" as true but not the only values. As I said previously, assembly and often compiler generated code uses the Z (zero) flag of the processor after loading or testing a byte (or larger) value and they usually do not bother doing a comparison as it takes extra cpu ops. That is they test boolean by:
AX = (Mov AX)
Check Z/NZ (zero) flag (Branch if zero etc)
Now when it needs toggled:
value = not value
When $00, it becomes $FF (-1). When -1, it becomes $00. If a value of $01, then extra code is needed to do the toggle as not of $01 is $FE, not $00.
You are wrong on Delphi's "bool" too
http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Bool,_false,_true
" A zero value, null pointer value, or null member pointer value is converted to false. Any other value is converted to true. "
Chad Hower: I've seen it much more recently, from people too young to have been mainframe coders.
ReplyDeleteEven if the various bool/Boolean datatypes worked without any problems at all, the real “Boolshit”, IMO, is to compare a boolean variable to anything at all in the first place. If you think you logically need to write:
ReplyDeleteif myBoolVar = True...
Then why stop there? Hey, that's a boolean expression! So, uh, is that expression true or false? Obviously, you need to write:
if (myBoolVar = True) = True...
But then, of course — is that true?!? So:
if ((myBoolVar = True) = True) = True...
And so on, and so on. The real “Boolshit” is to write anything else than
if myBoolVar then...
in the first place. I really don't get what's wrong in the heads of people who write stuff like that, but it feels like it means maybe coding isn't what they should be doing for a living.
Christian Conrad Probably "Code Camp" Javascripters who often are never taught anything but to hack without even learning debugging principles, let alone CompSci principles. The "truthy" crowd where anything can be a boolean according to bizarre and often contradictory rules.
ReplyDeleteChristian Conrad You nailed it!
ReplyDeleteUwe Raabe But wouldn't even a mere "if A=B then..." fail when
ReplyDeleteA contains Boolean(1) and B contains Boolean(-1)?
Arthur Hoornweg Indeed! That's why Christian Conrad pointed that out in cute ironic way.
ReplyDeleteArthur Hoornweg And that is why you always use "if not (A xor B) then" when comparing Boolean variables
ReplyDeleteTorbjörn Olsson Nobody does that...
ReplyDeleteIt would be simpler to use a function assignment when the source of a boolean is unclear (such as a variant returned by a dataset or an Olevariant returned by COM).
Function AsBool(Unsafesource:Boolean):Boolean; Inline;
Begin
if (Not UnsafeSource) then Result:=False else Result:=True;
End;
Arthur Hoornweg You are wrong. Look into System.Variants._VarToBoolean
ReplyDeleteStefan Glienke I dug up my old code and you're right. My problem wasn't the variant conversion from integers to booleans but the other way around.
ReplyDeleteprocedure TForm1.Button1Click(Sender: TObject);
var V:Variant;
B:boolean;
I:integer;
begin
B:=True;
V:=B;
I:=V;
Showmessage(format('"true" became %d',[i]));
end;
Interesting discussion here:
deltics.co.nz - (True = 1) and (True = ‘-1’) ?
Always compare against zero (or not zero). I use "if" a lot, and a dedicated bool type (but I am writing pascal code that ports to other languages that may not have boolean type). That final else? Well, it is valid in some cases (where false is zero, true is a value, and the boolean type could store some other value). Just saying, you code may someday get compiled somewhere else, and the rules change. I remember that happening when moving from Turbo Pascal to using the Windows BOOL type.
ReplyDelete