• epsalon (unregistered) in reply to GoatCheez
    GoatCheez:

    Alex forgot to mention that Stefanie was brought in to figure out why their server was constantly beeping at odd intervals ;-P




    Actually, 892 is an even interval!
  • Kevin (unregistered) in reply to BradC
    BradC:

    Ah, score one for VB.Net, which supports optional arguments.

    Take that, C# !!!



    I hope that was a joke. C# has method overloading which can make a method accept different sets of arguments. The optional arguments are not marked with an "optional" keyword, but it is the same effect.

    Take for instance the System.Collection.ArrayList constructor. You can create a new ArrayList with any of the following:

    new ArrayList()
    new ArrayList(int capacity)
    new ArrayList(ICollection c)

  • (cs) in reply to Dude
    Anonymous:
    Alex Papadimoulis:

    Scott Stanchfield was tasked with optimizing memory usage in a Java application and found a way to shave a few bytes left in by an intern with a sense of humor ...

    public class ValidationMessage
    {
    //internal members string messageId;
    string messageText;
    string helpLink;
    /* ... */ double cheeseburger;
    char broiled;
    long time;

    //helper functions /* ... */ }



    I guess we know where that guy is going to be working


    In fact, the part Alex snipped includes the initialization of the string messageText to "Do you want fries with that?".
  • JiffyPop (unregistered) in reply to juvenile

    The worst (?) one I ever saw was from this person who was extremely intelligent, who created a project acronym that, for obvious reasons, never got used:

    Common Library Internals Tying Original Real Income Server



    My favorite almost-used name was for a company that wanted to have a way of tracking business prospects.

    It was changed before deployment, but I still think "P-Tracks" is pretty bad.

  • (cs) in reply to Kevin
    Anonymous:
    BradC:

    Ah, score one for VB.Net, which supports optional arguments.

    Take that, C# !!!



    I hope that was a joke. C# has method overloading which can make a method accept different sets of arguments. The optional arguments are not marked with an "optional" keyword, but it is the same effect.

    Take for instance the System.Collection.ArrayList constructor. You can create a new ArrayList with any of the following:

    new ArrayList()
    new ArrayList(int capacity)
    new ArrayList(ICollection c)



    Unfortunately, the C# method as described above involves more code for the function overloading.
  • John (unregistered) in reply to JiffyPop

    Best one I ever saw was the Personnel Management System.  We joked that the server would go down once a month.

    It was later changed to the Personnel Record System.

  • Martin (unregistered)
    //Enable or disable controls in the form
    private void EnableDisable(bool blnEnable) { ... }

    The question here is: WHAT is it enabling?

    Normally you might see something like EnableWindow or EnableButton or some such.
    So, are you enabling a disable? Wouldn't that mean that passing in True
    really means you're disabling? If so what are you disabling? And, if you pass
    in False, does that mean you are disabling the disable and thus actually
    enabling? On top of that, precisly WHICH controls are you enabling or disabling,
    once you figure out which input yields the desired result.

    It all makes the head explode!

  • (cs)
    Alex Papadimoulis:

    I suppose I'll leave you with this comment that Miki Watts came across ...

    Price = 0e-5; /* JKF 1999-07-21 I hope it's not a bug */


    They should have just said
    	/* JKF 1999-07-21 I hope this doesn't end up on TheDailyWTF */


  • Dazed (unregistered) in reply to JiffyPop
    Anonymous:
    My favorite almost-used name was for a company that wanted to have a way of tracking business prospects.

    It was changed before deployment, but I still think "P-Tracks" is pretty bad.

    I know of a major European airport that used to have a Passenger Information System. Honest.

  • Reed (unregistered) in reply to EvanED
    Alex Papadimoulis:

     * Note: This should probably be a static method. Since it isn't, 
    * you will need to reference it will a null object:
    * COrderSummary *obj = NULL;
    * obj = obj->XMLParse(someXMLString);
    * ***/


    What? This is garaunteed to segfault. Always.  Every time.

    (Maybe they meant this? COrderSummary obj; obj.XMLParse(...);)
  • wateva (unregistered) in reply to Dazed

    and how do you turn it off?  <g>

  • wateva (unregistered) in reply to Dazed
    Anonymous:
    Anonymous:
    My favorite almost-used name was for a company that wanted to have a way of tracking business prospects. It was changed before deployment, but I still think "P-Tracks" is pretty bad.
    I know of a major European airport that used to have a Passenger Information System. Honest.


    Anonymous:
    and how do you turn it off?  <g>

  • (cs) in reply to juvenile
    juvenile:
    Anonymous:
    Anonymous:
    juvenile:

    I get the abbreviation with initials, but what else does puhse stand for?

    Two syllables...pronounce it.



    OK, let's see;
    Two syllables: puh-se
    • puh, as in Winne the Pooh?
    • se, as in Standard Edition?

    Pronounced: [pu:se]

    Not funny at all.

    When I first read it, I read it aloud with a long 'u', silent 'h', soft 's' and silent 'e' - sorta like 'piews' - had no clue - been a long f*g week - tgif! Gotta go home to wife/kids and not get me some.



    Better just stick to the wife.
  • Mike D (unregistered)

    I once heard that Sun found something like the following deep in the Solaris scheduler (they were taking a look at the code before handing it to some high paying customers):

    int funcname(...)
    {
      int blow = 0; // move unsched jobs to blowoff stack
      static int job = 1; // current job index
    
  • (cs) in reply to Martin
    Anonymous:
    //Enable or disable controls in the form
    private void EnableDisable(bool blnEnable) { ... }

    The question here is: WHAT is it enabling?

    Normally you might see something like EnableWindow or EnableButton or some such.
    So, are you enabling a disable? Wouldn't that mean that passing in True
    really means you're disabling? If so what are you disabling? And, if you pass
    in False, does that mean you are disabling the disable and thus actually
    enabling? On top of that, precisly WHICH controls are you enabling or disabling,
    once you figure out which input yields the desired result.

    It all makes the head explode!



    Nah, the real problem is that the brain processes it as an inherent contradiction...Is it Enable or Disable? Sure, you look at it for a second, and you get it, but that kinda stuff builds up, and you end up with seriously unreadable code.
  • Henrik (unregistered) in reply to John Bigboote

    buttCheek = ass.split('|')[x]

  • SilverDirk (unregistered) in reply to Reed
    Anonymous:
    Alex Papadimoulis:

     * Note: This should probably be a static method. Since it isn't, 
    * you will need to reference it will a null object:
    * COrderSummary *obj = NULL;
    * obj = obj->XMLParse(someXMLString);
    * ***/


    What? This is garaunteed to segfault. Always.  Every time.

    (Maybe they meant this? COrderSummary obj; obj.XMLParse(...);)

    Um, no, it wont... as long as no fields are accessed in the method.

    The WTF here is that they bothered to comment the thing as "should be static" instead of sticking a freaking 'static' keyword on the front. If its a static method, declare it like one.

    You would then call it as COrderSummary::XMLParse(someXMLString)

    By not declaring it static, someone in the future might decide to access a member var in the code, which would cause all static usage of it to segfault. (or maybe randomly segfault based on whether the var was needed or not)

    Anyway, much better to get a segfault than to get completely random behavior and possible memory corruption, which is what would happen if you call it without initializing the pointer and the method is no longer acting static.

  • Benjamin Smith (unregistered) in reply to kwan3217
    Anonymous:

    Buried inside of a large ACH validation routine, Stefanie found this line ...

    if (i == 892)  syscall_beep();

    I've done stuff like this in a lot of programs. It's obviously there for debugging, and probably he set a breakpoint on syscall_beep(). There obviously was a problem with thing 892, and in an effort to debug, and not have to trace through the previous 891 things, you put in a line of code with no effect, inside of an if, and break on it.

    <obligatory>The real WTF is that they forgot to take it out.</obligatory>


    Having been caught with my pants down one too many times managing a hosted PHP application, I wrote a function called DevMode() that returns true if the script is being run on the development server, false if not.

    So then it would look something like:

    if (DevMode())
     if (SomeCondition)
      syscall_beep();

    That solves this problem once and for all!
  • A. Nony Mous (unregistered) in reply to BradC
    BradC:
    Alex Papadimoulis:
    And while we're picking on the VS Tools for Office, following is the code required to call Excel's Dialog Show from C# ...

    if(xlApp.Dialogs[Excel.XlBuiltInDialog.xlDialogOpen].Show(sTextName,
      Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
      Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
      Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
      Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
      Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
      Type.Missing, Type.Missing, Type.Missing, Type.Missing) == true) { ... }

    Ah, score one for VB.Net, which supports optional arguments.

    Take that, C# !!!



    More like score -1 for Office .NET objects... One of the biggest PITA to work with.

    VB.NET isn't much better.
    oExcelDoc = oExcel.Workbooks.Open(ExcelDocName, , True, , , , True, , , False, False, False, False)
  • The Anonymous Coward (unregistered) in reply to Reed
    Anonymous:
    Alex Papadimoulis:

     * Note: This should probably be a static method. Since it isn't, 
    * you will need to reference it will a null object:
    * COrderSummary *obj = NULL;
    * obj = obj->XMLParse(someXMLString);
    * ***/



    What? This is garaunteed to segfault. Always.  Every time.

    No, sadly, it's not, because this is C++.  If the method were virtual, it would segfault, but in C++ the method isn't virtual unless it's declared virtual.  For non-virtual methods, you can do this (or at least not every compiler is going to kill you for it); but if the method dereferences the "this" pointer, or tries to access any data member (other than a static one), or tries to call a virtual method, then it will segfault.

  • (cs)

    I'm gonna get my Cumulative_Rate all over your Associated_Skill, bee-atch!

  • (cs) in reply to Kevin
    Anonymous:
    BradC:

    Ah, score one for VB.Net, which supports optional arguments.

    Take that, C# !!!



    I hope that was a joke. C# has method overloading which can make a method accept different sets of arguments. The optional arguments are not marked with an "optional" keyword, but it is the same effect.

    Take for instance the System.Collection.ArrayList constructor. You can create a new ArrayList with any of the following:

    new ArrayList()
    new ArrayList(int capacity)
    new ArrayList(ICollection c)

    I think you've misinterpreted my comment.

    When creating your own stuff, method overloading is the preferred technique. But when CALLING someone else's code that uses optional parameters (like MS Office apps), in this case VB.Net is vastly superior to C#.

    Alex's example in C#:

    if(xlApp.Dialogs[Excel.XlBuiltInDialog.xlDialogOpen].Show(sTextName,
      Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
      Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
      Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
      Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
      Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
      Type.Missing, Type.Missing, Type.Missing, Type.Missing) == true) { ... }
    <FONT face="Times New Roman">The exact same code in VB.Net:</FONT>
    if (xlApp.Dialogs[Excel.XlBuiltInDialog.xlDialogOpen].Show(sTextName) = true) Then ...
     
    <FONT face="Times New Roman">VB.Net automatically takes care of it all when compiled. This makes using VB.Net massively</FONT>
    <FONT face="Times New Roman"> simpler for Microsoft Office automation than C#. Not that its impossible with C#, just a royal pain in the rear.</FONT>
    <FONT face="Times New Roman"></FONT> 
    <FONT face="Times New Roman">See http://blogs.msdn.com/eric_carter/archive/2004/04/15/114079.aspx </FONT>
     
  • (cs)

    Here are a few funny names I've come across...

    // S-curve lookup table
    private byte[] sLut;

    We also have a fingerprint scanning device from a manufacturer named Heimann. We've had many good laughs about this for years. The image quality is best if your fingers are not too dry, so we apply moisturizer to the fingers before scanning if there are problems. During a particular sales demo, my boss said to the client "Now that your finger is all lubed up, you can stick it in the Heimann".

  • Scott (unregistered) in reply to John Bigboote

    That's why it's an exception.

  • Bustaz Kool (unregistered) in reply to John Bigboote
    John Bigboote:
    juvenile:

    A better name might be:

    catch (ProblemUndoingShortSaleYesterday pussy)



    If I caught more of that type of exception in college, I might not be a programmer today. It's a pretty rare scenario for most coders.

    It's not rare if you develop the right kind of driver.  Just put your portal into protected mode and you'll be interfacing with the system internals in no time.  Remember, it's not the size of the download that's important here, it's how you handle the buffer overflow...

  • !false (unregistered)

    Sounds like that intern rode the:

    short bus;

    to work.

  • (cs) in reply to Reed
    Anonymous:
    Alex Papadimoulis:

     * Note: This should probably be a static method. Since it isn't, 
    * you will need to reference it will a null object:
    * COrderSummary *obj = NULL;
    * obj = obj->XMLParse(someXMLString);
    * ***/


    What? This is garaunteed to segfault. Always.  Every time.

    (Maybe they meant this? COrderSummary obj; obj.XMLParse(...);)


    A couple people have already corrected you, but there weren't any explanations for why things are as they are. Consider a C++ "compiler" that translates code into straight C instead of into some machine code. I don't know if any are still in common use, but the compiler Stroustrup worked on during the development of C++, CFront, at least worked like this. It's instructive to see what it does to common constructs. Consider a class:

    class SomeClass {
           int someData;
        public:
           int someMethod(int anArgument);
    };

    This would get translated by our CFront-like compiler into:

    struct SomeClass {
        int someData;
    };

    int SomeClass__someMethod(struct SomeClass* this, int anArgument);

    In other words, it drops all the member functions out of the class declaration, as well as all the access modifiers. (It checks access separately; we won't consider that.) It then makes a prototype for each of the member functions as a free function that takes a pointer to the class as the first argument. (The name's also mangled, usually worse than what I show above.)

    Now the implementation of functions:

    int SomeClass::someMethod(int anArgument)
    {
        return someData * anArgument;
    }

    This would turn into:

    int SomeClass__someMethod(struct SomeClass * this, int anArgument)
    {
        return this->someData * anArgument;
    }

    Anything that's a reference to a member variable is prefixed with "this->". Now how does a call get translated?

    This:

    SomeClass someObject;
    someObject.someMethod(5);

    Becomes:

    SomeClass someObject;
    SomeClass_someMethod(&someObject, 5);

    And

    SomeClass* somePointer = new SomeClass;
    somePointer -> someMethod(5);

    Becomes:

    SomeClass* somePointer = malloc(sizeof(SomeClass));
    SomeClass__someMethod(somePointer, 5);

    Note that there's no dereferencing of somePointer in there at all. This means that if you say something like:

    NULL -> someMethod(5);

    (ignore that it would need a cast to tell it what type NULL is) then it will just be translated to:

    SomeClass__someMethod(NULL, 5);

    Again, no dereferencing. The only problem comes up in during the execution of someMethod, in that 'this' is NULL and the implementation dereferences 'this'.

    If the function is conceptually static, then it doesn't access any member variables (and doesn't call any nonstatic functions either, which rules out anything virtual). This means that the compiler doesn't insert this-> before anything, so 'this' is never dereferenced.

    You can play around with this if you'd like. You can actually get some pretty weird errors. For instance, if you do something like the above accidentally, and haven't seen the issue before, the fact that it gives an error about, say, address 0x4 being not readable when it's running someMethod might take some time to sort out.

    Anyway, just one more aside: virtual functions. These are stored as function pointers inside the struct. So if someMethod was virtual, then SomeClass would be translated instead to:

    struct SomeClass {
        int someData;
        int (* someMethod) (struct SomeClass* this, int anArgument)
    };

    and then the function call with pointers would be:

    somePointer->someMethod(somePointer, 5);

    (Note that somePointer is repeated here.) Thus HERE because it needs to access the someMethod field of *somePointer, if somePointer is NULL it will segfault.

    (Actually, the description of virtual functions is a bit simplified from practice. In reality, a vtable is created for each class, and the pointers to virtual functions go in the vtable, not the individual objects. The objects then hold pointers to the vtable. There are a lot of efficiency reasons for this. However, implementing something like the above would be perfectly legal, AFAIK, according to the C++ spec.)

    Also note that the above is just my understanding; I'm not a compiler writer, so I can't say that this is exactly how things are done in practice. However, I've read a lot about C++ that would affirm what I said and seen a lot of bugs that manifest themselves in a way that is consistant with the above and not much else, so I'm pretty confidant that this is at least a good approximation to what's happening.
  • (cs) in reply to SilverDirk
    Anonymous:
    The WTF here is that they bothered to comment the thing as "should be static" instead of sticking a freaking 'static' keyword on the front. If its a static method, declare it like one.


    I don't by default put blame at the author of that comment. There are a couple reasons.

    First, the guy who originally wrote the method (which may or may not be the same person!) might not have understood or known about static methods. I can't decide if this is WTF-worthy. I'd LIKE to say it is, because static methods are something that aren't too difficult that seem to me like they should be in the arsenal of anyone programming C++ or Java... but I don't know how widespread exposure is. For instance, in my four years as an undergrad, I don't think I heard even once about static methods. This includes two semesters of C++ instruction. On the flip side, the dept is not exactly known for producing stellar programmers. It's not a terribly great department, and we've gotten comments from industry that we should improve instruction in programming itself. So it's possible that we're the exception in this.

    Second, suppose either it's a different guy who made it non-static in the first place, or the same person but he's since expanded his toolkit to include static methods. It's possible that he's not in a position now to change it. If the class's use is widespread, then either he might be too lazy to change it (somewhat WTF-worthy) or not have the authority to change it.

    In short, I think this IS a WTF, and belongs on this site, but at the same time I think it's one of the lesser ones that shows up here.
  • Daniel Millen (unregistered) in reply to BradC
    BradC:
    Alex Papadimoulis:
    And while we're picking on the VS Tools for Office, following is the code required to call Excel's Dialog Show from C# ...

    if(xlApp.Dialogs[Excel.XlBuiltInDialog.xlDialogOpen].Show(sTextName,
      Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
      Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
      Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
      Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
      Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
      Type.Missing, Type.Missing, Type.Missing, Type.Missing) == true) { ... }

    Ah, score one for VB.Net, which supports optional arguments.

    Take that, C# !!!

    Ahem...  Params[]

    Captcha: awesomeness (previous was genius, when I forgot to click quote...)

  • (cs) in reply to Jonathan Pryor
    Anonymous:
    On a vague tangent, I really wish I could find a compiler/preprocessor that supported named arguments in C,  C++, C#, or Java. Everytime I touch win32 code after a month or two elsewhere I come back and end up clueless as to what arguments are doing, especially surrounded by a random number of NULLs.
    This is actually fairly easy to do within the C++, C#, and Java languages.  Stroustrup gave an example in The Design and Evolution of C++, showing that named arguments weren't necessary.

    The solution is to introduce a new type with methods which return itself.  For C++:
    class window_args {
    public:
        window_args& color (Color c) {/* ... */ return *this;}
        window_args& border (Border b) {/* ... */ return *this;}
        window_args& title (const std::string& s) {/* ... */ return *this;}
        /* ... */
    };
    void* CreateWindow (window_args args);
    Usage thus becomes:
    void* p = CreateWindow (
        window_args().color (Color::Blue).title ("insert title here));
    This pattern is readily extended to C# and Java.
    There's a specific name for that API pattern: such interfaces are called fluent interfaces, and it's very much underused.
  • Anonymous (unregistered) in reply to Daniel Millen

    [quote user="Anonymous"][quote user="BradC"][quote user="Alex Papadimoulis"]And while we're picking on the VS Tools for Office, following is the code required to call Excel's Dialog Show from C# ...

    if(xlApp.Dialogs[Excel.XlBuiltInDialog.xlDialogOpen].Show(sTextName,
    Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
    Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
    Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
    Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
    Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
    Type.Missing, Type.Missing, Type.Missing, Type.Missing) == true) { ... }

    [/quote]

    Ah, score one for VB.Net, which supports optional arguments.

    Take that, C# !!!

    [/quote]

    Ahem...  Params[]

    Captcha: awesomeness (previous was genius, when I forgot to click quote...)

    [/quote]

    Params[] doesn't even begin to address the same problem as optional arguments. While it IS possible to use params to give you optional arguments, there are a LOT of shortfalls.


    1. No static type checking of the types. Optional arguments gives you static checking; params doesn't. The only exception to this is if all the parameters are the same type. If you have "optional parameters" of different types, you have to go with the most generic. In many cases, this will be Object. Checking that you're passing in an Object doesn't get you much.

    1. There isn't even static checking of the NUMBER of arguments.

    1. The code for dealing with retreiving the arguments is too complicated. Instead of referring to them by name, you have to refer to them as, e.g., arguments[5], at least long enough to put them into another variable.

    1. Figuring out what to PASS IN to functions that would do this is too complicated, as you don't get help from intellisense; all you see is that there are some number of variable arguments. With optional arguments, you get the parameter name.

    1. I'm not sure about this one, but you might not be able to have primitive types as some of your arguments unless they are all of that primitive type. It's possible that C# would do autoboxing for you; I don't know either way.

    Variable length argument lists are intended to solve an entirely different problem then are optional arguments.

  • (cs) in reply to Martin
    Anonymous:
    //Enable or disable controls in the form
    private void EnableDisable(bool blnEnable) { ... }

    The question here is: WHAT is it enabling?
    Unless specified otherwise, one would assume the whole object/form. The real problem here is that the method ought to have been called simply Enable() without the extraneous Disable bit. If you want to enable/disable individual controls, you'd probably have to request them. That's the least surprising and most obvious behaviour.
  • (cs) in reply to A. Nony Mous
    Anonymous:
    BradC:
    Alex Papadimoulis:
    And while we're picking on the VS Tools for Office, following is the code required to call Excel's Dialog Show from C# ...

    if(xlApp.Dialogs[Excel.XlBuiltInDialog.xlDialogOpen].Show(sTextName,
      Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
      Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
      Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
      Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
      Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
      Type.Missing, Type.Missing, Type.Missing, Type.Missing) == true) { ... }

    Ah, score one for VB.Net, which supports optional arguments.

    Take that, C# !!!



    More like score -1 for Office .NET objects... One of the biggest PITA to work with.

    VB.NET isn't much better.
    oExcelDoc = oExcel.Workbooks.Open(ExcelDocName, , True, , , , True, , , False, False, False, False)

    You don't have to use positional arguments.  You can also do:

    <FONT face="Courier New">oExcelDoc = oExcel.Workbooks.Open(FileName:=ExcelDocName, ReadOnly:=True, SomeOtherParam:=True)</FONT>

    Don't try saying it's an awful syntax because C# uses the same syntax for assigning values to public fields on attributes.

    System.Windows.Forms.MessageBox.Show is a good example of why optional parameters are better than overloading.  There are 12 overloads and you still often have to fill in nulls in the best overload.  Also, you can't use overloading to distiguish between calls using different parameters of the same type.  This doesn't work:

    <FONT face="Courier New">public DialogResult Show(string Message)
    {
    ...
    }
    public DialogResult Show(string Title)
    {
    ...
    }</FONT>

    A similar thing happens in the other direction.  If you have a C# method with an unsigned long parameter, it can't be called from VB.Net.  Each language has its little things that it does better than other languages.

    But, can the C# guy please at least concede that VB.Net has optional arguments and C# does not and C# would be a better language if it did have them.  You don't have to use them all the time, but they do come in handy.

    BTW, the Office API was invented back when no language other than VBA could call it.  So, it developed a lot of optional parameters because VBA didn't support overloading.  That's why today it sucks to call it from C#.

  • (cs) in reply to Martin
    Anonymous:
    //Enable or disable controls in the form
    private void EnableDisable(bool blnEnable) { ... }

    The question here is: WHAT is it enabling?

    Normally you might see something like EnableWindow or EnableButton or some such.
    So, are you enabling a disable? Wouldn't that mean that passing in True
    really means you're disabling? If so what are you disabling? And, if you pass
    in False, does that mean you are disabling the disable and thus actually
    enabling? On top of that, precisly WHICH controls are you enabling or disabling,
    once you figure out which input yields the desired result.

    It all makes the head explode!



    it's the member function of a form object. true enables, and false disables. it operates on all of the control on the form...

    forgive me if you were being sarcastic.
  • mat (unregistered) in reply to Martin

    Yes it can - right click on the break point

  • Ann Coulter (unregistered) in reply to Bustaz Kool
    Anonymous:
    John Bigboote:
    juvenile:

    A better name might be:

    catch (ProblemUndoingShortSaleYesterday pussy)



    If I caught more of that type of exception in college, I might not be a programmer today. It's a pretty rare scenario for most coders.

    It's not rare if you develop the right kind of driver.  Just put your portal into protected mode and you'll be interfacing with the system internals in no time.  Remember, it's not the size of the download that's important here, it's how you handle the buffer overflow...



    WTF did that mean?
  • Benjamin Smith (unregistered) in reply to Bustaz Kool
    Anonymous:
    John Bigboote:
    juvenile:

    A better name might be:

    catch (ProblemUndoingShortSaleYesterday pussy)



    If I caught more of that type of exception in college, I might not be a programmer today. It's a pretty rare scenario for most coders.

    It's not rare if you develop the right kind of driver.  Just put your portal into protected mode and you'll be interfacing with the system internals in no time.  Remember, it's not the size of the download that's important here, it's how you handle the buffer overflow...



    Seriously, dude. You need to get laid.
  • missing (unregistered) in reply to SomeCoder
    Anonymous:
    GoatCheez:

    ..... assuming that string was defined as a type.... otherwise all fingers point to C# ;-)


    A bit of a nitpick, but string is defined as a type if you're using the STL.

    A bit more of a nitpick: string predates the STL, and in modern C++ it's std::string.  It's just string if you're "using std", but class declarations are usually in header files and "using" namespaces in header files is usually a bad idea.
  • Anton (unregistered) in reply to Martin
    Martin:

    Anonymous:
    the real WTF then is that they're not using a debugger with conditional f-breakpoints! come on, this technology has been in debuggers for at least the last ten years...

    Alas, VS2005 cannot support conditional breakpoints in C# however!

    Did you ever tried to right-click on the red dot of a breakpoint?

  • (cs) in reply to pete23

    I used the beep-debugging many times, as it's great technique for tracing. Conditional breakpoints serve different purpose - they simply break the execution, which often means: break in the middle of receiving mouse input, kick back focus to the debugger, and obscure the whole application window with the debugger, causing Invalidate - this may, or may not, be what you need when debugging GUI issues.

    You could use some tracking classes, debug.writeln and similar things, but again, you're losing correlation between the events and actions that caused them, unless you're carefully watching at the clock and ... no, it's just hard to debug any GUI-related problems this way...

  • (cs)
    Alex Papadimoulis:

    Jay's predecessor had a hard time understanding why users might want things like SUBTOTALS and TAX AMOUNT on their invoice: can't they just use a calculator?

    # add in a "BALANCE DUE" line for the cry-babies who can't figure it out



    To be fair, that comment doesn't actually say the number wasn't there in the first place. It may have been that it was merely not properly labelled...
  • Loren Pechtel (unregistered) in reply to juvenile
    juvenile:

    Several years ago, we worked on a system that wreaked of buzzword bingo. We had to add a new db table to hold transaction log records, locally called record-of-diary, but all the good acronyms (relevant to the system) were already used. My boss, in a fit of frustration, told the dba to just name the table 'asshole'. He did. Two days later, we started getting nasty e-mails from the operations group complaining about log entries that looked like this:

    inserting ROD into asshole ...

    *sigh*



    Long ago I was asked to create a pattern.  I didn't know what it was supposed to be for and for some reason I couldn't get a good answer as to what it was supposed to be.  Creating the graphics was no big deal but it needed a name.  In my attempts to get a name the guy referred to it indirectly as "shit".  (Something like "the shit you're working on"--it's more than a decade ago, I don't recall the details.)  Only maintainence would ever see the internal name I gave it--so the object I created was named "shit".

    No squawks once I explained where the name came from.
  • (cs) in reply to Loren Pechtel
    Anonymous:
    juvenile:

    Several years ago, we worked on a system that wreaked of buzzword bingo. We had to add a new db table to hold transaction log records, locally called record-of-diary, but all the good acronyms (relevant to the system) were already used. My boss, in a fit of frustration, told the dba to just name the table 'asshole'. He did. Two days later, we started getting nasty e-mails from the operations group complaining about log entries that looked like this:

    inserting ROD into asshole ...

    *sigh*



    Long ago I was asked to create a pattern.  I didn't know what it was supposed to be for and for some reason I couldn't get a good answer as to what it was supposed to be.  Creating the graphics was no big deal but it needed a name.  In my attempts to get a name the guy referred to it indirectly as "shit".  (Something like "the shit you're working on"--it's more than a decade ago, I don't recall the details.)  Only maintainence would ever see the internal name I gave it--so the object I created was named "shit".

    No squawks once I explained where the name came from.

    Something about this post and the "German variable name" discussion in another thread reminded me of a project years ago where we had database and server names based on Catch-22: development was on Yossarian, V&V was Nately, and so on (Nateley's Whore would not work because of the embedded chars). Anyone want to guess what we called the UAT database?

  • JC Denton (unregistered)
    if(xlApp.Dialogs[Excel.XlBuiltInDialog.xlDialogOpen].Show(sTextName,
    Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,

    Shouldn't that be:

    object oMissing = Type.Missing;

    if(xlApp.Dialogs[Excel.XlBuiltInDialog.xlDialogOpen].Show(ref sTextName,
    ref Type.Missing,ref Type.Missing,ref Type.Missing,ref Type.Missing,ref Type.Missing,

    etc? [The values are passed byreference]

    Yes , Office PIA's are a Royal pain

    Oh, and how about:

    string legs;
    legs.split(s);


  • capcha=quality (unregistered) in reply to Philbert Desanex

    The real WTF is that C# doesn't support optional arguments. Even C++ can do that.

  • (cs) in reply to missing
    Anonymous:
    Anonymous:
    GoatCheez:

    ..... assuming that string was defined as a type.... otherwise all fingers point to C# ;-)


    A bit of a nitpick, but string is defined as a type if you're using the STL.

    A bit more of a nitpick: string predates the STL, and in modern C++ it's std::string.  It's just string if you're "using std", but class declarations are usually in header files and "using" namespaces in header files is usually a bad idea.

    I'll nitpick you one better: It's either "using namespace std" or "using std::string", not "using std" (unless I have been misled all this time).

    ;)

  • (cs)
    Anonymous:
    See e.g. http://blogs.msdn.com/brada/archive/2003/11/23/50836.aspx


    I think this reasoning is BS. Perhaps I don't fully see the consequences here, but it seems to me that nothing they say there is a criticism of anything but the way they IMPLEMENTED default arguments in VB.

    I see no reason why you couldn't have the C# compiler translate this:

    int foo(int first, int second=default) { ... }

    into this:

    int foo(int first, int second) {...}
    int foo(int first) { return foo(first, default); }

    Automagically. As they don't seem to have a problem with the second form, voila, problem solved. You have a simpler syntax than writing the second thing by hand (and if you manage to define a function that takes thirty arguments like the show method in the original WTF,  you don't have to write thirty overloads) but with the same result.
  • Bigwig (unregistered) in reply to Reed

    Certainly not. As long as you don't access members of the class, you can call any method, since it's been allocated with the classes' skeleton on the heap. No member accessed, no segfault, with most compilers at least.

  • Bigwig (unregistered) in reply to Reed
    Anonymous:
    Alex Papadimoulis:

     * Note: This should probably be a static method. Since it isn't, 
    * you will need to reference it will a null object:
    * COrderSummary *obj = NULL;
    * obj = obj->XMLParse(someXMLString);
    * ***/


    What? This is garaunteed to segfault. Always.  Every time.

    (Maybe they meant this? COrderSummary obj; obj.XMLParse(...);)


    yeah, the above post was a reply to this quote.
  • Mr. Win (unregistered) in reply to EvanED
    EvanED:
    I think this reasoning is BS.
    Indeed. Even if we restrict the discussion to dodgy implementations of optional parameters, the fundamental argument against them is that if you change your public interface, the calling code will break. Duh? Don't change your public interface!

    In the particular example given, overloading is indeed better than badly implemented optional parameters. I can also point out examples where composition is better than inheritance. Should we throw out inheritance, too?

Leave a comment on “Another Friday Smorgasbord ”

Log In or post as a guest

Replying to comment #:

« Return to Article