Representative Line



  • Forum regulars might recall that I was lumped with the maintenance of a Silverlight application a couple of months ago. Since I just spent the entire day trying to get 3 frigging buttons to display on a screen (yes, the app's framework really is that painful), I though I'd indulge TDWTF with some of the gems that I discovered during my ordeal. First up is the crown jewel:

    ~CompletionGuideModel()
    {
      string x = string.Empty;
    }

    Yes, that is a destructor declaring a new variable and assigning a value to it. No, it's not autogenerated code.
    Yes, it's currently in production. No, I don't care enough to fix it.

    Close second has to be the comment on the code that invokes service operations, which takes the form of the following in 99% of the app:

    service.AsyncOperationCompleted += service_AsyncOperationCompleted; // unhooked
    service.AsyncOperation(param1, param2, paramN);

    Because as everyone knows, + removes event handlers and invoking services is so tricky that you have to copy-paste-edit the code (and comments) to do so.

    Rounding out the trifecta of failure is the fact that this app makes Remote Procedure Calls... to itself. Without using any standard RPC mechanism. Because doing things badly wasn't bad enough, they had to reinvent the wheel badly too.



  • @The_Assimilator said:

    Rounding out the trifecta of failure is the fact that this app makes Remote Procedure Calls... to itself. Without using any standard RPC mechanism.

    Ooooh, cool. Give us the details!



  • @The_Assimilator said:

     

    ~CompletionGuideModel()
    {
    string x = string.Empty;
    }

     

     

    I would guess someone wanted to set a breakpoint on that and see when the object was being destroyed.

     



  • @mott555 said:

    I would guess someone wanted to set a breakpoint on that and see when the object was being destroyed.

    If you ever have to do that, the correct way to do so is:

    int breakpoint = 42;



  • @The_Assimilator said:

    service.AsyncOperationCompleted += service_AsyncOperationCompleted; // unhooked

    Oh, is that what that does?

    @The_Assimilator said:

    Rounding out the trifecta of failure is the fact that this app makes Remote Procedure Calls... to itself.

    I'm doing R&D on what I consider a bleeding-edge project that will do that same thing, but only because the non-Silverlight version will run on Windows and use a local service process for part of its operation. For Silverlight, I had planned on faking a local service by making RPC calls to self.

    But that is absolutely the only scenario I can think of that wouldn't be absolute bullshit.



  • @mott555 said:

    I would guess someone wanted to set a breakpoint on that and see when the object was being destroyed.
    Why does that scare me even more now?  Oh that's right: non-deterministic gc, meaning there's a serious design issue related to the complexity of your object lifetimes.



  • @hoodaticus said:

    @mott555 said:
    I would guess someone wanted to set a breakpoint on that and see when the object was being destroyed.
    Why does that scare me even more now?  Oh that's right: non-deterministic gc, meaning there's a serious design issue related to the complexity of your object lifetimes.

    This has to be C++. There's no garbage collector in C++, is there? And if so, it shouldn't call the destructor; that's done by delete.



  • @TGV said:

    @hoodaticus said:

    @mott555 said:
    I would guess someone wanted to set a breakpoint on that and see when the object was being destroyed.
    Why does that scare me even more now?  Oh that's right: non-deterministic gc, meaning there's a serious design issue related to the complexity of your object lifetimes.

    This has to be C++. There's no garbage collector in C++, is there? And if so, it shouldn't call the destructor; that's done by delete.

    Silverlight = C#.



  • @mott555 said:

    @The_Assimilator said:

     

    ~CompletionGuideModel()
    {
      string x = string.Empty;
    }

     

     

    I would guess someone wanted to set a breakpoint on that and see when the object was being destroyed.

     

    If you need to know when a C# instance is destroyed, then you have a bigger problem.  Also, this would be heisen-behavior.  The very fact that a debugger (and probably an IDE) is running would likely change when the instance gets garbage collected.


  • @The_Assimilator said:

    @TGV said:

    @hoodaticus said:

    @mott555 said:
    I would guess someone wanted to set a breakpoint on that and see when the object was being destroyed.
    Why does that scare me even more now?  Oh that's right: non-deterministic gc, meaning there's a serious design issue related to the complexity of your object lifetimes.

    This has to be C++. There's no garbage collector in C++, is there? And if so, it shouldn't call the destructor; that's done by delete.

    Silverlight = C#.

    Really? I thought you could use any .net language for Silverlight.



  • @Xyro said:

    @The_Assimilator said:
    Rounding out the trifecta of failure is the fact that this app makes Remote Procedure Calls... to itself. Without using any standard RPC mechanism.

    Ooooh, cool. Give us the details!

    I barely escaped that particular code with my sanity intact, my mind has suppressed those memories, and there is no way in hell I'm going back there... sorry.

    @blakeyrat said:

    @The_Assimilator said:
    @TGV said:

    @hoodaticus said:

    @mott555 said:
    I would guess someone wanted to set a breakpoint on that and see when the object was being destroyed.
    Why does that scare me even more now?  Oh that's right: non-deterministic gc, meaning there's a serious design issue related to the complexity of your object lifetimes.

    This has to be C++. There's no garbage collector in C++, is there? And if so, it shouldn't call the destructor; that's done by delete.

    Silverlight = C#.

    Really? I thought you could use any .net language for Silverlight.

    blakey, for a guy who professes to hate pedantic dickweedery, you seem to be guilty of it rather often. Yes, you can use any language in the .NET ecosystem for Silverlight. This particular project uses C#. Happy?



  • @blakeyrat said:

    Really? I thought you could use any .net language for Silverlight.
    Nope.  Unles you consider this to be the same as "possible".



  • @The_Assimilator said:

    blakey, for a guy who professes to hate pedantic dickweedery, you seem to be guilty of it rather often. Yes, you can use any language in the .NET ecosystem for Silverlight. This particular project uses C#.

    I'm not pedantic, but I'm also not fucking psychic. You said SILVERLIGHT = C#, not THIS PROJECT = C#. That's not you leaving out a trivial detail, or using a slightly-incorrect example, or a typo-- that's you typing something COMPLETELY FUCKING DIFFERENT than what you meant to say. So while I'm sorry you lack the capacity to translate the random thoughts in your head into text, I make no apologies. Quite the opposite, you should apologize to me for wasting my time as I tried to verify your incorrect bullshit, when it turns out even you knew it was wrong.

    @The_Assimilator said:

    Happy?

    Not really.



  • @blakeyrat said:

    THIS PROJECT = C#

    Psh, unless he's on the .Net team in Microsoft, I highly doubt his project = C#.



  • @Xyro said:

    Psh, unless he's on the .Net team in Microsoft, I highly doubt his project = C#
    This.  That has to be the most pedantic dickweedery I've ever see.  Very nice!



  • @hoodaticus said:

    @Xyro said:
    Psh, unless he's on the .Net team in Microsoft, I highly doubt his project = C#

    This.  That has to be the most pedantic dickweedery I've ever see.  Very nice!

    That sounds like a challenge. Plus, there's no way that's the most pedantic dickweedery on this forum, so maybe you just haven't read enough threads to see that.



  • You're right, I just don't remember it.


Log in to reply
 

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