- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Which raises some serious questions about what said collegue expects String.trim() to do. As in, do they assume Strings have some hidden property that makes them unusable without a .trim() or something? I do suspect they ran into some obscure problem some time in the past, did a bunch of stuff to fix it including .trim(), and when it finally worked came to the conclusion that it was due to the .trim().
Admin
"Frist".Trim()
Admin
The developer must have worked with our database before and for a long time. There's no "VARCHAR" to be seen anywhere, everything is stored in "CHAR". Which of course means you have to call Trim on just about everything (DateTime and Int excluded. Yes, at least we have those types as well), or you'll end up with a lot of trailing spaces. After a while it becomes automatic and you find yourself calling Trim where it isn't really needed.
Admin
You forgot to call ToString on it.
So the correct frist would have been "Frist".ToString().Trim()
Admin
Even if things coming from the database did need to be trimmed*, explain "False".Trim()
Admin
Of course there is at least one programming language for which everything can be treated as a string.
Admin
https://en.wikipedia.org/wiki/Cargo_cult_programming
Admin
PHP?
Admin
I think this makes more sense: " Frist ".ToString().Trim()
Admin
It sounds like they just got told once to always trim their strings, as good practice. Then they took that lesson out of that context, didn't really think about it, and started applying everywhere, all the time. At least they're not setting everything to lower case as well.
Admin
It's fairly common to get padded strings when reading from a database. I'd guess that the programmer ran into that sort of problem in the past and now habitually trims everything "just in case."
Admin
You forgot to trim the constant before ToString()-ing it.
Admin
No, this is actually the reason. Retrieving a value from a char(20) field in a table returns a string that is padded to 20 characters (at least in SQL Server). Said colleague would retrieve CHAR data from a table, and then try to compare it to another string value (using == rather than .Equals()), and as we all know "TEXT" != "TEXT ", so he would trim everything to make sure that any equality test would work properly.
However, that absolutely doesn't excuse calling .Trim() everywhere, and I never understood why he didn't write his stored procedures with RTRIM(field) so that the queries themselves would just return trimmed data and he wouldn't need to litter his code with .Trim().
Admin
SQL Server's CHAR (and NCHAR) datatype always pads every value stored to the full width of the column, if the field is not nullable. If a CHAR field is nullable, the behaviour depends on the ANSI_PADDING option value that was set when the table was created. If set to ON, the default, values are always padded to the full width of the column. If set to OFF trailing spaces are trimmed.
If ANSI_PADDING is ON, you can store trailing spaces in VARCHAR columns. The database will store exactly what you give it. If ANSI_PADDING is OFF, trailing spaces are trimmed.
https://msdn.microsoft.com/en-GB/library/ms187403.aspx
The ANSI_PADDING option was introduced in SQL Server 6.5 and is for compatibility with code for older versions; the ANSI_PADDING ON behaviour matches the SQL-92 standard. Later types such as NCHAR, NVARCHAR, TEXT and VARCHAR(MAX) only support the ANSI_PADDING ON behaviour. Many newer features of SQL Server (e.g. computed columns, indexed views) only work when ANSI_PADDING is ON. These days, SQL Server Management Studio defaults to ON; you could get inconsistent behaviour in earlier versions if you created a table in Query Analyzer (which used DB-Library, with ANSI_PADDING OFF) versus creating it in SQL Server Enterprise Manager (which used OLE DB, defaulting to ANSI_PADDING ON).
If your strings are always the same length, within one or two characters, use a CHAR field. You save the small overhead of the length prefix bytes which indicate how long the string is, and the indirect lookup to where the variable fields are stored at the end of the page. If there is any significant variation, use a VARCHAR field: the density of rows per page will usually be better, and you won't have to trim your data after retrieving it.
Admin
string.Empty.ToString.Trim()
Better safe than sorry
Admin
if "True".ToString().Trim() == WTF.ToString().Trim() { return "Coder is a WTF"".ToString().Trim() }
Admin
https://gist.github.com/masterX244/b7a812c14db497e9857615855a54d8c7 tampermonkey/greasemonkey sterilizing utility
Admin
You may want to change the old gist to a popup alert, so people know to change their tm/gm script to the new url
Admin
It's a perfectly suitable use of the Builder Pattern. :D
Admin
Although "cargo cult" encompasses a collection of practices that are (falsely) applied to a discipline... I prefer to call this the "shaking a voodoo stick at" pattern. Maybe it helped at one point, perhaps for unrelated reasons, but now it seems to be needed everywhere, and for no reason.
Admin
Even string constants may have any number of null characters at the end. So how do you expect to properly compare them? By trimming them, you know there will be exactly one null terminator on each side of the comparison. Problem solved.
Admin
No. Since you're obviously ignorant, I'll give a straight answer (for once 😉). Tcl treats everything as strings, or rather they're formally the supertype of all other value types. (That says nothing about how they're implemented, of course.)
Admin
The boolean and trim stuff is bozo, sure. But the rest is fine; the "date" that is being compared here is not a date field, but a date from a text box. That is already a string; Tyisha's coworker didn't convert the date to a string before checking to see whether or not it is valid. Presumably this is C# code, so I'd personally have used DateTime.TryParse here, but it's not necessarily wrong to have a library method to check if a string conforms to a valid date format (you might, for example, want some sort of logging to occur every time you make such a check, so it's convenient to abstract that out).
Admin
Well, all of the above don't give a clue about the story behind "Text.ToString()" and "Trim().ToString().Trim()" ...
Admin
Yes, of course "False".Trim() is dumb, even dumber than "TextBox.Text.ToString()". I'm just saying that I've found myself calling TRIM on stuff that really didn't need to be trimmed, like trying to trim a DateTime... in my defense, our database is a mess. Columns don't have very descriptive names, they are called stuff like "F196" or "F100" or "G000", so it's almost natural to write "SELECT TRIM(G000) FROM ...", even though G000 always contains exactly 5 digits and is 5 chars long.
Admin
And that's great so long as you're the only developer and are consistent about it. Where it falls apart is when you're on a team of idiots who don't know about VAHRCHAR, don't use RTRIM/LTRIM, do blind string == comparisons everywhere, don't even think about sanitizing INSERT/UPDATE fields, and choose random lengths for the same column in two tables while suppressing exceptions so it's not safe to just copy from one to the other without ending up in a half-aborted state because they didn't use transactions. That kind of developer isn't careful about NULL either so even OP may end up with NullReferenceExceptions from those Trim() calls. Forget anything even remotely technical like the weirdly-terminated strings that come back from some Win32 calls.
What I've done was call a static function that internally looks like [ function SafeClear (object o){return((o??"").trim());} ] because I was tired of being hauled into code review sessions over the inline version and then ended up being yelled at for the extra stack frame that it would've generated (if it hadn't drastically reduced the kind of stupid errors throwing us into the debugger in the first place). Yeah, a hypothetical 101 frames is so much worse than 100 real frames and is definitely what's killing performance in a system that uses Entity to cache entire databases per user session...
Admin
As someone who has done this I can explain the thought pattern. You may have written a simple script or program at some point that had to consume a string that was provided by a third party. That third party may have had a habit in the past of occasionally sending whitespace in places you didn't expect because it was sending data exactly as it was keyed with absolutely zero validation. You get burned one day. A field that should've contained a country code was a tab, a date of birth had spaces and so on. As a junior/inexperienced coder you get defensive and start trimming things every time you receive a string, or add some strings. Also I think some languages iterate differently. So you have these arrays that always end with a null entry. So rather than improving your level of understanding, just trim everything and pray a whitespace never appears in your dataset again.
Admin
And the Format string gets Trim() called on it twice. I am partly surprised that this coworker doesn't use string.Trim().Trim().Trim().Trim()... ad infinitum everywhere.
Admin
Has anyone of you thought that the reason behind this, is that the guy just doesn't know what the fuck he is doing?
Admin
Or he has a rare case of OCD.
Admin
Another WTF is initializing a variable to some value just to assign another value to it just 2 lines below. A pet peeve of mine.
Admin
That, or the golden hammer (https://en.wikipedia.org/wiki/Law_of_the_instrument)
Admin
while (true) inputString = inputString.trim();
Admin
I seem to remember in VB that converting from a number to a string would add a space to the front of the string. Maybe they were used to that. Still no excuse.
Admin
REXX.