Finally on Try blocks? We've heard of that too.



  • My newest excavation from this code base:

    SqlCommand sqlCommand = new SqlCommand();
    SqlConnection mySqlConnection = null;
    Exception exc = null;
    
    string cs = string.IsNullOrEmpty(eCode) ? _ConnectionString : GetConnectionString(eCode);
    
    sqlDataObject = null;
    try
    {
    	mySqlConnection = new SqlConnection(cs);
    	sqlCommand.Connection = mySqlConnection;
    	sqlCommand.CommandText = commandText;
    	sqlCommand.CommandTimeout = _DBTimeOut;
    	mySqlConnection.Open();
    	sqlDataObject = sqlCommand.ExecuteScalar();
    }
    catch (Exception e)
    {
    	exc = e;
    }
    finally
    {
    	if (mySqlConnection != null)
    	{
    		mySqlConnection.Close();
    		mySqlConnection.Dispose();
    	}
    	if (sqlCommand != null)
    	{
    		sqlCommand.Dispose();
    	}
    }
    
    if (exc != null) { throw exc; }
    

    Almost all of the existing database queries are routed through the class that contains this method. Which has the exact same block of code to set up the Sql Connection and command 8 times over.

    I don't know what amuses me more, that their finally block could be done entirely by a using, or the useless catch that stores the exception, and re-throws it at the end of the function, completely screwing up the call stack on the exception

    Right now I'm going through the code, removing all instances of Sql statement building with string.Format. This class will probably be next on the chopping block.



  • @bardofspoons42 said:

    I'm going through the code, removing all instances of Sql statement building with string.Format. This class will probably be next on the chopping block.
     

    Just asking, but, erm, will the program be much faster and much more stable with you plowing through and reseeding the code?

    Because obviously "dirty code" is not at all a good reason to remove all instances and put code on the chopping block.



  • The real WTF is String.IsNullOrEmpty(). My first issue with it is that it's trivial to construct a boolean expression that manages the same thing without a function call. I hate crap like that, where extra ways to do things are grafted onto a language for no goddamned reason. After all, if you don't understand nulls and boolean expressions, you're screwed anyway. Second, how many fucking times does Microsoft expect me to hit the Shift key per day? Like, 80,000? I usually just seeth quietly about "camel case," "Pascal case," and the rest of Microsoft's time-wasting, finger-twisting naming recommendations, but this one is ridiculous. It looks like you're sending the runtime a ransom note.



  • @dhromed said:

    @bardofspoons42 said:

    I'm going through the code, removing all instances of Sql statement building with string.Format. This class will probably be next on the chopping block.
     

    Just asking, but, erm, will the program be much faster and much more stable with you plowing through and reseeding the code?

    Because obviously "dirty code" is not at all a good reason to remove all instances and put code on the chopping block.

    If it was just a problem with that method, I would clean it up and move on. I mentioned in another post that all Sql in this program is in the format of "EXEC procName @Param1={0}, @Param2={1}", which is then run through string.format to fill in the parameters (Which may or may not involve quote escaping), and then sent off via a SqlCommand. I'm not tackling it right now, but there is a SQL command that takes 108 parameters. Because, for some reason, while the data is stored normalized in the database, they denormalize it via stored procs, display it, and saves again in denormalized form, which the proc has to fix. The proc that selects data for this has an execution plan that looks like this when zoomed out:

    I should note that this just returns a single row, selecting a prospect from the database, along with some other information. So, it goes a bit beyond "I don't like it, I'm going to replace it"


  • Winner of the 2016 Presidential Election

    @bardofspoons42 said:

    My God, it's full of stars.



  • @bridget99 said:

    The real WTF is String.IsNullOrEmpty(). My first issue with it is that it's trivial to construct a boolean expression that manages the same thing without a function call. I hate crap like that, where extra ways to do things are grafted onto a language for no goddamned reason. After all, if you don't understand nulls and boolean expressions, you're screwed anyway. Second, how many fucking times does Microsoft expect me to hit the Shift key per day? Like, 80,000? I usually just seeth quietly about "camel case," "Pascal case," and the rest of Microsoft's time-wasting, finger-twisting naming recommendations, but this one is ridiculous. It looks like you're sending the runtime a ransom note.
    I don't use the shift key while typing it.  I type the following keys and intellisense does the rest - s, t, r, {dot}, i, s, n, {right parenthesis}



  • @bridget99 said:

    The real WTF is String.IsNullOrEmpty(). My first issue with it is that it's trivial to construct a boolean expression that manages the same thing without a function call. I hate crap like that, where extra ways to do things are grafted onto a language for no goddamned reason. After all, if you don't understand nulls and boolean expressions, you're screwed anyway. Second, how many fucking times does Microsoft expect me to hit the Shift key per day? Like, 80,000? I usually just seeth quietly about "camel case," "Pascal case," and the rest of Microsoft's time-wasting, finger-twisting naming recommendations, but this one is ridiculous. It looks like you're sending the runtime a ransom note.
     

     

    I fail to see how if(String.IsNullOrEmpty(somestr)) is worse than if(somestr==null||somestr.length==0) or why it would cause you to seeth quietly. I am partly referring to the fact that using Shift is suddenly worse keystroke-wise than a longer boolean expression.

     

    but then again many people don't need good reasons. They make up their mind and then they make up the rest as well.



  • @BC_Programmer said:

    I fail to see how if(String.IsNullOrEmpty(somestr)) is worse than if(somestr==null||somestr.length==0) or why it would cause you to seeth quietly. I am partly referring to the fact that using Shift is suddenly worse keystroke-wise than a longer boolean expression.

     

    but then again many people don't need good reasons. They make up their mind and then they make up the rest as well.


    Okay, two things:

    What is the semantic difference between a null string and an empty string?

    Depending on your answer to that question, either:

    • Why are you doing the same action for two very different circumstances?
    • Why does your language allow null strings if it has a construct similar to a string pointer (that is semantically distinct from a simple string)?


  • @BC_Programmer said:

    @bridget99 said:

    The real WTF is String.IsNullOrEmpty(). My first issue with it is that it's trivial to construct a boolean expression that manages the same thing without a function call. I hate crap like that, where extra ways to do things are grafted onto a language for no goddamned reason. After all, if you don't understand nulls and boolean expressions, you're screwed anyway. Second, how many fucking times does Microsoft expect me to hit the Shift key per day? Like, 80,000? I usually just seeth quietly about "camel case," "Pascal case," and the rest of Microsoft's time-wasting, finger-twisting naming recommendations, but this one is ridiculous. It looks like you're sending the runtime a ransom note.
     

     

    I fail to see how if(String.IsNullOrEmpty(somestr)) is worse than if(somestr==null||somestr.length==0) or why it would cause you to seeth quietly. I am partly referring to the fact that using Shift is suddenly worse keystroke-wise than a longer boolean expression.

     

    but then again many people don't need good reasons. They make up their mind and then they make up the rest as well.

    I really dislike using the Shift key. It disrupts the flow of thought to code. It's much more error-prone than just having to type a bunch of lowercase characters. I suspect that anyone who disagrees has either never really thought about it, or has been cowed into submission by people who overestimateTheAmountOfInformationThatAnIdentifierCanSlashShouldConvey.



    The best languages have ditched first grade math notation and thus allow names like "much-easier-to-type." That's what I like. I even read about a language once in which the Shift key had special significance. That is, if you were using a US keyboard, and you did something that required you to use the Shift key, it was a sort of warning that you were doing something potentially risky, like incurring a resource cleanup requirement, or introducing a potential race condition. Variables had names like "oh-no-my-toddler-will-think-this-is-subtraction." Function calls used square brackets instead of parentheses in this language, IIRC. Parentheses were reserved for something unsafe (macro invocation?). As long as the developer was using stack allocation, functional programming, etc., everything could be typed without Shift, and would end up being inherently reentrant. I'll try and find a link...



  • @bridget99 said:

    I really dislike using the Shift key. It disrupts the flow of thought to code.
    If the simple act of pushing the Shift key in the right places is taxing enough on your thought process that it disrupts your ability to write code freely, that does not seem to say much for the magnitude of your mental capacity...


  • Discourse touched me in a no-no place

    @bridget99 said:

    I really dislike using the Shift key. It disrupts the flow of thought to code.
    I suggest you google 'Mavis Beacon'.



    Seriously, if having to consider whether or not to use an upper-case 4 or 8 or not disrupts your 'flow of thought to code' then you're not really a programmer.



    Perhaps sir would be happier with one of these:



  • @bridget99 said:

    The real WTF is String.IsNullOrEmpty(). My first issue with it is that it's trivial to construct a boolean expression that manages the same thing without a function call. I hate crap like that, where extra ways to do things are grafted onto a language for no goddamned reason. After all, if you don't understand nulls and boolean expressions, you're screwed anyway.

    While loser coders like you are wasting time making sure you type extra tests, super coders like me are using methods like this to get our products to market faster. Keep on losing, loser.

    @bridget99 said:

    Second, how many fucking times does Microsoft expect me to hit the Shift key per day? Like, 80,000? I usually just seeth quietly about "camel case," "Pascal case," and the rest of Microsoft's time-wasting, finger-twisting naming recommendations, but this one is ridiculous. It looks like you're sending the runtime a ransom note.

    LOL. Underscores FTW. I hate trying to read camel case.



  • @Ben L. said:

    What is the semantic difference between a null string and an empty string?

    Sometimes, it's an arbitrary decision by a framework to pass an empty string or a null string when they post a form. Either way, if you have a required field, there may be no difference between a null object or an empty string when processing. But a null pointer exception is always a bummer. I suppose you could simply throw an exception anyways and force your callers not to send you nulls, but that's just being a dick.

    @Ben L. said:

    Depending on your answer to that question, either:

    • Why are you doing the same action for two very different circumstances?
    • Why does your language allow null strings if it has a construct similar to a string pointer (that is semantically distinct from a simple string)?

    Neither one of these applies to my answer.



  • @bardofspoons42 said:

    This class will probably be next on the chopping block.


    Clean it up, sure, but I wouldn't be so quick to eliminate it. Not only is it a question of containing the boilerplate (and avoiding the proliferation of a shorter boilerplate which skips the using / finally), it makes it easy to handle per-connection parameters if that becomes necessary.



  • The repeated code is one thing, but a lot of people don't know about the using statement so is it really that terrible to do it the old-fashioned way?


  • The Cold Doesn't Bother Us Anyway

    @bridget99 said:

    The real WTF is String.IsNullOrEmpty(). My first issue with it is that it's trivial to construct a boolean expression that manages the same thing without a function call [b]that the compiler can optimise by inlining, thereby removing the function call overhead completely anyway[/b].

    FTFY

    @BC_Programmer said:

    I
    fail to see how if(String.IsNullOrEmpty(somestr)) is worse than
    if(somestr==null||somestr.length==0)

    The latter is of course exactly what the former does anyway.



  • ITT: people who still work in languages where avoiding "unnecessary" function calls is more desirable than writing readable code.

    @RaceProUK said:

    @bridget99 said:

    The real WTF is String.IsNullOrEmpty(). My first issue with it is that it's trivial to construct a boolean expression that manages the same thing without a function call that the compiler can optimise by inlining, thereby removing the function call overhead completely anyway.

    FTFY

    Hey, someone who actually understands that the guys who created .NET are much smarter than the majority of the programmers on the planet, and would've thought about things like this!


  • Winner of the 2016 Presidential Election

    Could someone quantify the performance boost inlining a function really has? I couldn't see it making a measurable, real-world impact unless you're checking millions of strings.

    99% of the time the overhead of a single function call (just the call, not what the function does) is something a programmer shouldn't have to think once about.



  • Jesus, the Bridget99 troll account just reels 'em in. What's wrong with you people?



  • @The_Assimilator said:

    ITT: people who still work in languages where avoiding "unnecessary" function calls is more desirable than writing readable code.

    @RaceProUK said:

    @bridget99 said:

    The real WTF is String.IsNullOrEmpty(). My first issue with it is that it's trivial to construct a boolean expression that manages the same thing without a function call that the compiler can optimise by inlining, thereby removing the function call overhead completely anyway.

    FTFY

    Hey, someone who actually understands that the guys who created .NET are much smarter than the majority of the programmers on the planet, and would've thought about things like this!

    I was much more concerned about the simple difficulty of accurately typing IsNullOrEmpty() than about the "extra" function call. But I will tell you that relying upon a compiler to optimize things in a way that conforms to the developer's own imagination is a sign of amateurism, in my opinion. The thought process of such amateurs seems to be "gosh, those compiler-writing people are so smart, surely they're code will do such-and-such." Having actually written and maintained a few compilers, better developers understand that it's not necessarily so. All sorts of practical considerations come into play.



  • I drew a fairly good pear in pencil.



  • @joe.edwards said:

    Could someone quantify the performance boost inlining a function really has? I couldn't see it making a measurable, real-world impact unless you're checking millions of strings.

    99% of the time the overhead of a single function call (just the call, not what the function does) is something a programmer shouldn't have to think once about.

    I work with a lot of devices that have a hardware stack for return addresses. Typically this holds from seven to twelve addresses. Some of the newer devices can be configured to trigger an interrupt service routine if the maximum call depth is exceeded... the older ones just fail silently. An "extra" function call can mean the difference between "wow, that's some really accurate positioning" and "gaaaaa my arm, pull the plug." So, function calls are not free... and you can discount this as a "special case," but there are literally millions (maybe billions) of the devices I'm referring to in production. They're not relevant to .NET, but they are a good counterpoint to a lot of the high-and-mighty, by-the-book OOP pronouncements that the regulars here like to issue.


  • The Cold Doesn't Bother Us Anyway

     @bridget99 said:

    @The_Assimilator said:

    ITT: people who still work in languages where avoiding "unnecessary" function calls is more desirable than writing readable code.

    @RaceProUK said:

    @bridget99 said:

    The real WTF is String.IsNullOrEmpty(). My first issue with it is that it's trivial to construct a boolean expression that manages the same thing without a function call that the compiler <font size="7">can</font> optimise by inlining, thereby removing the function call overhead completely anyway.

    FTFY

    Hey, someone who actually understands that the guys who created .NET are much smarter than the majority of the programmers on the planet, and would've thought about things like this!

    I was much more concerned about the simple difficulty of accurately typing IsNullOrEmpty() than about the "extra" function call. But I will tell you that relying upon a compiler to optimize things in a way that conforms to the developer's own imagination is a sign of amateurism, in my opinion. The thought process of such amateurs seems to be "gosh, those compiler-writing people are so smart, surely they're code will do such-and-such." Having actually written and maintained a few compilers, better developers understand that it's not necessarily so. All sorts of practical considerations come into play.

    Thought I'd make that word a bit bigger, since you obviously missed it first time.

     



  • @RaceProUK said:

     @bridget99 said:

    @The_Assimilator said:

    ITT: people who still work in languages where avoiding "unnecessary" function calls is more desirable than writing readable code.

    @RaceProUK said:

    @bridget99 said:

    The real WTF is String.IsNullOrEmpty(). My first issue with it is that it's trivial to construct a boolean expression that manages the same thing without a function call that the compiler <font size="7">can</font> optimise by inlining, thereby removing the function call overhead completely anyway.

    FTFY

    Hey, someone who actually understands that the guys who created .NET are much smarter than the majority of the programmers on the planet, and would've thought about things like this!

    I was much more concerned about the simple difficulty of accurately typing IsNullOrEmpty() than about the "extra" function call. But I will tell you that relying upon a compiler to optimize things in a way that conforms to the developer's own imagination is a sign of amateurism, in my opinion. The thought process of such amateurs seems to be "gosh, those compiler-writing people are so smart, surely they're code will do such-and-such." Having actually written and maintained a few compilers, better developers understand that it's not necessarily so. All sorts of practical considerations come into play.

    Thought I'd make that word a bit bigger, since you obviously missed it first time.

     

    I don't know how to make super-huge letters like that... I just settle for having super-huge genitalia. BUT I think this is one of those cases where "may" fits the situation better than "can." And I stand by my general assertion that people who rely on compiler optimizations to explain why their code doesn't suck are unskilled hacks.



  • @Ben L. said:

    @BC_Programmer said:

    I fail to see how if(String.IsNullOrEmpty(somestr)) is worse than if(somestr==null||somestr.length==0) or why it would cause you to seeth quietly. I am partly referring to the fact that using Shift is suddenly worse keystroke-wise than a longer boolean expression.

     

    but then again many people don't need good reasons. They make up their mind and then they make up the rest as well.


    Okay, two things:

    What is the semantic difference between a null string and an empty string?

    In .NET, [url=http://msdn.microsoft.com/en-us/library/system.string.aspx]strings[/url] are objects.  Atempting to access methods on a null string object throws a NullReferenceException.  An empty string is just one set to "" (which is also the constant [url=http://msdn.microsoft.com/en-us/library/system.string.empty.aspx]String.Empty[/url]), and you can call methods as normal on it.

    As for why String.IsNullOrEmpty or String.IsNullOrWhiteSpace (which you should use instead of IsNullOrEmpty) exist, I imagine it's for consistency across programming languages... C# isn't the only language .NET supports.

     



  •  @bridget99 said:

    My first issue with it is that it's trivial to construct a boolean expression that manages the same thing without a function call.
    Bullshit.



  • @Sir Twist said:

     @bridget99 said:

    My first issue with it is that it's trivial to construct a boolean expression that manages the same thing without a function call.
    Bullshit.

    Really? I never use that method, but I'm frequently checking to see if strings are empty or null. Are you using VB.NET? If that's the problem, go read up on OrElse... or else.



  • .Length is a property, using it as an rvalue calls the getter. That is a function call. Maybe it's not visible, but it's there.



  • @Sir Twist said:

    .Length is a property, using it as an rvalue calls the getter. That is a function call. Maybe it's not visible, but it's there.

    Well, if you want to pick nits, they're all method calls, not function calls. But if I were really writing this, I would use == to compare the string to "". I'm sure that results in at least one method call beneath the surface... but that's not really what bothers me. I just think that having a static method of the string class called IsNullOrEmpty is stupid.


  • The Cold Doesn't Bother Us Anyway

    @bridget99 said:

    I would use == to compare the string to "".

    Thus opening yourself to a world of pain.

     



  • @bridget99 said:

    I just think that having a static method of the string class called IsNullOrEmpty is stupid.

    It prevents the world from creating this method somewhere else, thus saving lots of time and energy, except in this thread.



  • @RaceProUK said:

    @bridget99 said:

    I would use == to compare the string to "".

    Thus opening yourself to a world of pain.

     

    == is overloaded for strings such that is does a test for equal data (not for pointer equality). Yeah, if you artificially force things to be instances of Object, you'll get a reference comparison and bad things will happen. That's more of a problem with using Object than a problem with using == in my estimation. And really, if you want to write ".Equals(String.Empty)" I'll still think you're an anal retentive fucktard, but much less of one than the guy who calls IsNullOrEmpty.


  • The Cold Doesn't Bother Us Anyway

    @bridget99 said:

    And really, if you want to write ".Equals(String.Empty)" I'll still think you're an anal retentive fucktard, but much less of one than the guy who calls IsNullOrEmpty.

    Good thing I don't call that then - I call String.IsNullOrWhitespace().



  • Interesting that you could care about each and every function call so much that you'd want to avoid String.IsNullOrEmpty but you don't care about x == "" which is significantly more work.


  • The Cold Doesn't Bother Us Anyway

    @configurator said:

    Interesting that you could care about each and every function call so much that you'd want to avoid String.IsNullOrEmpty but you don't care about x == "" which is significantly more work.

    I assumed that's aimed at bridget99 not me ;-)



  • @powerlord said:

    @Ben L. said:

    @BC_Programmer said:

    I fail to see how if(String.IsNullOrEmpty(somestr)) is worse than if(somestr==null||somestr.length==0) or why it would cause you to seeth quietly. I am partly referring to the fact that using Shift is suddenly worse keystroke-wise than a longer boolean expression.

     

    but then again many people don't need good reasons. They make up their mind and then they make up the rest as well.


    Okay, two things:

    Explanation

    Which makes more sense:

    string is an unextendable class defined by the standard library and used at the language level (string literals). A simple operation like "how long is string x?" takes multiple memory accesses. Substrings contain a separate copy of their contents.

    string is a basic type (defined at the language level) consuming two words; the zero value (null) of string is a zero-length string starting at 0x00000000. Substrings can be produced in O(1) time with O(1) memory.



  • @configurator said:

    Interesting that you could care about each and every function call so much that you'd want to avoid String.IsNullOrEmpty but you don't care about x == "" which is significantly more work.

    Read my last post. I don't care at all about reducing function calls in .NET. If I need something to be fast, I write it in something that isn't .NET. My goal for my .NET code is to get it up and running quickly, and to make it easy to understand. When I said I didn't need to use a function, what I meant is that neither I nor anyone else needs for IsNullOrEmpty to exist at all. It is a stupid, useless piece of cruft, and the infantile way in which it is named is an additional source of consternation. People who use names like that are impotent fools who should be neutered like dogs.



  • @bridget99 said:

    It is a stupid, useless piece of cruft

    Except it shortens code that is needed in a lot of places, and avoids programmers mistakes as well.

    @bridget99 said:

    the infantile way in which it is named

    Following the naming convention of the entire platform doesn't seem infantile to me.


  • The Cold Doesn't Bother Us Anyway

    @bridget99 said:

    My goal for my .NET code is to get it up and running quickly, and to make it easy to understand.

    Side-by-side:

    if (x == null || x.Length == 0)

    if (String.IsNullOrEmpty())

    That second one looks suspiciously like a valid English sentence...

    Word of advice: if you're gonna troll, at least be consistent about it.



  • @RaceProUK said:

    @bridget99 said:
    My goal for my .NET code is to get it up and running quickly, and to make it easy to understand.

    Side-by-side:

    if (x == null || x.Length == 0)

    if (String.IsNullOrEmpty())

    That second one looks suspiciously like a valid English sentence...

    Word of advice: if you're gonna troll, at least be consistent about it.

    I said "up and running quickly" first. That's the goal that is ill-served by having to type finger-twisting crap like IsNullOrEmpty. And the fact that we have Intellisense, i.e. that there is an IDE available where an out-of thread actor will insert your code for you, does not really sway me here. That doesn't mean that we should countenance unreasonable naming standards. After all, we're all typing IsNullOrEmpty repeatedly in this thread. Wouldn't you rather not have the discussion at all (which would be facilitated by leaving out cruft), or, alternatively, wouldn't you rather have discussions about "is-null-or-empty" or even just "isnullorempty"? Both are much easier to type. (And I doubt you really thought I was subtracting "or" from "null" in the first suggestion, nor do I find the second suggestion inordinately hard to read.)



    And frankly, I think that all this focus on maintainability of .NET code is just a bit misplaced. Getting stuff up-and-running quickly is the main appeal of .NET for me. It is good for prototyping, scripting, and wrapping DLLs written in C; but I'm not going to agonize over the elegant maintainability of my C# or VB.NET code. .NET code is really pretty transitory. It's not cross-platform; in fact, it's rendered obsolete (or at least deprecated) on its own platform with alarming rapidity. It's easy to reverse engineer; yeah, I could get some sort of obfuscator, or I could just write the good parts in C (which tends to be a good idea anyway). And .NET code is always susceptible to being replaced, precisely because it is easy to write. That .NET code you wrote that you thought would be around forever will not be around forever. And even if it does somehow manage to endure to the point where some hypothetical maintenance programmer might be confused by it, he's got a nuclear-strength debugger to help him figure everything out.



  • The Cold Doesn't Bother Us Anyway

    @bridget99 said:

    And frankly, I think that all this focus on maintainability of .NET code is just a bit misplaced.

    'Aaaaaaaaaaaaaaaand he's outta there!' I'm so so so glad I don't maintain any of your code, and I feel sorry for anyone who does. Also, I recommend a career change to politics, where I think you'll fit right in.



  • @RaceProUK said:

    @bridget99 said:
    And frankly, I think that all this focus on maintainability of .NET code is just a bit misplaced.

    'Aaaaaaaaaaaaaaaand he's outta there!' I'm so so so glad I don't maintain any of your code, and I feel sorry for anyone who does. Also, I recommend a career change to politics, where I think you'll fit right in.

    My whole point was that nobody maintains most of this crap. If you find a really elite shop that's using .NET, their core assets are almost certainly in a non-managed language. The .NET is just scaffolding. It's not the actual bridge, dam, skyscraper, etc. If .NET is actually what you're delivering to your clients, you're not really working in an elite shop. You're a consultant or something like that. And either way, your code is probably going to get thrown away. At least if you get it out the door, somebody might use it.


  • The Cold Doesn't Bother Us Anyway

    @bridget99 said:

    @RaceProUK said:
    @bridget99 said:
    And frankly, I think that all this focus on maintainability of .NET code is just a bit misplaced.

    'Aaaaaaaaaaaaaaaand he's outta there!' I'm so so so glad I don't maintain any of your code, and I feel sorry for anyone who does. Also, I recommend a career change to politics, where I think you'll fit right in.

    My whole point was that nobody maintains most of this crap. If you find a really elite shop that's using .NET, their core assets are almost certainly in a non-managed language. The .NET is just scaffolding. It's not the actual bridge, dam, skyscraper, etc. If .NET is actually what you're delivering to your clients, you're not really working in an elite shop. You're a consultant or something like that. And either way, your code is probably going to get thrown away. At least if you get it out the door, somebody might use it.

     




  • @RaceProUK said:

    @bridget99 said:

    @RaceProUK said:
    @bridget99 said:
    And frankly, I think that all this focus on maintainability of .NET code is just a bit misplaced.

    'Aaaaaaaaaaaaaaaand he's outta there!' I'm so so so glad I don't maintain any of your code, and I feel sorry for anyone who does. Also, I recommend a career change to politics, where I think you'll fit right in.

    My whole point was that nobody maintains most of this crap. If you find a really elite shop that's using .NET, their core assets are almost certainly in a non-managed language. The .NET is just scaffolding. It's not the actual bridge, dam, skyscraper, etc. If .NET is actually what you're delivering to your clients, you're not really working in an elite shop. You're a consultant or something like that. And either way, your code is probably going to get thrown away. At least if you get it out the door, somebody might use it.

     


    You can post memes, and spout the conventional wisdom you got from someone else all you want, but I'm the one attempting to engage in a rational discussion here.



  • @configurator said:

    @bridget99 said:
    It is a stupid, useless piece of cruft

    Except it shortens code that is needed in a lot of places, and avoids programmers mistakes as well.

    @bridget99 said:

    the infantile way in which it is named

    Following the naming convention of the entire platform doesn't seem infantile to me.

    I think that the naming convention Microsoft uses / recommends for .NET is pretty infantile. That would actually be the central point of this part of the seminar... the "recurring theme," so to speak.


  • Discourse touched me in a no-no place

    @bridget99 said:

    but I'm the one attempting to engage in a rational discussion here.
    It appears that you have posted this sentence on the wrong thread. Or website.



  • @Ben L. said:

    What is the semantic difference between a null string and an empty string?
     

    Depends upon the situation. In some cases, they're interpreted as the same thing.

    Consider the difference between NULL and zero. I have three shelves:

    • shelf1 reads "10" => I have 10 beers left.
    • shelf2 reads "0" => shelf is empty 
    • shelf3 reads NULL => I have not counted it yet.

    Now let's do the same thing with strings:

    • Mary's middle name is "Daisy" => she has a middle name, and it's known 
    • My middle name is "" => I have no middle name
    • Your middle name is NULL => I don't know if you have a middle name or not, so I need to ask you.

    Now, we had this discussion over in the Oracle Haters' Forum where Oracle decided the empty string is NULL. Check there for a deeper discussion, including the problems brought about by conflating the two as identical.

    @blakeyrat said:

    Jesus, the Bridget99 troll account just reels 'em in. What's wrong with you people?
     

    They'll learn, eventually. All part of the growing experience. I find myself checking the poster's identity more often these days.

     


  • The Cold Doesn't Bother Us Anyway

     Present for bridget99:




  • I can admit that maybe I've been a tad too doctrinaire on this issue. I guess everyone has differently shaped fingers and different opinions on what looks ugly.




    What do y'all think about String.Empty? It seems a little silly, in light of the fact that one can use "" to equal effect.



  • @bridget99 said:

    String.Empty?

    I hate it. I think it's useless, and not as clear as "".


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.