• Hanzito (unregistered)

    Makes me wonder: don't they have version control? Because I would want to check what else the person who touched that line has changed. For he's no King Midas.

  • 516052 (unregistered)

    Mysteries like this one are what git blame was made for.

  • DQ (unregistered)

    They'll know what it's for when in a few days the entire system crashes...

  • (nodebb)

    Most likely the line predates the git.

  • Rob (unregistered)

    I prefer the way Go and (since 22) Java handle _: it's not just a linter hint, it's a compiler instruction. You can't use it even if you tried.

  • (author) in reply to Allexxann

    Or whoever put it in is long gone and the commit message explains nothing.

  • John Melville (unregistered)

    Not there but the my psychic powers can invent a rational explanation for this code.

    1. At some point the code actually needed the value length / 8.
    2. The code that uses this variable goes away.
    3. C# has become more noisy about warnings over the past several versions. (This is a good thing. Warnings point out where you are probably not doing what you thought you were doing.) Every time I upgrade to a new c# compiler I have a handful of new warnings to resolve.
    4. After an upgrade someone gets a variable not used warning.
    5. An internet search shows that the discard char _ is immune from the variable not used warning. (This is a very minor WTF in itself. _ was a legal, and unremarkable variable name in C# 1.0. For backwards compatibility sometimes _ is a variable that just has a funny name and sometimes it is the discard operator.)
    6. That person changes the variable name to _ to shut the linter (which in this case is built into the compiler) up.
    7. WTF -- problem solved!
  • (nodebb)

    Hard to say for sure without taking a look at the surrounding code but it might be the kind of line you add temporarily to be able to set a debug breakpoint on it. I've see quite a few of those, forgotten in the rush to close a support ticket from an important client. 😅

  • (nodebb)

    This is C#, though it could be basically any language.

    Yes but no. If it was C++, one could imagine making a class something like this:

    class Absorber
{
public:
    template<class T>
        Absorber &operator =(const T &)
        {
        };
};

    Now make a variable of this type, call it, say, _, and you can "assign" anything to it.

    Of course, it does nothing to mitigate the mystery of the expression in the article's code...

    Addendum 2026-05-12 09:16: Bah, there should be a "return this;" in the function...

  • kythyria (unregistered) in reply to AGlezB

    Writing a weird noop just to have a breakpoint is slightly odd in C#, where System.Diagnostics.Debug.Break() exists. Granted, that's completely unconditional.

  • (nodebb)

    Dividing by 8 looks like converting a bit length into bytes. And it's a float 8.0f because they want fractional bytes?

  • (nodebb) in reply to Allexxann

    Most likely the line predates the git.

    cvsblame. As long as source control has been around, there's been a way to easily look at a file and see who contributed what parts of it.

  • Argle (unregistered) in reply to Remy Porter

    Remy Porter (author) in reply to Allexxann 2026-05-12 Or whoever put it in is long gone and the commit message explains nothing.

    This should probably be elevated to super-duper extra-special WTF. I submitted that clip late last week, and I was flattered to see that it was the story of the day today. Yesterday, I got an email with an attached resume of a candidate for employment. I'll be interviewing him this afternoon. I noted with some interest that he was a former employee of my company. What I didn't notice was the name of a project that he worked on. What a co-interviewer noticed was that we all know the project primarily by its acronym, not its full name, and he reduced it to an acronym and pointed it out to me. I thought "uh-oh." Today's WTF, and dozens of others, passed through his hands. Wish me luck with this one.

  • Conradus (unregistered) in reply to 516052

    And git blame kicks up a name nobody on the team recognizes; presumably he left years ago. What now?

  • Conradus (unregistered) in reply to Remy Porter

    Ah, yes, the ever popular "Fix bug" commit message.

  • Fizzlecist (unregistered) in reply to 516052

    We started off using on-prem git, then moved to Bitbucket before finally ending up with Github. With each move the commit history was lost (keeping it wasn't possible at the time). Now when there's an issue there's only one person to blame...

  • mihi (unregistered) in reply to Fizzlecist

    If it all were git repos, the person is to blame who did not check how to import/push existing git repos to the new service. And regardless which git service, there is always a way to push existing history there (if you spend a bit of time, it does not even matter which source control it came from). It may be impossible to have the original commiter end up in git's committer field (so blame is a s two-step process as you first need the commit hash to check the commit message where the original commiter ends up), depending on whether it is allowed to push foreign commits. But for GitHub/BitBucket that surely is not a problem as they allow it.

  • (nodebb) in reply to Steve_The_Cynic

    Isn't that called std::ignore?

  • (nodebb) in reply to thosrtanner

    That's entirely possible...

  • (nodebb) in reply to Jaime

    History is often lost when going between source control systems. There are lots of tools today to convert repositories between various source control systems, but in the past, they generally didn't do more than create a repository and import the source code you have.

  • Officer Johnny Holzkopf (unregistered)

    Maybe the calculation for _ is len(gth) 8th to accomodate to some crazy non-metric unit system, like "something's width is measured as n eighths of text length"? It doesn't matter - if it's not needed anywhere, use _ to discard any values measured in degree footgallon per 1/32nd square-ounce-dozenpound in 1/8 cup Fahrenheit of pixel-inches...

  • (nodebb)

    Ah yes, the discard placeholder. This one has a ton of history to it and is something non-.net developers will have a hard time to wrap their head around. And LLMs, but eh, not that token generators have a ton of other issues by design when being abused as a tool instead of as a toy.

    But I regress, see, it's very important to understand that the .net framework platform is a framework not a language. While for example Java is a non-standardized leftover monolith of a failed Sun OS, C# is just yet another language out of hundreds which use and have to follow the .net ISO standard specifications like the CLS (common language specification) and CTS (common type system). Here naming capabilities are defined and yes, _ is a totally valid name for an entity technically. In fact, if you follow CLS by the letter (by for example not using unsigned types), you can even attribute your types with this: https://learn.microsoft.com/en-us/dotnet/api/system.clscompliantattribute

    And now things complicated because when they introduced named tuples (https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/value-tuples) they needed said discard placeholder for deconstructions. And they did what happened till the field keyword for every single added feature, they made the placeholder conditional, not a keyword (in fact there is barely any keywords in c# compared to other languages).

    You see, if there is a member defined named _ then in the scope of this member the discard placeholder is simply not available and the member is used instead. It doesn't matter if it's a field, a variable or a property. They did it to be backwards compatible but obviously it means the developer has to keep the context of feature like this in mind and a single line of code will tell you nothing of what is actually going on.

  • (nodebb)

    All true as a matter of fact.

    But I suspect the number of members actually named _ in the wild are very few and far between. Such that as a working assumption, somebody new to a particualr codebase can use the discard operator freely without concern.

    If they start introducing weird bugs, now it's time to go through the relevant codebase looking for CLS-complaint, but nonetheless very bad practice members cryptically named _. And rename them to something meaningful.

    Addendum 2026-05-13 08:06: Of course that doesn't help the compiler-writers who have to deal with that ambiguity as you say. But they're outnumbered by customer developers probably 100K to 1.

Leave a comment on “Underscore Its Unimportance”

Log In or post as a guest

Replying to comment #697930:

Log Out

« Return to Article