Comment On "True" and True

insert into comments values ( "frist".toString() );

I strung together the frist.

trwtf is that there is no empty finally block.

Severity One:

insert into comments values ( "frist".toString() );

I think you meant

insert into comments values ( new String("frist").toString() );

captcha: bene ... no, not really

label.Text = GetString("SettingsUpdated")

WTF, lol. I hope this actually updates it with 'The settings have been updated' instead of just a straight 'SettingsUpdated'.

It's brilliant! No type mismatches, and just think how easy it would be to migrate the application to XML! It has the makings of Enterprisy.toString() written all over it!

(Commented edited because it was virtually identical to the one before, even though I am not the same person.)

When you have to do something like this to make your program work (and therefore disable half of the fundamental programming-flaw/error checking in, y'know, every modern programming language) you know something is very wrong.

I guess I'll get it out of the way...

...he's coding it so one day if there's a "File_Not_Found" state they can easily just add that in.

The real WTF is that he doesn't do anything with the catch block, am i right?

CAPTCHA: bene - A french food. bene

exel:

Jimmi:

it's also worth noting the fact that the datatype to store the true/false values is nvarchar(5). What could possibly go wrong?

Well, for starters, FileNotFound will not fit in 5 characters.

Shorten it to fnotf. Clearly readable, and speaks for itself. And fits in 5 chars.

I hate to say I've done this too. Mainly because the company I work for refuses to give me a specification and the amount of time 'True','False' has changed to 'True','False','Some other weird state' is ridiculous.

My only saving grace is that they are stored in the database as enums?

"Old Code"?
I see way more of this now than before everything was (nay had to be) XML and web oriented.
Admittedly in some languages the types were cobbled together with strings & ints but at least we made the effort.
Now get off my lawn.

RHuckster:

I guess I'll get it out of the way...

...he's coding it so one day if there's a "File_Not_Found" state they can easily just add that in.

No, it stores as nvarchar(5) so it would be "File_".

Obviously TRWTF is that it is not stored as a nvarchar(14).

string temp1 = "false";

string temp2 = "false";

temp2 = "true";

string brainEXPLOSION = temp1 + temp2;

In other news, why didn't he have a constant string value for true and false? I mean, this would probably be bad, and may be hard to find deep in code:

string temp1 = "fale"

This is all very sensible - string literals don't change, but what if the language changed and started using YES and NO for booleans instead? It's actually very sensible.

It's also very common in embedded systems where you only have ints and strings.

Am I the only one disappointed by the lack of .ToString() calls in an article that starts out by talking about how man .ToString() calls there are?

Knux2:

In other news, why didn't he have a constant string value for true and false? I mean, this would probably be bad, and may be hard to find deep in code:

string temp1 = "fail"

FTFY

This reminds me of the codebase that I work with where boolean values are stored in the database as CHAR(1) where '1' is considered true.

Thus, in the codebase, I find things like:
if (record.getFieldString(1).trim().compareTo("1") == 0)
{
...
}

Jimmi needs an editor.

"almost everything that goes in or out of a function is^H^H ends with a .ToString(), even if it's already a string...

Any Named Moose:

Severity One:

insert into comments values ( "frist".toString() );

I think you meant

insert into comments values ( new String("frist").toString() );

insert into comments values ( GetString (new String("frist").toString()).toString().toString() );

campkev:

Am I the only one disappointed by the lack of .ToString() calls in an article that starts out by talking about how man .ToString() calls there are?

Could that be TRWTF?

Does your particular language not have an enum of its own?

CAPTCHA: enim. Like enum but for integers

n9ds:

It's brilliant! No type mismatches, and just think how easy it would be to migrate the application to XML! It has the makings of Enterprisy.toString() written all over it!

So, did the developers miss the "everything is a string" simplicity of Tcl?

When all you have is a swiss army knife, everything looks like a string.

campkev:

Am I the only one disappointed by the lack of .ToString() calls in an article that starts out by talking about how man .ToString() calls there are?

"No, I am very disappointed too".ToString()

Why is tempStartTime and tempEndTime encoded as ints, where is the ToString() ?

I think there is an instinct for novice developers to overuse strings. They are simple to understand, easy to manipulate and have good native handling in most high-end languages. However, any developer that actually understands OO principles should have realised the folly of this approach by the time they left University. Anyone who takes string-based coding out of school and into their job clearly hasn't learnt enough to be writing production code. Today's submission looks like your typical "I just learnt VB6 and everything can be done with strings" type code (I know it's C# but you get my point and it never hurts to have a dig at VB developers).

Won't fit "File Not Found" into 5 letters, though.

Mike D.:

n9ds:

It's brilliant! No type mismatches, and just think how easy it would be to migrate the application to XML! It has the makings of Enterprisy.toString() written all over it!

So, did the developers miss the "everything is a string" simplicity of Tcl?

Oh wow, I've been working with TCL for a day now and nobody told me that. Suddenly a whole lot of weird behaviour makes perfect sense. I should really RTFM before diving into these things but thanks for the tip, benevolent stranger.

Brian follower of Deornoth:

Won't fit "File Not Found" into 5 letters, though.

You'll have to use the ISO approved FNF code, then.

WriteComment("And what happens when it tries to store \"unknown\" into that field?".ToString().ToString());

Yeah... That was really quite hard to read. The poor grammar kind of overshadowed the entire article. Though maybe the quotation was just done out of irony.

I accidentally the post.

That's the most Visual Basicy C# I've ever seen.

I'm a bit concerned as we should have some code that does exactly this. It needs to get a start and end time and a selection of days of the week and send that info to a web service.

Hmm, think I better check this isn't our code.

That's so stupid... what a bad coder. All those manual checks for literal "true" and "false"s.

You could do this way faster with a 2 constant global "true" and "false" strings to use in the compares, so you aren't dimming all those extra strings on the fly and even more so with a Boolean.TrueString and Boolean.FalseString assuming it's .Net like I get the impression it is.

Also, I'm glad the DB uses nvarchar because those literal "true" and "false" strings he has could contain Unicode. So way to bloat the DB just that little bit more on top of storing strings instead of a Byte.

After all, since SQL Server won't let you Boolean, a string is way more logical than a Byte.

This is known as "stringly typed" programming. See:

http://www.globalnerdy.com/2010/05/09/new-programming-jargon/

(Not making this url into a clickable one with bbcode, because the server will reject my message as spam...)

at least they're using a webservice, that's good practice!

John Preston:

That's so stupid... what a bad coder. All those manual checks for literal "true" and "false"s.

You could do this way faster with a 2 constant global "true" and "false" strings to use in the compares, so you aren't dimming all those extra strings on the fly and even more so with a Boolean.TrueString and Boolean.FalseString assuming it's .Net like I get the impression it is.

This is the sort of flamebait that might just get a bite, despite being the most obvious troll this side of Shrek. It's not the best troll I've seen round here but it's got a certain something to it so good luck to you sir, let's see if you net anything in...

notme:

This is known as "stringly typed" programming. See:

http://www.globalnerdy.com/2010/05/09/new-programming-jargon/

[neologism]

Tagged accordingly!

But, "null" will fit in there fine. And "maybe". So, it has that going for it.

exel:

Jimmi:

it's also worth noting the fact that the datatype to store the true/false values is nvarchar(5). What could possibly go wrong?

Well, for starters, FileNotFound will not fit in 5 characters.

You just have to be synthetic. FNF.

A Proposed Replacement for Booleans

This code got me thinking, and I don't think it goes far enough. Booleans are obsolete technology, and they need to be updated. What's one of the first words little kids learn? "No." And "no" is really just false. So we shouldn't be using baby stuff for computers.

So this code takes the first step. It goes from booleans to strings. That's a big step, and it frees us up to redefine what a boolean means. Strings are flexible, so we could have a string that's "maybe" or "sort of" or "probably not". See because we aren't dealing with babies any more, so the black-and-white delineation of true/false is no longer enough.

But here's the problem. We're doing computer stuff. A computer doesn't know that "hell yes" is pretty damn true. We could define a whole bunch of values, but there's always something that'll fall through the cracks. Plus no one wants to go looking up the list of accepted values every time they code stuff. So we need something flexible.

Now we could invent some sort of super AI that can parse the strings and determine how truthy they are. But that's a lot of work, and we'd have to use the old, boring boolean system to do it since the super replacement booleans wouldn't be usable until the AI was done. So we need something we can use now.

Instead of an AI, we could use Google. You could do queries of "'hell yes' true" and "'hell yes' false" and go with the one with more hits. That's kind of like crowd-sourcing the web 3.0 paradigm through the wetware of website builders. But what if someone uses + for true and - for false? Google can't handle punctuation searches. What we really need to do is develop a new search engine that can, but again, we'd have to do all our development work using the old, boring booleans until it was done. No one in their right mind would want to do that. Again, we need something we can use now.

So here's where we get tricky. Instead of text strings, we switch to probabilities. That's all math and sciencey, and it can be evaluated by mathy computer machines, but it still gives us a lot of flexibility. Sure, we lose the ability to have a "hell yes" value -- it'll get encoded, say, as a less exciting 99.99% -- but we gain something that will work. However, since we're trying to be all math and sciencey, we'll encode 99.99% as .9999 because that's how the math people seem to do it, and they must know what they're doing because they study that stuff. So instead of strings, we can use floats for the booleans, but we still gain a vast number of possibilities. We can even represent things that're more true than true with values over 1, and that's amazing and powerful. For example, if I had a new boolean value for is_this_a_good_idea, I could assign a value of 2.6. That way, it's a good idea, and even if it wasn't, it's still a good idea, and even if it still wasn't, it still kinda is. And you know what's really cool? A lot of legacy code uses 1 for true and 0 for false, so it's easily ported to our system. Free backwards compatibility!

But there's a problem because floating point math is all weird. The IEEE has tried to contain the damage, but they're electricity people, and we don't want electricity, we want math and truth. So what we could do is turn those floating point numbers into integers and just do fixed point math. That really limits our precision though because what if a truth value is .0000000000000000000001? Rounding that to a lower precision would be tantamount to lying, and that's a bad way to start a new system for truth. So we need something better.

And that something better is strings. We store the neo-boolean values in strings, and we don't have to worry about all those crazy math limitations. Sticking ".0000000000000000000001" in a string is easy. We're done! There are at least a dozen programming languages that support strings, including Pascal, BASIC, and Algol 60. So I fully expect this standard to catch on.

A F:

This reminds me of the codebase that I work with where boolean values are stored in the database as CHAR(1) where '1' is considered true.

Thus, in the codebase, I find things like:
if (record.getFieldString(1).trim().compareTo("1") == 0)
{
...
}

Which is very different than == 1 because like someone else pointed out, eventually, the DB column will be 0, 1, OR N.
N means Not applicable, not No -> false -> same as 0.

Then you get (..."1" != "1") means it could be 0 OR N, not just 0 vs. ("0" == "0") means it must only be 0.

Of course, the column name will still be named in such a way as to imply a boolean. Enabled, InStock, etc.

The truly delightful aspect is that "false" evaluates to TRUE if you're testing it, since its evaluated as a string, and yes, the string is valid and non-NULL.

Atleast he did not write

if (mondayCheckBox.Checked.ToString()=="true")
tempMonday = "true";

if (tuesdayCheckBox.Checked.ToString()=="true")
tempTuesday = "true";
......

Call me Sally if you like, but if the spec. says true, false, etc. I'd use an enum in in source code too, not just the DB.

Alan:

I hate to say I've done this too. Mainly because the company I work for refuses to give me a specification and the amount of time 'True','False' has changed to 'True','False','Some other weird state' is ridiculous.

My only saving grace is that they are stored in the database as enums?

Jimmi:

it's also worth noting the fact that the datatype to store the true/false values is nvarchar(5). What could possibly go wrong?

Maybe I'm dumb, but does anyone know what could possibly go wrong? It seems to me that "true" and "false" should fit. NVARCHAR isn't null-character-terminated, is it?

Erasmus Darwin:

A Proposed Replacement for Booleans

<snip>

I admire that you took the time to author such an expansive troll and I am especially impressed by the fact that your proposed solution doesn't actually fulfil the purpose of a boolean value in any way. Kudos, good sir, there is surely a job waiting for you in Redmond.