• Zatapatique (unregistered)

    // Basically, Frist

  • Erwin (unregistered) 
    
several thousand dense comments containing no further lines of code
  • Erwin (unregistered)

    Alas, Zatapatique eat me by a few seconds...

  • (nodebb)

    Honestly, I'm not sure if that comment is a statement of surrender or just an ironic joke. Either way, I get it.

    It's possible that the programmer started writing an introduction to the code, and got interrupted before continuing, and never came back to it.

  • Anonymous (unregistered)

    if (val == null) { return null; } return val;

    "val == null" is not "ReferenceEquals(val, null)" so the code above may actually be important, dependent on the equals implementation.

  • (nodebb)

    Independent of the usage of string and String: I always wonder why it should be so much simpler and more convenient to write something like String.Empty instead of just "".

  • L (unregistered) in reply to Melissa U

    old versions of .net created an instance of the empty string for each "" literal you had in code.

  • (nodebb) in reply to Melissa U

    (wide-eyed innocent) Well, because when you're compiling a big project, think of all the time the compiler has to spend converting all those Empty Strings into references to String.Empty... (/wide-eyed innocent)

    More likely because, as I've said before, TRWTF is programmers.

  • (nodebb)

    For a fun take on the:

    if (val == null)
    return null;
return val;

    Unity decided to ask "how do we pool objects and let callers know if an object is 'live'?" And in their infinite wisdom decided that properties are overrated and, instead, that they should overload the equality operator and turn "equal to null" into "is dead". So in Unity, the above code would turn a dead object into a real null.

  • Yazeran (unregistered) in reply to colejohnson66

    Oh man, talk about a virtual landmine!

    I'm glad i don't work with Unity....

    Yazeran

  • Hans (unregistered) in reply to colejohnson66

    Unity decided to ask "how do we pool objects and let callers know if an object is 'live'?" And in their infinite wisdom decided that properties are overrated and, instead, that they should overload the equality operator and turn "equal to null" into "is dead". So in Unity, the above code would turn a dead object into a real null.

    So, if you want to check if an object is dead in Unity:

    if (val == null && val is not null)
  // it's dead
  • (nodebb) in reply to colejohnson66

    So the opposite of a Val Killer?

    I wonder if we could get the opposite of its autograph.

  • (nodebb)

    In the WriteLine snippet, you don't actually need to pass anything, there's an overload with zero parameters, which does the same thing

  • iWantToKeepAnon (unregistered)

    If String and string are the same thing, then these lines are identical:

    writer.WriteLine(string.Empty); writer.WriteLine(String.Empty);

    TRWTF is a language that has two classes that are the same.

  • (nodebb)

    I'm pretty sure the first one is by someone who either doesn't use English as their primary language or is just bad at variable names. There is probably code later on that uses "if (isTrue)" to decide to do something, and this variable sets whether or not to do it.

  • ScottTheAccountant (unregistered)

    Of all of them, #2 is the only one that makes me twitch uncontrollably.

    And SQL queries should be all caps AS THE UNIVERSE INTENDED, LOL.

  • (nodebb) in reply to Melissa U

    For starters, C# conventions dictate to always use keywords over types, so the correct way to write it is: string.Empty.

    When it comes to why, well that is a super complicated topic, until .netcore 3 the literal "" resulted in constructing an empty string everytime while string.Empty just returned the pointer to the indirected empty string. So until .netcore 3 the correct way to address an empty string was by writing string.Empty.

    Now why is it complicated: Since the start of .net the way when and how strings got build and automatically indirected changed over multiple times, simply because a lot of VB developers happily used the + operator in iterations to create sub strings of sub strings which resulted in poor performance and high memory usage due to incompetent "developers". MS tried to get a handle on this by change the behavior based on what LinkedIn nonsense was popular at the moment, but you cannot really solve incompetence with tech, you just push it into another corner and this ongoing battle will most likely never end.

  • Java guy (unregistered) in reply to Anonymous

    dependent on the equals implementation.

    This is Java, == cannot be overridden and will always compare the values on either side.

  • Bob (unregistered)

    Sorry for playing devil's advocate, but I could imagine "isTrue" being a valid data field, for instance for an "Anecdote" model to keep track if it is a true story or made up. Of course I have not seen the surrounding code.

  • Dlareg (unregistered) in reply to Erwin

    Are you calling me dumb?

  • Klimax (unregistered) in reply to MaxiTB

    I think some of that was caused also by C++ devs who are used to concat by +.

  • basicAlly (unregistered)

    So, basically, the comment is very smol, but if it contained the full sentence, it would not be that smol anymore

  • (nodebb) in reply to Klimax

    Actually less so back in those days. Keep in mind, literature was out for .net way before it got released, so while it was still in the Beta phase. Most C/C++ developers were used to RTFM, it was "non-devs" and "career-devs" fresh from the university that had the "the compiler does all the work why read a manual" mindset. I'm not blaming both groups though, they were told by either marketing reps of the language vendor or their university teachers (in order to get KISS,DRY,YAGNI across as a guideline) it's the way it should be/is and sadly this mindset is very common till this day.

  • TopCoder (unregistered) in reply to Melissa U

    "" and string.Empty are not necessarily the same. The value of string.Empty can actually be modified at runtime using reflection. So not only are you ok in preferring"" over string.Empty, it is in fact safer.

  • MaxiTB (unregistered) in reply to TopCoder

    String.Empty is a static readonly intrinstic field. There is no way to to change it via reflection.

    https://github.com/dotnet/runtime/blob/1d1bf92fcf43aa6981804dc53c5174445069c9e4/src/libraries/System.Private.CoreLib/src/System/String.cs

  • (nodebb)

    I'm four days and 25 comments late to the party and yet nobody has picked this up:

    Boolean values can hold true or false.

    And FileNotFound

  • (nodebb) in reply to jeremypnet

    Guess after decades that joke got old for many here :-)

  • Craig (unregistered) in reply to MaxiTB

    In my experience, there is minimal difference in usage of concatenation between C# and VB.

  • CRConrad (unregistered) in reply to Mr. TA

    C#’s Pascal roots showing through.

Leave a comment on “Basically, a Smorgasbord”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article