- 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
this.TraceOutput(string.Concat("\n\n\n", "Frist", "\n\n\n"));
Admin
I cannot help but admire the vast amount of code in the last method --- devoted to looping through a string which is guaranteed to be exactly one character. Bravo!
Admin
Microsoft's inclusion of Convert.ToX was a horrible mistake. It caused a massive amount of developers to use them, unaware of the better X.TryParse methods.
Admin
Looks like that mail variable is a global too, so once it is set it will always be set
Admin
´´´this.´´´
This is pretty much always a dead giveaway that code was written by a Java dev.
Addendum 2025-03-06 09:52: And obviously the complete lack of understanding of the Dispose pattern makes it pretty likely that we are no talking about a c/C++ dev here, because it's a bread and butter COM pattern.
Admin
re: "mostly a black box" - that is a sure-fire way to miss cyclomatic complexity related situations - even if they have 100% code coverage.
Admin
@colejohnson66** ref
The Convert.ToX methods were in .Net from the original Framework 1.0. The Tryparse methods were a later addition, Framework 2.1 IIRC. MS would have needed a time machine to do it the other way.
But yes, once the TryParse. methods exist, there begins to be an argument for deprecating the Convert methods. Without delving into the source code details to assess performance, it may well be that the Convert methods are significantly faster for the happy path. Which would be reason enough not to deprecate them.
Admin
Different tools for different reasons.
As a general rule, TryParse is very useful for situations when the immediate code can gracefully recover from a failed attempt to parse. Say for example you are parsing a configuration file where any missing entries are assumed to mean you should use builtin defaults. Or you have a 50% chance someone is going to spell 'true' as 'yes' and it's a known thing you just have to handle in code.
But this is not always the case. There are plenty of situations where a failed parsing attempt is a non recoverable fault from the perspective of your immediate code. And the correct thing to do is to throw an exception and let whom ever called your code do the handling within their broader context. And for those situations you deliberately want to use Convert or Parse (if available) because they throw exceptions.
It's the same as with Linq and it's First / FirstOrDefault methods.
Admin
I love they part where they call engine.Dispose() directly, instead of properly using a "using" statement (or at least calling it inside a finally block). And they don't bother disposing the StreamWriter at all.