• Tom (unregistered)

    Could be I'm missing something, but if 'o' is null, wouldn't

    return (ConcurrentQueue<AppointmentCuttOff>)ViewState["lstAppointmentCuttOff"]

    throw an exception?

  • Destructorizer (unregistered)

    The real wtf is the coder that wants to cast null into somethiing else. Compressing the line into "Cleverness" makes the best WTF. We all want to shine with a glorious line, yet, this will crash just in time.

  • Prime Mover (unregistered)

    Gosh. Computer programmer is dyslexic. Hold the front page.

  • Mindless (unregistered)

    return (ConcurrentQueue<AppointmentCuttOff>)ViewState["lstAppointmentCuttOff"] causes the WTF when it crashes on a Null reference.

  • (nodebb)

    Re: Hungarian notation.

    It's wrong on two levels. It's trying to be "Systems" Hungarian (where the wart tells you the type), which is only just barely HN at all, and it fails at being SHN because it's got the wrong wart on it.

    The original HN, "Applications" HN, was a workaround for the shortcomings of C"s type system, where "flavours" of data cannot be easily indicated. Is this unsigned a count, an indication of size, what? Is this char * a pointer to a single character or to a NUL-terminated string? If it's a NUL-terminated string, does it contain raw text? HTML-encoded text? Something else?

    It's mostly unnecessary now, except that there is a growing number of languages where variables don't have explicit types, and it helps a lot to indicate what kind of data your variable is supposed to hold.

    Also:

    While there are a queue of appointments

    Should be:

    While there is a queue of appointments

    The thing that there is is a queue.

  • Dennis (unregistered)

    This does not seem that bad to me. In some languages, typecasting null values will lead to a NPE. If in doubt, I'd probably do the same.

  • Mirko (unregistered) in reply to Tom

    No, in .NET you can perform casting on a null value.

  • DFYX (unregistered) in reply to Tom

    Assuming this is C#, casting null is perfectly acceptable as long as the target type is nullable. Obviously it must be nullable or we couldn't explicitly return null either.

  • (nodebb)

    1. Without the "if null" try having your average developer set a breakpoint on the the code if the element in viewstate is null, but not break if it contains something...

    2. Since we do not see the call to the setter, we can not know anything about the instance(s) being used and if they are potentially shared across threads.

  • (nodebb) in reply to TheCPUWizard

    Since we do not see the call to the setter, we can not know anything about the instance(s) being used and if they are potentially shared across threads.

    If they managed to access ViewState across threads, then that code would be the real star of this WTF. ViewState only exists for about half of the ASP.Net request pipeline, which is handled on a single thread and typically lives only a few milliseconds.

  • Greg (unregistered) in reply to TheCPUWizard

    I have no idea what IDE you're using but all three I use have something called conditional breakpoints. They usually slow down the debugging process by a non negligible amount but that's something else.

  • (nodebb) in reply to Jaime

    The idea of anything in ViewState (conceptually objects that get sometimes serialized to the client or to a database) being used for concurrency control is both laughable and worrying. That this works at all in this application…

  • Cidolfas (unregistered)

    Until this was pointed out I assumed the variable was called "1stAppointmentCutoff" (as in "first").

    Either way, this is a very mild WTF compared to what else we've seen.

  • Brian (unregistered)
    The entire get block could just be: return (ConcurrentQueue<AppointmentCuttOff>)ViewState["lstAppointmentCuttOff"]

    To really nitpick it, you don't even need a block there. Just "get => (ConcurrentQueue<AppointmentCuttOff>)ViewState["lstAppointmentCuttOff"];"

  • Trust Me I'm Not a Robot (unregistered)

    Am I the only one to see this? I kept reading "lst" as "first", thinking that initial character was the digit 1 - until I remembered that you can't begin a variable name with a numeral. So it's really a lowercase L - which means it's an abbreviation for "last", not "first".

    Hungarian notation has its usual problems, and using visually similar characters just makes it worse.

  • ooOOooGa (unregistered)

    With all the talk of bad variable naming and no one is going to point out how terrible it is to have a variable named 'o'?

  • I'm not a robot (unregistered) in reply to TheCPUWizard
    Without the "if null" try having your average developer set a breakpoint on the the code if the element in viewstate is null, but not break if it contains something...
    Even if you assume that the "average developer" doesn't know how to use conditional breakpoints, it's absurd to suggest that the committed code should be littered with that stuff "just in case" - let the "average developer" add those hacks in when they're relevant for a bug that needs to be diagnosed, and take them out again afterwards. Otherwise you could just as well justify nonsense like "if (list.Length == 0) return list; else if (list.Length == 1) return list; else if (list.Length == 2) return list; ..."; after all, an "average developer" might some day need to set a breakpoint that only applies when the list has a particular length, or when a string has a particular first character, or any number of other criteria.
  • Hasseman (unregistered) in reply to Trust Me I'm Not a Robot

    That is called lexical distance. Certain characters should be avoided in variable names if it can lead to confusion.

  • WTFGuy (unregistered)

    I'm just super-impressed our developer managed to spell "cutt" consistently between the typename and the viewstate keyname. I'd much sooner have expected one to be "Cutoff" and the other other "Cuttoff".

    As to the ConcurrentQueue, everybody knows ASP.Net is multi-threaded to handle all those pages being "simultaneously" served to different users. So of course we need to use a concurrent data structure for our internal queue of cut(t)offs.

  • Officer Johnny Holzkopf (unregistered) in reply to WTFGuy

    Another interpretation of "CuttOff" could have been "cut to FF" - "CutToFf" or "cutToFF", BeCause messingWith uPper and loWer casE 1s Fun.

  • (nodebb)

    Maybe the developer is a Kasabian fan.

  • Chris (unregistered)

    In C#, the ConcurrentDictionary has AddOrUpdate as a method, but the standard Dictionary does not. I would be lying if I didn't say laziness has caused me to use a ConcurrentDictionary in single-threaded usage.

  • Chris (unregistered) in reply to Greg

    What I find strange is that if you put a condition on a breakpoint, it slows everything down a lot. But if you put an if (condition) // something to put a breakpoint on, it doesn't slow down at all. I guess the way it accesses the variables for evaluating the condition are completely different in each case.

  • (nodebb) in reply to Chris

    What I find strange is that if you put a condition on a breakpoint, it slows everything down a lot. But if you put an if (condition) // something to put a breakpoint on, it doesn't slow down at all. I guess the way it accesses the variables for evaluating the condition are completely different in each case.

    That's basically it. Here's how I think of it:

    • You have some compiled code under investigation, which executes in one execution context (which I'll call the "main" context).
    • You have a debugger, which executes in a separate execution context (often, but not always, a parent of the main context).
    • A breakpoint triggers a switch from the main context to the debugger context
    • If the breakpoint is a conditional breakpoint, the debugger then inspects the state of the main context, extracts the variables of interest, and calculates the condition. If false, switch back to the main context and continue, else update the UI.
    • However, if the condition is in the compiled code, then the main execution context never reaches the breakpoint, and no switching of contexts or inspection of an external process's state is necessary until the condition is met.

    In theory, in an interpreted language, the debugger could inform the interpreter of the conditional breakpoint, and the interpreter could treat the condition check as "injected" code and execute it as part of the main execution context, and only switch contexts if required. I am not sure if any interpreted language debugging environments do this, but it should result in no slowdown during execution (at the cost of a tiny overhead during the interpretation step).

  • (nodebb)

    Is this really a big evil or simply harmless debug code that wasn't removed?

    As others have said, conditional breakpoints are expensive--there isn't really such a thing as a conditional breakpoint, the breakpoint always fires (which is an expensive operation) then the environment checks the conditional before presenting it to the user.

    Add to this the fact that C# (and I think any other managed language) doesn't support the hardware-assisted breakpoints that can make certain types of conditionals fast. (I used to love break-on-write. Now you have to make something a property that isn't automatic to do this.)

  • (nodebb) in reply to Loren Pechtel

    Is this really a big evil or simply harmless debug code that wasn't removed?

    Given the amount of discussion it has caused here, I wouldn't call it harmless debug code, but I wouldn't call it a big evil either.

    And yeah, hardware breakpoints (especially break-on-write) were good. They were about the only good thing about Turbo Debugger 386 back in the DOS days. It was glacially slow at actually switching control to the debugger when you did hit a breakpoint, while on the same PC, Turbo Debugger 286 would do it so fast you'd miss it if you blinked at that exact moment, but TD286 didn't support hardware breaks.

  • NotAThingThatHappens (unregistered)

    You often have 'hotspots' in your code where you need to place a bereakpoint often. I see no problem in making that part of the code a little easier to debug by placing a (somewhat) unnecessary breakpoint.

    I am an oldschool developer that started when the c64 was hotstuff. These days, 'if' statements like the one in the article are basically free. I keep reminding myself of this fact when I wite code 'for clarity' (not for 'speed' or minimum CPU-cycles).

    Yes Tom, the 'hard cast' will bring down C#. You can use the 'soft cast', which Remy prolly meant, but he sometimes makes mistakes, like he re-wrote (incorrectly) my submission a few weeks back.

    Softcast.

    return ViewState["lstAppointmentCuttOff"] as ConcurrentQueue<AppointmentCuttOff>

  • (nodebb) in reply to Jaime

    Jamie not difficult at all.....

    This is not about ViewState being accessed by multiple threads, but rather an item in viewstate....

    While this is normally the result of serialization/deserialization, that is not the only way...

    ViewState["mykey"] = someobject

    Two lines later (same thread same request

    ViewState["mykey"].Operation()....

    The original someobject could be being accessed by many threads..

    FYI: this is not just theory, have seen it.

  • Appalled (unregistered)

    Are "CutOffs" something to do with this new-fangled transgender society we live in today?

  • (nodebb)

    C language is over my head

  • eric bloedow (unregistered)

    wow. this triggered an OLD memory: when i saw "1st" i read it as "LIST"...on a TRS80 computer, if you type "LLIST"it tries to PRINT the current program, and if you don't have a printer connected, TOTAL SYSTEM FREEZEUP. with no way to recover but a power-cycle. WTF?!

Leave a comment on “A Cutt Above”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article