• (cs)

    If it was Javascript I would write it:

    googleId = googleId || null;
    It ensures googleId is null if it was undefined, null or '' previously. Of course if the intended use for the null value was something like this later:
    if (googleId != null) { ... }
    Then the first line is not needed as you can just simply write:
    if (googleId) { ... }
  • (cs)
    googleId = googleId == null ? null : googleId; // ensure really null
    You have to be really certain that googleId is really null, otherwise it might override googleSuperego.

    Monsters from the googleId might then destroy the 'Don't be evil' mantra.

  • Laser-Opto the Supervillain (unregistered) 
    goggleEyed = goggleEyed == null ? null : goggleEyed; // ensure really dull

    FTFY

  • TbK (unregistered)

    I am new to tdwtf, but I like it.

    Just wanted to mention that most of this horrible code in this issue is optimized by the compiler anyway, isn't it?

  • Pot-ah-to Pot-ay-to (unregistered) in reply to TbK
    TbK:
    I am new to tdwtf, but I like it.

    Just wanted to mention that most of this horrible code in this issue is optimized by the compiler anyway, isn't it?

    Nope. Most of it just blows up in the user's face.

  • Andrew in a Suit (unregistered) in reply to @Deprecated
    "The sad part about this code," Ramin writes," is that its author actually tries to justify this pattern. " 
    googleId = googleId == null ? null : googleId; // ensure really null

    The sad part about some broken VMs I can name, possibly still including PHP, is that the pattern is justifiable.

  • Harrow (unregistered)

    cAMELtOEvARS cONSISTENTcODEfORMATTING eTC.

    -hARROW.

  • AHB (unregistered)

    This reminds me of a CS professor I had in college. He was from Germany and had a thick accent. His grammar was understandable, but sometimes hilarious.

    One day he was giving a lecture on probability:

    "OK, say we flip ze coin. Now, say I want head." I smile at one of my classmates. A few minutes later "OK, so all I want is head." Now I snicker a little and I'm having trouble not laughing. I look around at the rest of the 19 year olds in the classroom and the situation is dire, everyone is about to bust out laughing. After he says a couple more variations of "All I want is head" he realizes that something's up and next time it's, "so now all I want is tail" and everybody's laughing out loud.

    Another time he was talking about dynamic programming and the problem of loading packages of different sizes into a truck. He's trying to call the algorithm the packer but it comes out as pecker. He brought the house down once he started talking about using recursion, asking his "little brother" to do some of the work for him: "SO now I'm going to use my little brother's pecker..."

  • (cs) in reply to djmaze
    djmaze:
    public static bool IsInfiniteLoop()
{
    return !IsFiniteLoop();
}

    public static bool IsFiniteLoop()
{
return !IsInfiniteLoop();
}
    

    void definiteCrash()
{
IsInfiniteLoop();
}
    Hmm, how about this? 
    public static bool IsInfiniteLoop()
{
	try
	{
		return !IsFiniteLoop();
	}
	catch (StackOverflowException)
	{
		return true;
	}
}

public static bool IsFiniteLoop()
{
	try
	{
		return !IsInfiniteLoop();
	}
	catch (StackOverflowException)
	{
		return !true;
	}
}
  • iMalc (unregistered)

    Camel Case is great until you start writing methods with names such as the clbuttic: bool PenIsUp() { return !PenIsDown(); } bool PenIsDown() { return !PenIsUp(); }

  • Anonymous (unregistered)

    Anyone who can't see what the GoogleID comment is doing needs to brush up on some modern languages. I could immediately determine the intention of that code and why it was doing what it was doing.

    Like it or not, loose comparison is becoming extremely common thanks to languages like PHP and javascript. Yes, the real WTF may be the language itself, and it may be stupid, but that doesn't change the fact that many modern languages are heading that direction and you need to at least be able to interpret code that way in your head when necessary, or start preparing for retirement.

  • methinks (unregistered)

    As usual, the "Real WTF" (TM) lies in the comments:

    Most commenters obviously did not get that

    1. "Camel toe" is a mix-up with "camel case", a naming convention for source code identifiers, in which adjacent words in otherwise completely lowercase names start with a capital letter to increase readability: thisIsACamelCasedIdentifier "Camel case" thus pertains to the "humps" inside such names.

    2. "Camel toe" is something completely different and quite a well known meme on "teh internets": http://www.urbandictionary.com/define.php?term=camel+toe

    The russian guy was obviously thinking about something else when writing this ;o)

    Remember, the internet is for p0rn! ;o) http://www.youtube.com/watch?v=T-TA57L0kuc

  • jerk_programmer (unregistered) in reply to DES
    DES:
    FeepingCreature:
    The googleId one _might_ make sense if the language supports overloading == and googleId is an object defined to sometimes return true on equality to null.

    No, it will never make sense. What it actually does is:

    googleId = googleId

    Incorrect.

    Perl: http://stackoverflow.com/questions/137487/null-vs-false-vs-0 Javascript: http://www.bloggingdeveloper.com/post/JavaScript-null-vs-undefined-The-Difference-between-null-and-undefined.aspx

    and so on, it is very common in dynamically typed languages that 2 values may be equal under == but have different types and be not equal under some other operator such as ===

  • wulf (unregistered) in reply to sink
    sink:
    ((Object)this).toString executes the implementation of Object instead of extented class. Like in super.super....toString().

    No. It doesn't matter what super or interface type you choose to "view" an object as, it matters what specific type the object actually is. That's the whole point, really. Your way would make inheritance completely useless.

  • sink (unregistered) in reply to wulf

    Right! I turned crazy by trying to force sanity into that code.

  • sink (unregistered) in reply to wulf
    wulf:
    sink:
    ((Object)this).toString executes the implementation of Object instead of extented class. Like in super.super....toString().

    No. It doesn't matter what super or interface type you choose to "view" an object as, it matters what specific type the object actually is. That's the whole point, really. Your way would make inheritance completely useless.

    Right! I turned crazy by trying to force sanity into that code

  • nothanks (unregistered) in reply to methinks
    methinks:
    As usual, the "Real WTF" (TM) lies in the comments:

    Most commenters obviously did not get that [...]

    Whoosh!

  • the_joke_explained (unregistered)

    http://en.wikipedia.org/wiki/Cameltoe

  • MSCW (unregistered) in reply to IronMensan
    IronMensan:

    I've defined += on container classes and I've defined == on a few classes

    That doesn't mean that your operators makes sense just because you defined them. Who are you, after all, russian coder?

  • MSCW (unregistered) in reply to bl@h
    bl@h:
    Since when are camels native to Russia?

    Since 1917 when we conquered Asia steppes

  • (cs)

    VB6?

    Birds?

    ::evil swamplike flashbacks::

  • zx (unregistered)

    a question to native speakers: how would you rewrite the Russian guy's comment in a proper way?

  • apoc9 (unregistered) in reply to sink

    No, It doesn't.

    super.toString() // call method toString defined in parent class of this instance ((Object) this).toString() // this is Object & call method toString on this instance

Leave a comment on “Convoluted toString, Interesting Comments, and More”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article