Do not compare Strings
-
Or get a shotgun.
-
A bear with a shotgun is just bad news for everyone concerned...
-
Under what circumstances could a string be either null or empty, with both of these meaning the same thing?
I see you have never used Oracle.
-
-
Fezzes are cool now?
-
-
pretty sure that's a retrobacronym, otherwise why would i have had to deal with PSV (pipe separated) and TSV (tab separated) and ZSF( '\0' spearated) files before?
I've called pipe separated value files PSVs, but only to be silly....
And why would they call \0 ZSF... isn't that NTSF?
-
The transmission format they use to communicate with the central servers uses field-sep and record-sep.
Most old shit I've dealt with is fixed record format, which is an unholy bitch when you have to add things. And no one wants to wake the old man RPG dev to update the import code.
6 in a row. I apologize for the brokenness of this string of posts.
-
-
Most old shit I've dealt with is fixed record format, which is an unholy bitch when you have to add things.
I have to deal with a few different fixed width formats and some of them reserve fields next to fields for identification numbers where X digits are never enough. X+Y must be plenty! Others are "this record contains a 1" or other fixed value.
-
And why would they call \0 ZSF... isn't that NTSF?
I keep reading that as ZFS and NTFS
-
-
A bear with a shotgun is just bad news for everyone concerned...
Yeah -- that sounds like a major problem...
-
SPEAKING of Oracle, our Oracle DBA said this in an email to our project's dev team yesterday.
One cannot express in words how I loath Oracle on Windows. It seems with every patch something must go wrong.
This was after she'd taken our Dev DB down for 5 hours the day after applying a patch to it.
Now, having said that, we (apparently?) run one of the largest Oracle Spatial installations in the world, so we run into all sorts of fun new bugs that no one else does.
-
-
Now, having said that, we (apparently?) run one of the largest Oracle Spatial installations in the world, so we run into all sorts of fun new bugs that no one else does.
I've never dealt with Oracle Spacial (fortunately it seems).
Our Oracle DB isn't the biggest (biggest table has about 3billion rows), but I've seen enough bugs to hate Oracle deeply. Their response to every bug we've submitted has been, "try upgrading, see if that fixes it."
One of the bugs was that a Primary UNIQUE key got corrupted, and started allowing duplicates. Except not all the time, and only in one of the dozens of partitions. It also happened to be that 3 billion row table. And it was so broken that it wouldn't re-build the key because there were duplicates in the table. Now I have the tools that I could have fixed that crap in a day, but at the time I had no way short of creating a new table and crafting a PL/SQL to try to remedy their broken key and put in non-duplicated data in the new table and create a new primary key.
-
I've had data corruption in the DB because the client wasn't using the DB api correctly. Result: Data in DB not matching the declared type.
Also frequently seen when inserting malformed UTF-8.One would expect serverside validation, but apparently there isn't any.
-
The bizarre part was that any way you tried to query the table in Oracle, it swore there were no duplicates. But if you tried to copy the data out of that table into another with an identical Unique Key, it would fail due to duplicates.
-
The bizarre part was that any way you tried to query the table in Oracle, it swore there were no duplicates. But if you tried to copy the data out of that table into another with an identical Unique Key, it would fail due to duplicates.
Did it somehow have two copies of the column, one of which had the unique constraint on, and the other of which was used for actual extraction of values?
Ugh, just writing that makes my head ache.
-
Did it somehow have two copies of the column, one of which had the unique constraint on, and the other of which was used for actual extraction of values?
I'm guessing it was a bad / buggy index.
-
I'm guessing it was a bad / buggy index.
That's less demented than my idea. May it be so!
-
I'm guessing it was a bad / buggy index.
Yes, the index corrupted. We ended up having to do something like
[pseudocode][code]
create table tmp like crappy_table;
create unique primary key index (uniquekeycolumns) on tmp;
insert into tmp (select uniquekeycolumns,x,y,z from crappy_table group by uniquekeycolumns);
drop table crappy_table;
rename table tmp as crappy_table;
[/code][/pseudocode]Which doesn't look so bad except when it takes over day (I don't remember exactly how long it took, but it was a while) to finish copying all the data and squashes your disk i/o for the entirety of it because your server isn't very good.
-
I really don't understand what kind of culture could ever induce someone to consider null, and the empty string, to be the same.
There's no reason to write
[code]if (string != null && !string.isEmpty())[/code]when you can just write
[code]if (!string.isNullOrEmpty())[/code]
if you don't actually need to differentiate between a null result and an empty result. Of course null and empty aren't the same, but if you don't care, then it doesn't matter.
Basically:
This stuff almost always seems overblown to me. How often is it really important to differentiate between null and an empty string?
-
They even have
String.IsNullOrWhiteSpace()
- when a string full of nothing also feels empty to you.
-
It always struck me as bad language design when strings and other types are required to have a null value just because they're reference types.
I mean I'm hardly alone here and languages like Haskell and Rust and some others fix that.
But not nearly enough languages do.
And since when did knowledge stop me from making a post here?
-
Do you also consider it a wtf that strings are immutable in C# and Java?
-
Only on even week numbers.
Being objects made out of multiple parts, I can't help but think that they shouldn't be immutable by default.
But most usages of strings do not need to mutate them...
This is all before we discuss the strong performance implications.
(This is the perfect place to explain myself, I think.)
-
They even have
String.IsNullOrWhiteSpace()
- when a string full of nothing also feels empty to you.Shhh, the philosophers might hear you. They'll start with that, and if they find out about undefined behaviors in C we'll be stuck with them forever!
-
I think that Go's strings have a zero value of
''
instead of nil. (the "zero value" is what you get if you just declare a variable with no initialization)
-
So, Go has reinvented names for more things than just coroutine? <I mean, default is still a word>
-
Makes some practical sense. Strings in buffers on the stack can't be NULL.
-
I consider it a wtf when strings aren't immutable. Calling copy every time you assign a string is a pain in the ass. And string operations are commonly chained, so it's not like your functions aren't gonna return the same string anyway, if you want your language to be usable.
I simply cannot think of any use case for mutable strings that wouldn't be a better fit for arrays of characters.
-
I honestly thought isNullOrEmpty considered whitespace.
-
I honestly thought isNullOrEmpty considered whitespace.
Nope; that's why they addedIsNullOrWhitespace()
in .NET 4
-
Do you also consider it a wtf that strings are immutable in C# and Java?
Mutable Strings are TRWTF
-
I think the only common reason you would need isBlank over isEmpty is if you're modifying the string or not trimming things you're putting into a db.
-
It's also useful shorthand for
s == null || String.IsNullOrEmpty(s.Trim())
;)
-
s == null || String.IsNullOrEmpty(s)
I know a shorthand for that:
String.IsNullOrEmpty(s)
-
I know a shorthand for that
*sighs*
…fixed my post… seems I'm a little distracted today…
-
*sighs*
…fixed my post… seems I'm a little distracted today…Someone is too busy flirting.
-
There's no reason to write
[code]if (string != null && !string.isEmpty())[/code]when you can just write
[code]if (!string.isNullOrEmpty())[/code]
if you don't actually need to differentiate between a null result and an empty result. Of course null and empty aren't the same, but if you don't care, then it doesn't matter.
Basically:
This stuff almost always seems overblown to me. How often is it really important to differentiate between null and an empty string?
But, under what circumstances is that actually the right thing to do?
-
Usually always.
-
Well, here's a real-world example:
You have a Person class with two strings for firstname and lastname. The class is mapped to a corresponding SQLite-Table.
Now you build a UI where you databind the two textbox-fields to the two strings. That has the advantage of being able to use this UI for both creating new entries and updating old entries.
Here's the thing, though: Only upon saving the fields into the table are NULL strings converted into empty strings (the database itself couldn't care less either way, actually, it's just that the sync-routine doesn't like NULL entries.)
And if the datacontext is a
new Person()
instead of aPerson.FindById()
then you have the problem that the content of the textboxes may be either empty or null, depending on whether you have the former or the latter case.Thus you do the
if(!string.IsNullOrEmpty(person.lastname) ^ !string.IsNullOrEmpty(person.firstname))
if your data model demands either a lastname or firstname.
-
or more generalized,
String.isNullOrEmpty
is useful in any situation where you have a method that doesn't implement the Null Object pattern... or if you don't know if it implements the Null Object pattern.
-
if(!string.IsNullOrEmpty(person.lastname) ^ !string.IsNullOrEmpty(person.firstname))
That's an 'interesting' way to spell
if(string.IsNullOrEmpty(person.lastname) != string.IsNullOrEmpty(person.firstname))
.
-
That's an 'interesting' way to spell
if(string.IsNullOrEmpty(person.lastname) != string.IsNullOrEmpty(person.firstname))
.Well, it's a XOR, they always look weird.
-
Well, it's a XOR, they always look weird.
I'm sure the maintenance programmers will relish the challenge that bitwise boolean logic introduces too.
If you've ever wondered why C has
&&
and||
operators, but no^^
operator, that's because 'logical XOR' is spelled!=
.
-
Sorry,
!=
is not logical XOR.1 ^^ 2
would be false, but1 != 2
is true...
-
In a
bool
ean context, you muppets...!= | true | false ---------------------- true | false| true false| true | false
^ | 1 | 0 ---------------------- 1 | 0 | 1 0 | 1 | 0
-
You specified C. C does not have a boolean type, and there are definitely situation where variables in boolean context will have a value other than 1 or 0.