• snoofle (unregistered)

    I've seen a few not-allowed-to-fix-it-because-the-data-is-imported-from-other-systems "boolean" database columns defined as "varchar(255) null" which made this exact sort of nonsense necessary in order to protect the innards of the application from string-booleans

  • (nodebb) in reply to snoofle

    At point of import the data should've been cleaned and converted as needed. Maybe this consultant didn't screw up on this one thing, but some other consultant did when importing the data.

  • Raj (unregistered)

    Maybe it's like yaml, where Yes and ON are true, but "Yes" and "ON" are strings.

  • Whatever (unregistered)

    Boolean.parse won't replace the sample code because it only looks for System.TrueString and System.FalseString, and throws an exception if the string doesn't match either. Sure the code is ugly, but don't go acting all smug by suggesting a fix that ultimately is naïve and invalid.

    However The TWTF is the DailyWTF for using dodgy syntax highlighting that doesn't seem to correctly highlight the strings in the false case.

  • (nodebb)

    This routine is completely unfair to true. The defaultValue should be randomized so true gets a fair chance.

  • snoofle (unregistered) in reply to Mr. TA

    You're correct.

    Normally it sh/would be sanitized on import, unless it's dumped by the sending team, and they won't sanitize it. That only leaves either a) running a sanitize-job after import and before the using-program, or b) sanitize on query. With DBs with 10 billion rows and regulatory time constraints, it usually winds up as the latter.

    YMMV

  • mmisingnamea43 (unregistered)

    Actually I've written code just like that for parsing config files. If a config item is not given, use the builtin default. Depending on the name of the config item, it is sometimes more natural to use on/off, sometimes yes/no, sometimes true/false and in some cases even 0/1. I also wrote a string-to-number where off/false/no/0 yielded 0 and on/true/yes/1 yielded 1, because at one point a setting that was boolean was changed to int, but forcing the user to update configuration on software update should be avoided if possible.

  • (nodebb) in reply to Whatever

    This. The built-in type converters have a few corner cases as well. Like nulls. Is null really false or zero?

    The default value isn't a WTF either (although I'd return it inside of a catch block). Sometimes you just need something to display. Sometimes null is effectively false or zero.

  • Foo AKA Fooo (unregistered)

    I see no WTF here, without further context. The values might come from a user-editable config file which may be required to accept exactly these values (I've seen such files) rather than whatever the built-in method recognizes.

    The error handling is questionable, but again without context, it may be just fine to use a default given by the caller for each flag.

    Sure, the whole thing could have been written much more compactly with regular expressions and ternaries, but as everyone knows(TM) these are evil(TM) even when they're not.

  • KZilla (unregistered) in reply to Whatever

    From the article: 'The consultants wrote the module which set the flags, and guaranteed that the flags were only ever "true" or "false".'

    So really, in this case, the correct solution was just to use the bool.Parse method. And if that wasn't true, these highly paid consultants still screwed up, since they couldn't even follow their own requirements.

    Either way, it is still a WTF .

  • get off my lawn (unregistered)

    If you don't have the opportunity to restrict the input then you have to do something like this. Possibly cleaner code could be written, but calling it a WTF is the real WTF.

  • RickSanchez (unregistered)

    TryParse is better: https://docs.microsoft.com/en-us/dotnet/api/system.boolean.tryparse?view=netframework-4.8

  • (nodebb)

    best way to replace the complete string-to-boolean-dilemma:

    return StringToOrdinalValue(value) %2 == 0;

  • sizer99 (google) in reply to KZilla

    Since they made the dumb decision to store a Bool in a string (the root cause here) you will inevitably end up with someone putting a 'yes' or '0' in there. Basically, unless it's enforced by the database it's not a guarantee it's just a verbal agreement with a wink and a nod from your used car salesman. So you can either decide that the thing crashes when someone does that (maybe that's the right move) or you parse it defensively.

  • (nodebb) in reply to mmisingnamea43

    Yeah, this could just about be lifted from the program I'm working on right now. It's reading a config file, and has a range of truthy and falsey values that a human might have put in there. The only difference is that it squawks rather than uses a default if it finds something it doesn't know.

    Yeah, this was supposed to be from a clean source. Does truly clean data actually exist?!

  • sizer99 (google) in reply to Loren Pechtel

    'Does truly clean data actually exist?!'

    It can, for an instant, as long as you never let anyone write to it ever again. Or as long as you enforce everything with constraints.

    This whole problem is because they're using a string to store a bool. If you made it a database bool (int if you have no bools) then the database handles the enforcement, the problem vanishes. If you want to limit something to 8 choices, then you make a database enum and nothing else can be present. For a database that lacks enum, you can make it a table with a unique KEY then 'constraint thisCol_type FOREIGN KEY( thisCol ) REFERENCES thisColTypes( id )'

    In your case you're just hosed because as soon as you have meatbags editing a config file, forget it.

  • (nodebb)

    Truth? Do it the way Fortran does it. When accepting logical inputs (true/false), if the input starts with 'T', the value is TRUE, otherwise it is false.

    Don't like that? Tough!

    Sorry, no "File Not Found".

  • löchlein deluxe (unregistered)

    Needs more any(map(…)) with a configurable list of yesish and noish strings. (Yes, I know truthy and falsy are already a thing. Conventions are great, there are so many to choose from.)

  • Little Bobby Tables (unregistered)

    Ho hum. No big deal. We do similar with our integration to our decades-old back end, where for any particular table the convention for "true" and "false" can vary considerably -- usually "Yes" and blank for true and false, sometimes "Yes" and "No", sometimes "Y" and blank.

    If you know the table and are familiar with how it holds its booleans, you can write a custom rule to convert to a standard form in the front end (for example, java booleans if your front end is a java app, whatever else if it's not), but it may in fact be easier just to write a "one size fits all" converter a bit like the one in question rather than carve one to size for each integration. Granted, our implementation is a bit more sophisticated than the one given here, and has more parameters to pass in so you can fine-tune it, but it's ultimately the same technique.

    The fun comes when you want to write the data back out to the oh-so-finicky back end which will accept data only in its specified format, so if you pass "No" back when the falsy option is blank, the integration crashes.

  • Everwhat (unregistered) in reply to Whatever

    I assume you wrote the code in the article.

  • (nodebb)

    "TryParse is better:"

    No, it's not. Every built-in TryParse has that awkward syntax with the out parameter that forces you to declare a variable beforehand. That's how you get manure like this:

    bool b = false; if (tryparse(something, out b)) { if (b) { dosomething(); } }

    When what you really need is: if (SafeToBoolean(something, false) == true) { DoSomething(); }

  • James (unregistered) in reply to Zenith

    Recent versions of C# make it a little nicer:

    if (bool.TryParse(something, out bool b)) { if (b) { DoSomething(); } }

  • (nodebb) in reply to Zenith

    TryParse allows throwing a better exception than Parse throws, like, say, "The value of the setting FooSetting is {0}, which cannot be parsed as a Boolean."

  • LaughingItOff (unregistered) in reply to Whatever

    Agreed, you cannot trust the string to always either be "true" or "false" and TryParse would be the way to go. This would also mean using a tristate, meaning a boolean allowing NULL for all edge cases, unless you want to err on the side of false?

  • Anon (unregistered) in reply to Foo AKA Fooo

    Config files should not be directly edited by an end-user. Let the installer, or a "preferences" UI set the values. If somebody modifies the config file manually, and doesn't bother checking what values are acceptable, they deserve what they get (i.e. an exception and application crash when the value fails to parse).

  • Wizofaus (unregistered) in reply to Zenith

    Since C# 7 at least that has not been true, you can declare the variable as you name it: bool.TryParse(value, out bool boolValue)

  • gidds (unregistered)

    I'm surprised no-one's mentioned Postel's law: "Be conservative in what you do, be liberal in what you accept from others."

    The WTF code embodies that principle. It may not always be the best approach (and many have criticised it since), but in an imperfect world it may often be a good compromise. And with ample precedent, it doesn't really seem WTF-worthy.

  • Foo AKA Fooo (unregistered) in reply to Anon

    Nope. Don't limit the user's choice how to edit their configuration (editors, versioning, probably also a "preferences" UI, but only as an option, not as a requirement). Not all users are stupid and want/need to be restricted. (The "user" may be the DBA, or it may be a competent person who just happens to be a end-user of this software at this moment.)

    What they deserve on invalid input is a proper and specific error message (which setting in which config file is invalid), not a "general error" and certainly not a crash.

  • Wumpusarama (unregistered)

    The TRWTF is they forgot -1.

  • Matosawitko (unregistered)

    ON = true NO = false

    Makes perfect sense. No danger of a transposition error here.

Leave a comment on “Be True to Yourself”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article