• (cs) in reply to boog
    boog:
    jasmine2501:
    ...all of the fixes they ever do involve commenting out the original code and writing the new code there, which does nothing but hurt readability and has no value when you have a source control system. If someone wants to know what the function looked like in the past, they can look up the history, and there is no reason to leave the original code in the file.
    This was standard practice in my last job. I remember hearing the argument that having the old code commented out makes it quicker to see what was changed, because you don't have to dig through history to find an old version.

    Of course, I only heard this argument from people who never successfully used a source control system in their lives.

    It is occasionally useful to leave old versions around if you want to say "here's a version that you might have thought of but is wrong for a subtle reason, which is why the following is more complicated than you'd expect" or something like that, but I somehow think that's not what you're talking about. :-) And code that is left in for reasons like that should basically always have a comment explaining why the heck you did that.

  • Simon (unregistered) in reply to C-Octothorpe
    C-Octothorpe:
    2) MAX_NUMBER_ATTACHMENTS is probably a constant, and the number "1", is definitely constant. Testing one constant against another seems, well, kinda stupid...

    Probably a compile-time constant... change the constant and recompile, and you've got a debug build. Good for performance if the compiler can optimise out any unused code, but annoying in an IDE that's smart enough to spot dead code and warn you about it...

  • Flotsam (unregistered) in reply to Fonseca

    Umm. Wont it wait 100 * 100 counts of whatever the wait function takes. Assuming that's milliseconds, this ought to be "timeInCentiseconds"

  • Norman Diamond (unregistered) in reply to jasmine2501
    jasmine2501:
    Public Function IsObjNothing(ByRef poObject As Object) As Boolean
        '***** 04/21/2004 - corrected function IsObjNothing expression type
        'IsObjNothing = (TypeName(poObject) = Nothing)
        IsObjNothing = (TypeName(poObject).ToUpper = "NOTHING") End Function
    Not only is it completely useless, it's also poor performance, which is the number one complaint about the software,
    It's also broken. ToUpper might yield "NOTHİNG".
  • Mike (unregistered)
    The Article:
    Public Function IsObjNothing(ByRef poObject As Object) As Boolean
        '***** 04/21/2004 - corrected function IsObjNothing expression type
        'IsObjNothing = (TypeName(poObject) = Nothing)
        IsObjNothing = (TypeName(poObject).ToUpper = "NOTHING") End Function
    

    So...is the TDWTF here the syntax error near ToUpper, the apparent company coding standard requirement that detailed change history comments must be written for even the most minor changes, commenting out the old code instead of deleting it, having a separate function to check for Nothing, not using the invariant culture for the ToUpper call, or the fact that this is VB.NET?

    I think it's the last one.

  • SG_01 (unregistered) in reply to Marc
    Marc:
    Always the same fuss over "this" being null. Keep in mind that "this" is merely syntactic sugar for another parameter implicitly passed to a function.

    In C one might write

    void class_A__method(object* this,int a,int b,int c) { class_A__othermethod(this,a,b,c); class_A__thirdmethod(a,b,c); }

    whereas in C++ you might write

    class A { void method(a,b,c); void othermethod(a,b,c); static void thirdmethod(a,b,c); }

    void A::method(a,b,c) { this->othermethod(a,b,c); thirdmethod(a,b,c); }

    It's all the same. Just because "this" is passed implicitly (and sometimes unnecessarily!) in object oriented programming, that doesn't mean it's always defined!

    Normally in a class you'd define functions that don't require the object pointer as static methods. However, in some cases it's useful that a method can be called both with or without object pointer.

    A bit exotic, no doubt. But there are perfectly legitimate uses for "this" being null.

    Right, but if you're talking about virtual functions, (like this one), it's very unlikely, as the program will crash before it can execute the function... Unless you call it specifically.

    And really, doing ptr->SomeClass::Function(a,b,c) is usually asking for problems ^^

  • SG_01 (unregistered) in reply to SG_01

    Example:

    class A
    {
    public:
       int i;
       virtual void method(a,b,c);
    }
    
    class B
    {
    public:
       virtual void method(a,b,c);
    }
    
    void main()
    {
       A* a = null;
       a->method(a,b,c); // crash
       a->A::method(a,b,c); // would work if A::method didn't care about this
       a->B::method(a,b,c); // would work if B::method didn't care about this
    }
    
    void B::method(a,b,c)
    {
        this->A::method(a,b,c); // Most people omit "this->". 
        // This function would work if this == null, if not for above call...
    }
    
    void A::method(a,b,c)
    {
        this->i += a; // Crash if this == null
    }
    

    Also, doing above in C, while possible, would be a PITA ^^

  • Jasmine (unregistered) in reply to Mike
    Mike:
    The Article:
    Public Function IsObjNothing(ByRef poObject As Object) As Boolean
        '***** 04/21/2004 - corrected function IsObjNothing expression type
        'IsObjNothing = (TypeName(poObject) = Nothing)
        IsObjNothing = (TypeName(poObject).ToUpper = "NOTHING") End Function
    

    So...is the TDWTF here the syntax error near ToUpper, the apparent company coding standard requirement that detailed change history comments must be written for even the most minor changes, commenting out the old code instead of deleting it, having a separate function to check for Nothing, not using the invariant culture for the ToUpper call, or the fact that this is VB.NET?

    I think it's the last one.

    It's actually not VB itself, it's VB6 programmers still doing things the same way they did back then, when there is a better way. I mean really, assigning the value to the function name? Works, but it's confusing. I'm pretty sure there is "Option strict off" at the top of the file I found this in. Might also seriously contain a "on error resume next" also, and I'm not shitting you. I get hundreds of warnings when compiling. I've been told to ignore them.

    The company is changing to C# this year, so the code quality should get even worse, given that this "code problem" is actually a management problem and switching the language doesn't accomplish the same thing as firing the managers.

  • (cs) in reply to C-Octothorpe
    C-Octothorpe:
    And fucking of course the red-headed step child

    Speaking as someone's red-headed step child: get your own.

  • oppeto (unregistered) in reply to Machtyn
    Machtyn:
    Mcoder:
    Wonk:
    1) Write "Hello World" Program 2) Copyright program 3) ???? 4) Profit!!

    Yep. That's Oracle.

    1. Write "Hello World" program
    2. Copyright program
    3. Have some random site (TDWTF) distribute your program verbatim
    4. Sue the hell out of random site. That'll teach them to obey copyrights
    5. Profit!!! (For the lawyers)

    Except they don't even follow their own copyright! Take a look at the second provision:

    Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
    I don't see anywhere in that Hello, World! program that would print out the copyright notice and list of conditions.
    It's not in binary form. That program was only ever intended in code form. It is not meant to be compiled

  • (cs) in reply to jasmine2501
    jasmine2501:
    costs over $1 million at the install, and over $100,000 per year.

    You may just have identified it. At least, these figures and the general WTF-ery of the code certainly brought a particular product to my mind.

  • Mike (unregistered) in reply to Jasmine
    Me:
    The real TDWTF must be...blah...blah...VB.NET
    A failed attempt at sarcasm.
    Jasmine:
    It's actually not VB itself, it's VB6 programmers still doing things the same way they did back then, when there is a better way.
    If that's how they would write this code in VB6, they get double-bonus points for doing it wrong in both languages.

    On a more serious note though, I feel for you. I work with VB6 and VB.NET code in my day job, and I dread having to fix anything our (luckily former) senior developer worked on. I once tried building one of his solution files and actually got a warning from Visual Studio telling me that couldn't display any more warnings.

    We should probably all be very afraid that he used to work on missile defense systems before joining our company...

  • refoveo (unregistered) in reply to Guess Who?
    Guess Who?:
    C-Octothorpe:
    Hortical:
    Counter-intuitive to me, anyway.
    Fair enough...
    Hortical:
    Arguments as return values? Algumemts as revurn talues? Algoomempts az rekuvn lal00z? UUUllllkkkooomemeptszzz.....
    Um, you lost me at "UUUllllkkkooomemeptszzz"...
    Hortical:
    String firstName;
    String lastName;
    boolean cool;
    [firstName, lastName, cool] = DoStuff();
    

    public [String, String, boolean] doStuff() { return ["C", "Octothorpe", Boolean.DEFINITELY_NOT]; }

    Damnit, just don't tell anyone, alright!

    Another idea comes to mind:

    public void transmit(String fn, String ln, boolean c){
        // send over network
    }
    public [String, String, boolean] doStuff(){
        return ["C", "Octothorpe", Boolean.SURE_WHY_NOT];
    }
    
    transmit(doStuff());
    

    instead of this

    string firstName;
    string lastName;
    bool cool;
    DoStuff(out firstName, out lastName, out cool);
    Transmit(firstName, lastName, cool);
    

    Anonymous Tuple Substitution.

    It's the wave of the failu^H^H^H^H^HFuture!

    I think I agrees a little, although I can see some potential abuse.

    I remember working on some cryptographic components which were tended to get very layered (due to misunderstandings and bad design, mainly - instead of replacing a translation layer {for example} they simply added another one). Nonetheless, the RSA component passed many (about 13, I think - some were shortcut calculations, some were redundant, maybe I exagerate) parameters down the chain.

    A structure like you suggest is far more appropriate - but in that case, why not use a struct? Your suggestion is perhaps marginally simpler in certain cases, but I'm not sure I really see that it's all that different (you simply get rid of the populating structure bit...)

  • Decius (unregistered)

    Clearly we need a function that removes the Not-non-uninvisible property as well.

  • Nagesh (unregistered) in reply to boog
    boog:
    D-Coder:
    What you're missing is that people who use the "beat the code into submission" methodology do not use source control.

    I see it every day here. But with extra comments like "Rajneesh -- 4/9/2003". Thank <$deity> "Rajneesh" is 10,000 miles away.

    I'm going to go out on a limb and guess that your code is touching Oracle somehow. Am I wrong?

    Because I seem to remember having to work around Rajneesh's crappy code myself.

    Rajneesh is one of our best developers. When I am having doubts about how to do something, he is my first port in a storm.

  • Julia Gillard (unregistered) in reply to oheso
    oheso:
    C-Octothorpe:
    And fucking of course the red-headed step child

    Speaking as someone's red-headed step child: get your own.

    WooHoo...people are talking about me!!

  • (cs) in reply to Mike
    Mike:
    Me:
    The real TDWTF must be...blah...blah...VB.NET
    A failed attempt at sarcasm.
    Jasmine:
    It's actually not VB itself, it's VB6 programmers still doing things the same way they did back then, when there is a better way.
    If that's how they would write this code in VB6, they get double-bonus points for doing it wrong in both languages.

    On a more serious note though, I feel for you. I work with VB6 and VB.NET code in my day job, and I dread having to fix anything our (luckily former) senior developer worked on. I once tried building one of his solution files and actually got a warning from Visual Studio telling me that couldn't display any more warnings.

    We should probably all be very afraid that he used to work on missile defense systems before joining our company...

    He worked as a blast shield, didn't he? Be honest!

  • (cs) in reply to Loren Pechtel
    Loren Pechtel:
    josefx:
    The MutableBoolean should be obvious for anyone familiar with the java wrapper classes. java.lang.Boolean is not Mutable so MutableBoolean is a good name for boolean wrapper with a public non final value field

    Even though I've never used Java I immediately understood what was going on. It's not a WTF unless it's duplicating library functionality.

    hoodaticus:
    ac:
    Isn't the MutableBoolean just a way to make the boolean (value) type into a reference type ("box" it, in .NET terms)? Because values types are passed by uh... value, you can't change the original value, so it appears "constant".

    Not that this is already covered by the java.lang.Boolean class or anything...

    This does nothing that a simple local variable wouldn't do.

    This allows pass-by-reference instead of pass-by-value.

    hoodaticus:
    I still don't get the point. If you have multiple classes sharing the same boolean, surely that boolean is significant enough that it has a property name in a class that is much more meaningful than MutableBoolean.

    Sharing it with a delegate, perhaps?

    How about holding a reference to this mystical object that holds this mighty global boolean value within the objects that depend upon it? I just don't see the point, or why anyone outside academia would arrive at MutableBoolean as a good idea.

    Let's say I have a Controller object that manages state, including boolean state, for a graph of objects. Why would I not give objects that depend upon that boolean state a reference to the Controller object instead of farming out to yet another object on the heap that adds nothing of value whatsoever?

  • (cs) in reply to SG_01
    SG_01:
    Right, but if you're talking about virtual functions, (like this one), it's very unlikely, as the program will crash before it can execute the function... Unless you call it specifically.

    And really, doing ptr->SomeClass::Function(a,b,c) is usually asking for problems ^^

    Trusting that you can make any method call on a null object, even if it's non-virtual and won't access fields, is asking for problems.

    Compilers are getting better and better at exploiting undefined behavior to improve the performance of compliant code; IMO it's a pretty small step from some of the things they do now to "changing" the semantics of code that relies on being able to call methods on null.

    Addendum (2011-07-21 01:10): And just to give you an idea of the sort of optimization that could matter, consider the following code:

    int foo(SomeStruct * p)
    {
        p->someFunction();   // 3
        if (p) {             // 4
            return 1;
        }
        else {
            return 2;
        }
    }

    The standard says that the function call on line 3 counts as a dereference, which means that the compiler can know that p can't legally be null. (More specifically, it can know that it can do anything it wants in the case that it is null.)

    The fact that p "can't be" null means that the conditional on line 4 isn't needed, because it will always take the true branch. Thus the compiler can discard the else branch.

    It is entirely legal -- and I would argue completely moral -- for the compiler to emit the following pseudo-assembly for that function:

    foo:  call SomeStruct::someFunction  // p already in arg1
          move %ra, 1  // store 1 as the return value
          ret

    That means that foo would always return 1, while if it were to just blithely go along with a naive transformation, you'd expect it to return 2 if p were NULL.

    Now, no compilers that I tried (MSVC 2010, GCC 4.6.0, Intel CC 11.0, and Clang++ 2.9) actually perform this optimization, but they could. And not only could they, it'd probably be almost easy to add to some of them.

    To argue this, let's look at a simplified version of that function:

    int foo(int * p)
    {
        int y = *p;     // 3
        if (p) {        // 4
            return y;
        }
        else {
            return 2;
        }
    }

    As before, the dereference of p on line 3 allows the compiler to optimize away the conditional on line 4. (Note the change of return value from 1 to y -- this avoids dead code elimination from removing line 3.)

    Now, do compilers optimize away the conditional? Yes they do, or at least GCC does.

    Here is the actual output from g++ -O2 for this version (I removed a label and demangled the name of foo):

    foo:
            movl    (%rdi), %eax
            ret

    No conditional... no branch... no predicated instruction.

    Now, in this case the actual semantics don't change -- calls where p is non-null will return *p and calls where p is null will still segfault -- but it does show that the fundamental optimization of using dereferences to infer that certain values cannot be null is already in place.

    The only thing that is preventing them from using that mechanism to optimize my earlier example is likely either that they just haven't thought about it or that they have and decided that it wasn't worth breaking existing code that ill-advisedly relies on a particular implementation of undefined behavior.

    (And actually, I lied before when I said the optimization in the second version of foo don't change the semantics: they do change the semantics if you're on a system that lets you map page 0, and you do so. Without the optimization I describe, foo(NULL) will return 2; with the optimization, it will return the value at address 0.)

    Long story short: don't rely on undefined behavior unless you have a damn good reason and you do some audits (and keep doing audits as you change both the code and compilers/compiler versions) to make sure that the compiler isn't doing something you don't expect. Undefined behavior is a part of C/C++ programming, and you will write code that falls into that category. But that code is not something you should be proud of. It's not something you should try to justify. It's something you should fix.

    Addendum (2011-07-21 01:20): I forgot one critical aspect: the definition of someFunction may need to be visible, and the compiler able to establish that its invocation does not change the value of p. I'm not sure about this though... what I said may be correct as I wrote it. I don't know what the rules are regarding where the compiler is allowed to assume values don't change and stuff like that (the whole volatile thing.)

    Addendum (2011-07-21 01:40): One last comment then I'm going to bed. In the previous addendum I had a bit of pointer-pointee confusion -- I now think that what I said originally is indeed, correct.

    The only function that can (legally) obtain the address of p is foo itself. It never does, which means that the compiler is allowed to assume that p is not aliased to anything. (Assuming locals aren't aliased "behind the compiler's back" is common.) Thus the call to someFunction can't change the value of p, which means that my proposed optimization goes through as described.

    The compiler is allowed to make that optimization regardless of whether the definition of someFunction is available. (Practically speaking, making it available and thus eligible for inlining would be likely to affect whether the optimization was performed, in much the same way that I needed to return y in the second version of foo to prevent the dead-code-elimination optimization step from removing the dereference before the redundant-null-check optimization phase got a chance to run.)

  • JD (unregistered) in reply to damnum
    damnum:
    C-Octothorpe:
    Syam:
    Actually, I didn't quite understand why this is so stupid. As far as I can see, a variable named MAX_NUMBER_ATTACHMENTS is used to determine if some sort of logging is enabled. Why is this so terrible? Can anybody enlighten me?
    THe WTF is two-fold: 1) The name of MAX_NUMBER_ATTACHMENTS *seems* to have absolutely nothing to do with logging 2) MAX_NUMBER_ATTACHMENTS is probably a constant, and the number "1", is definitely constant. Testing one constant against another seems, well, kinda stupid...

    So you don't like it simply because of the names?

    YES! Which is a perfectly good reason for not liking something. Programming is about communication and this is BAD communication. MAX_NUMBER_ATTACHMENTS in no way communicates the fact that it enables or disables logging.

    A future programmer gets sent a request to increase the maximum number of attachments, then gets sent a bug report when exceptions are thrown because the logging never really worked but it didn't matter because it was off. Then everyone sits back thinking, bah, silly programmer, can't even increase the maximum number of attachments without causing exceptions! Then multiply this by an entire codebase.

    Naming is one of the most important skills for a programmer.

  • David (unregistered) in reply to Flotsam

    If you call Wait(x) with 100 <= x < 200 it will call Thread.Sleep(100) once. So the submitter is correct that the unit is milliseconds.

    Perhaps the variable should be called timeInMillisecondsRoundedToTheNearestSecond.

  • I <3 scala (unregistered) in reply to Guess Who?
    Guess Who?:
    C-Octothorpe:
    Hortical:
    Counter-intuitive to me, anyway.
    Fair enough...
    Hortical:
    Arguments as return values? Algumemts as revurn talues? Algoomempts az rekuvn lal00z? UUUllllkkkooomemeptszzz.....
    Um, you lost me at "UUUllllkkkooomemeptszzz"...
    Hortical:
    String firstName;
    String lastName;
    boolean cool;
    [firstName, lastName, cool] = DoStuff();
    

    public [String, String, boolean] doStuff() { return ["C", "Octothorpe", Boolean.DEFINITELY_NOT]; }

    Damnit, just don't tell anyone, alright!

    Another idea comes to mind:

    public void transmit(String fn, String ln, boolean c){
        // send over network
    }
    public [String, String, boolean] doStuff(){
        return ["C", "Octothorpe", Boolean.SURE_WHY_NOT];
    }
    
    transmit(doStuff());
    

    instead of this

    string firstName;
    string lastName;
    bool cool;
    DoStuff(out firstName, out lastName, out cool);
    Transmit(firstName, lastName, cool);
    

    Anonymous Tuple Substitution.

    It's the wave of the failu^H^H^H^H^HFuture!

    While we are at it, why not anonymous structured type creation:

    public [String firstName,String lastName,boolean cool] doStuff(){
        return ["C", "Octothorpe", Boolean.SURE_WHY_NOT];
    }
    
    Tuple[String,String,boolean] x = doStuff();
    Transmit(x.firstName, x.lastName, x.cool);
    

    I guess this idea needs more work, it's starting to feel like javascript.

    By the way, a syntax like what Hortical suggested already exists in scala, if I'm allowed to make propaganda.

  • (cs) in reply to David
    David:
    Perhaps the variable should be called timeInMillisecondsRoundedToTheNearestSecond.
    timeInMilliseconds /* implementation providing resolution of one decisecond */ (rollseyes)
  • (cs)

    I love the mutable boolean that is immutable.

  • Jon (unregistered)

    A MutableBoolean is actually pretty useful if you need a method to be able to change a flag you pass in its argument list, as the standard Java Boolean is immutable. So the only real WTF is rolling your own, rather than using the MutableBoolean provided by commons-lang. Oh, and value should be declared volatile, to ensure visibility of changes made in other threads. And the initialisation to true is pointless, as the only constructor provided sets it. But aside from that...

  • Arthur de Jong (unregistered) in reply to Rich

    On Solaris 8 (old box hanging around) /bin/true is (this is the whole file):

    #!/usr/bin/sh # Copyright (c) 1984, 1986, 1987, 1988, 1989 AT&T # All Rights Reserved

    THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T

    The copyright notice above does not evidence any

    actual or intended publication of such source code.

    #ident "@(#)true.sh 1.6 93/01/11 SMI" /* SVr4.0 1.4 */

    I think on older release it was just a 0-byte file but at some point someone thought it would be a good idea to apply for copyright for those 0 bytes.

  • (cs) in reply to Jon
    Jon:
    A MutableBoolean is actually pretty useful if you need a method to be able to change a flag you pass in its argument list, as the standard Java Boolean is immutable. So the only real WTF is rolling your own, rather than using the MutableBoolean provided by commons-lang. Oh, and value should be declared volatile, to ensure visibility of changes made in other threads. And the initialisation to true is pointless, as the only constructor provided sets it. But aside from that...
    I still don't see why that role can't be filled by the object that created the MutableBoolean in the first place.
  • Guess Who? (unregistered) in reply to hoodaticus
    hoodaticus:
    I still don't see why that hole can't be filled by the object that created the SilenceableBoy in the first place.

    You sick fuck! He's your son!

  • Hortical (unregistered) in reply to Jon
    Jon:
    A MutableBoolean is actually pretty useful if you need a method to be able to change a flag you pass in its argument list, as the standard Java Boolean is immutable. So the only real WTF is rolling your own, rather than using the MutableBoolean provided by commons-lang. Oh, and value should be declared volatile, to ensure visibility of changes made in other threads. And the initialisation to true is pointless, as the only constructor provided sets it. But aside from that...
    I'd say the REAL real WTF is importing an entire 3rd party library for what could be implemented with 8 lines of code.

    It takes 10 seconds. Just write it.

    DO IT LIVE! FUCK IT! I'LL WRITE IT AND WE'LL DO IT LIVE!

  • Jon (unregistered) in reply to Hortical
    Hortical:
    Jon:
    A MutableBoolean is actually pretty useful if you need a method to be able to change a flag you pass in its argument list, as the standard Java Boolean is immutable. So the only real WTF is rolling your own, rather than using the MutableBoolean provided by commons-lang. Oh, and value should be declared volatile, to ensure visibility of changes made in other threads. And the initialisation to true is pointless, as the only constructor provided sets it. But aside from that...
    I'd say the REAL real WTF is importing an entire 3rd party library for what could be implemented with 8 lines of code.

    It takes 10 seconds. Just write it.

    DO IT LIVE! FUCK IT! I'LL WRITE IT AND WE'LL DO IT LIVE!

    Because you'll write it WRONG. Like the class above, which forgets about thread safety (or providing a equals or hashcode). And pretty much ANY non-trivial project is already using commons-lang already... so it's more a case of needlessly duplicating a class that is already in your project, and doing a bad job of it.

  • Hortical (unregistered) in reply to Jon
    Jon:
    Because you'll write exactly what you need and nothing more. Like the class above, which probably didn't need thread safety or equals or hashcode. And pretty much ANY non-trivial project is already using commons-lang already (pulled out of my ass)... so it's more a case of including an overblown library to simplify your project, and doing a bad job of it.

    Exactly. The code in the article was written for a very specific purpose and it fulfills that purpose. commons-lang wasn't necessary in any event because he could have used AtomicBoolean for thread safety, equals and hashcode (which is what I would have done).

    So it wasn't the best way to do it. But it's not "WRONG".

  • JayC (unregistered) in reply to hoodaticus
    hoodaticus:
    Jon:
    A MutableBoolean is actually pretty useful if you need a method to be able to change a flag you pass in its argument list, as the standard Java Boolean is immutable. So the only real WTF is rolling your own, rather than using the MutableBoolean provided by commons-lang. Oh, and value should be declared volatile, to ensure visibility of changes made in other threads. And the initialisation to true is pointless, as the only constructor provided sets it. But aside from that...
    I still don't see why that role can't be filled by the object that created the MutableBoolean in the first place.

    That sounds like a good way to spread around unnecessary dependencies....

  • (cs) in reply to I <3 scala
    I <3 scala:
    While we are at it, why not anonymous structured type creation:
    public [String firstName,String lastName,boolean cool] doStuff(){
        return ["C", "Octothorpe", Boolean.SURE_WHY_NOT];
    }
    
    Tuple[String,String,boolean] x = doStuff();
    Transmit(x.firstName, x.lastName, x.cool);
    

    I guess this idea needs more work, it's starting to feel like javascript.

    By the way, a syntax like what Hortical suggested already exists in scala, if I'm allowed to make propaganda.

    I just thought another approach would be to use lambdas and simply keep all the parameters in scope rather than passing them around like currency. Too lazy to write an example, though I might in a bit...

    I'd like to quickly point out that I realize that this goes against code reuse, etc., etc., but I'm just trying to solve the problem of parameters, not everything else.

    Addendum (2011-07-21 10:58): Ok, here is my (bad) example:

            public void Main()
            {
                string firstName = null;
                string lastName = null;
                bool isCool = true; // maybe?
    
                Action doStuff = () => 
                {
                    firstName = "C";
                    lastName = "Octo";
                    isCool = false; // I knew it...
                };
    
                doStuff();
    
                Console.WriteLine(firstName);
                Console.WriteLine(lastName);
                Console.WriteLine(isCool);
            }
  • QJo (unregistered) in reply to Jon
    Jon:
    Hortical:
    Jon:
    A MutableBoolean is actually pretty useful if you need a method to be able to change a flag you pass in its argument list, as the standard Java Boolean is immutable. So the only real WTF is rolling your own, rather than using the MutableBoolean provided by commons-lang. Oh, and value should be declared volatile, to ensure visibility of changes made in other threads. And the initialisation to true is pointless, as the only constructor provided sets it. But aside from that...
    I'd say the REAL real WTF is importing an entire 3rd party library for what could be implemented with 8 lines of code.

    It takes 10 seconds. Just write it.

    DO IT LIVE! FUCK IT! I'LL WRITE IT AND WE'LL DO IT LIVE!

    Because you'll write it WRONG. Like the class above, which forgets about thread safety (or providing a equals or hashcode). And pretty much ANY non-trivial project is already using commons-lang already... so it's more a case of needlessly duplicating a class that is already in your project, and doing a bad job of it.

    The only reason to write a MutableBoolean is in universes in which commons-lang hasn't been written yet. I'd be prepared to guess that maybe the MutableBoolean in the example dates from before commons-lang was introduced to the development community.

    Quite a few of the WTFs I've seen are only sillies because they involve reinvention of code which at its time of writing didn't exist.

    Now get off my lawn.

  • QJo (unregistered) in reply to Arthur de Jong
    Arthur de Jong:
    On Solaris 8 (old box hanging around) /bin/true is (this is the whole file):
    #!/usr/bin/sh # Copyright (c) 1984, 1986, 1987, 1988, 1989 AT&T # All Rights Reserved

    THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T

    The copyright notice above does not evidence any

    actual or intended publication of such source code.

    #ident "@(#)true.sh 1.6 93/01/11 SMI" /* SVr4.0 1.4 */

    I think on older release it was just a 0-byte file but at some point someone thought it would be a good idea to apply for copyright for those 0 bytes.

    Possible there's a company policy to the effect that "All source code must have a copyright header in this format" blah blah. No big deal. Easier (and quicker, and more efficient too, I would surmise) to add a header to all the files matching a particular format than to have to do it by hand and thereby have to make a decision as to what should sensibly have a header and what should not.

    So I'm afraid no WTF there either.

  • towfx (unregistered)

    the reason to have these 2 functions below

    public bool IsOk { get { return value >= 0; } }

    public bool IsNotOk { get { return !IsOk; } }

    are to use it like this...

    if(PART_1 == IsOK AND PART_2 == IsNotOk)

    very super elegant readable!

  • (cs) in reply to boog
    boog:
    D-Coder:
    What you're missing is that people who use the "beat the code into submission" methodology do not use source control.

    I see it every day here. But with extra comments like "Rajneesh -- 4/9/2003". Thank <$deity> "Rajneesh" is 10,000 miles away.

    I'm going to go out on a limb and guess that your code is touching Oracle somehow. Am I wrong?

    Because I seem to remember having to work around Rajneesh's crappy code myself.

    Sorry, wrong. I anonymized the name.

    I'd name the actual language/DB involved but then there'd be 30 postings "<X> is TRWFT!" (sic) And it's not, it's the programmers.

  • (cs) in reply to Erik
    Erik:
    /** *Makes the following dialog not non-uninvisible */

    Having spent several years reviewing the code and associated comments (when you actually got them) written by offshore developers, I feel somewhat qualified to attempt to parse the meaning of this comment. I had to decipher plenty that looked that bad or worse.

    Let's break it down and find a likely meaning for what each successive negative might actually be doing:

    • dialog is visible Dialog is shown to the user.

    • dialog is invisible Dialog is hidden from the user.

    • dialog is uninvisible My guess is that this abortion of language indicates an action, switching the dialog from invisible to visible.

    • dialog is non-uninvisible Based on the previous assumption, this would mean that a flag is set preventing the dialog from being switched from invisible to visible.

    • dialog is made not non-uninvisible Therefore, the method is changing the value of the flag, allowing the dialog to be switched from invisible to visible (though not actually making that switch itself).

    More likely the developer is just being a smart ass because the company is not professional enough to perform code reviews.

  • Jay (unregistered) in reply to Silfax
    Silfax:
    Bah - you are thinking too much into this

    MutableBoolean must have been created by someone that gets paid by coc (characters of code)

    Instead of

    boolean foo=true; boolean bar=false;

    they code MutableBoolean foo = new MutableBoolean(true); MutableBoolean bar = new MutableBoolean(false);

    By doing this they get paid almost 3 times as much...

    I used to work for the government, where the success of a project was measured by how much money you spent. Did you spend your entire budget? Then the project is a success. Did you fail to spend your entire budget? Uh oh, project is a failure.

  • Jay (unregistered) in reply to damnum
    damnum:
    C-Octothorpe:
    Syam:
    Actually, I didn't quite understand why this is so stupid. As far as I can see, a variable named MAX_NUMBER_ATTACHMENTS is used to determine if some sort of logging is enabled. Why is this so terrible? Can anybody enlighten me?
    THe WTF is two-fold: 1) The name of MAX_NUMBER_ATTACHMENTS *seems* to have absolutely nothing to do with logging 2) MAX_NUMBER_ATTACHMENTS is probably a constant, and the number "1", is definitely constant. Testing one constant against another seems, well, kinda stupid...

    So you don't like it simply because of the names?

    Ummm ... yes.

    If someone creates a field that holds the employee's social security number, and they call it "zipcode", then, yes, I will dislike that program "just" because of the names.

    Real example: I once created a function that determined whether or not a stock number that was entered by the user was valid. I called it "validateStockNumber" and it returned a boolean. Then someone else came along and added a bunch of code to also update a shipping manifest. Then someone else came along and made another update to remove the stock number validation. So then "validateStockNumber" in fact didn't validate stock numbers at all but instead updated shipping manifests.

    Later another programmer came along who had to call this function through a web service. So he called his proxy function "validateStockNumberButReallyUpdateManifest".

    Yes, I hated those code changes "just" because of the name.

  • Jay (unregistered) in reply to hoodaticus
    hoodaticus:
    Let's say I have a Controller object that manages state, including boolean state, for a graph of objects. Why would I not give objects that depend upon that boolean state a reference to the Controller object instead of farming out to yet another object on the heap that adds nothing of value whatsoever?

    Absolutely true ... IF you have other variables that would go in the object. But what if, for the problem at hand, the only variable you have is a single boolean. You COULD create a custom object just to hold that one boolean. But why? Why not just create a MutableBoolean that you can use in other places where you also have a single boolean?

    Yes, I don't use a MutableBoolean or a MutableInteger or a Mutable-anything-else when what I really want is an object with several variables. That would just be an unnecessary extra step. But it's not at all uncommon to have just one field that I need to manage for the current problem.

  • Jay (unregistered)

    I agree with earlier posters that it would be nice if a function call could return multiple values. If you could say, for example:

    firstname, lastname=parsename(fullname);
    

    But the "pure Java" approach isn't really that much worse. You would typically write:

    NameParser np=new NameParser(fullname);
    String firstname=np.getFirstName();
    String lastname=np.getLastName();
    

    Or if you're not a bean fanatic, just let NameParser have public fields for firstname and lastname that you can use once you've created the object.

    This has the side advantage that you can easily ignore "return values" that you don't care about for this particular invocation. It has the disadvantage that if the references are not written immediately following the call, it is not obvious to the reader just what was calculated where.

  • (cs) in reply to Jay
    Jay:
    hoodaticus:
    Let's say I have a Controller object that manages state, including boolean state, for a graph of objects. Why would I not give objects that depend upon that boolean state a reference to the Controller object instead of farming out to yet another object on the heap that adds nothing of value whatsoever?

    Absolutely true ... IF you have other variables that would go in the object. But what if, for the problem at hand, the only variable you have is a single boolean. You COULD create a custom object just to hold that one boolean. But why? Why not just create a MutableBoolean that you can use in other places where you also have a single boolean?

    Yes, I don't use a MutableBoolean or a MutableInteger or a Mutable-anything-else when what I really want is an object with several variables. That would just be an unnecessary extra step. But it's not at all uncommon to have just one field that I need to manage for the current problem.

    SOMETHING created that MutableBoolean. Why not just store the boolean inside it and pass it as a reference to the subscribers?

  • (cs) in reply to JayC
    JayC:
    hoodaticus:
    Jon:
    A MutableBoolean is actually pretty useful if you need a method to be able to change a flag you pass in its argument list, as the standard Java Boolean is immutable. So the only real WTF is rolling your own, rather than using the MutableBoolean provided by commons-lang. Oh, and value should be declared volatile, to ensure visibility of changes made in other threads. And the initialisation to true is pointless, as the only constructor provided sets it. But aside from that...
    I still don't see why that role can't be filled by the object that created the MutableBoolean in the first place.

    That sounds like a good way to spread around unnecessary dependencies....

    There already is a dependency there. Hiding it in a MutableBoolean just disguises it and makes it more difficult to track down.

  • Wouter Verhelst (unregistered)

    /*

    • Copyright (c) 1995, 2008, Oracle and/or its affiliates. All rights reserved.
    • Redistribution and use in source and binary forms, with or without
    • modification, are permitted provided that the following conditions
    • are met:
      • Redistributions of source code must retain the above copyright
    • notice, this list of conditions and the following disclaimer.
      

    [...]

    Actually, that's not the worst example of license WTF from the late Sun.

    They used to have a /bin/true which was just an empty file. That is a perfectly valid implementation of /bin/true (remember, "true" in the context of a shell script needs to return 0, which is a WTF in its own right, but that's a different matter entirely). Then some lawyer stumbled upon the fact that Sun is shipping a file without a license notice!!1!. So a license was added. They ended up with a file saying

    #!/bin/sh

    (i.e., "this is a shell script")

    Then a license notice, and then... nothing.

    Eventually it got kicked out again, because users were complaining that sun was asserting copyright on empty files. But still.

  • Val (unregistered)

    /** *Stops the the following comment from not be made not non-uninvisible */

  • (cs) in reply to hoodaticus
    hoodaticus:
    Jay:
    hoodaticus:
    Let's say I have a Controller object that manages state, including boolean state, for a graph of objects. Why would I not give objects that depend upon that boolean state a reference to the Controller object instead of farming out to yet another object on the heap that adds nothing of value whatsoever?

    Absolutely true ... IF you have other variables that would go in the object. But what if, for the problem at hand, the only variable you have is a single boolean. You COULD create a custom object just to hold that one boolean. But why? Why not just create a MutableBoolean that you can use in other places where you also have a single boolean?

    Yes, I don't use a MutableBoolean or a MutableInteger or a Mutable-anything-else when what I really want is an object with several variables. That would just be an unnecessary extra step. But it's not at all uncommon to have just one field that I need to manage for the current problem.

    SOMETHING created that MutableBoolean. Why not just store the boolean inside it and pass it as a reference to the subscribers?
    Why don't you store the return value in a field instead of returning it?

    Because it often (even usually) doesn't make sense. That return value doesn't have meaning outside of the context of the call, so it needn't be -- and in fact shouldn't be -- made to persist.

    For instance, take a look at BigInteger; like the boxed types, it is immutable. BigInteger has two functions that do division: BigInteger divide(BigInteger other); BigInteger[] divideAndRemainder(BigInteger other); The second version returns an array where [0] is the quotient and [1] is the remainder.

    I'd argue that the following would have been a not-entirely-unreasonable alternative for this API: BigInteger divide(BigInteger other, MutableBigInteger outRemainder) And even if that's not what you want to present to the client, I think it's reasonable to have as a private function behind the scenes.

    Now, your proposal: don't use a MutableBigInteger, but put a BigInteger field in some other object and have divide set it.

    What object should get it? The one you're calling divide on? So it's going to have a remainderFromTheLastTimeYouCalledDivide field in it? Oh, and now your immutable object isn't, because it has to change that field.

    The one that has the call to divide is in? So there should be an CanHoldTheRemandierOfDivision interface with a setTheRemainderOfDivision() function, and divide should take a CanHoldTheRemaniderOfDivision object?

    There's no good place for that field.

  • Joe (unregistered) in reply to QJo
    QJo:
    Arthur de Jong:
    On Solaris 8 (old box hanging around) /bin/true is (this is the whole file):
    #!/usr/bin/sh

    #ident "@(#)true.sh 1.6 93/01/11 SMI" /* SVr4.0 1.4 */

    So I'm afraid no WTF there either.

    TRWTF is that it took them 7 revisions to get to it.

    I'd love to see the "blame" output for it. Can you imagine what bugfixes have gotten us to this point?

    --Joe

  • damnum (unregistered) in reply to Jay
    Jay:
    damnum:
    C-Octothorpe:
    Syam:
    Actually, I didn't quite understand why this is so stupid. As far as I can see, a variable named MAX_NUMBER_ATTACHMENTS is used to determine if some sort of logging is enabled. Why is this so terrible? Can anybody enlighten me?
    THe WTF is two-fold: 1) The name of MAX_NUMBER_ATTACHMENTS *seems* to have absolutely nothing to do with logging 2) MAX_NUMBER_ATTACHMENTS is probably a constant, and the number "1", is definitely constant. Testing one constant against another seems, well, kinda stupid...

    So you don't like it simply because of the names?

    Ummm ... yes.

    If someone creates a field that holds the employee's social security number, and they call it "zipcode", then, yes, I will dislike that program "just" because of the names.

    Real example: I once created a function that determined whether or not a stock number that was entered by the user was valid. I called it "validateStockNumber" and it returned a boolean. Then someone else came along and added a bunch of code to also update a shipping manifest. Then someone else came along and made another update to remove the stock number validation. So then "validateStockNumber" in fact didn't validate stock numbers at all but instead updated shipping manifests.

    Later another programmer came along who had to call this function through a web service. So he called his proxy function "validateStockNumberButReallyUpdateManifest".

    Yes, I hated those code changes "just" because of the name.

    Without knowing the rest of the code you can't say whether the names are suitable or not.

  • The Cat (unregistered)

    MutableBoolean: The unspeakable love-child of Erwin Schrödinger and George Boole. You never really know if it's true or false until you call the accessor method.

Leave a comment on “Not Non-uninvisible, addfunk(), and More”

Log In or post as a guest

Replying to comment #:

« Return to Article