• (disco)

    Discourse is a type of insanity: [image]

  • (disco) in reply to LB_

    You're just not privy to the whispers on this thread.

  • (disco) in reply to Tsaukpaetra
    Tsaukpaetra:
    You're just not privy to the whispers on this thread.

    nah. unlisting the thread for rasins counts as a post.

    because discourse

  • (disco) in reply to accalia
    accalia:
    nah. unlisting the thread for rasins counts as a post.

    But what about the second reply that @LB_ had a notification for? Whispers, man! Whispers!

    Also, I think you may have whooshed.

    Edit :fa_flag_checkered:

  • (disco)

    26 posts were split to a new topic: Whooshing in an article

  • (disco)

    I don't know much Python; is that last one supposed to be:

    currentYear = datetime.now().year
for age in ages:
    result['years'].append(currentYear - age)  # this is only approximate
  • (disco) in reply to Foo_Bar

    Only if you assume that everyone's birthday is the first of January…

  • (disco) in reply to dkf
    dkf:
    Only if you assume that everyone's birthday is the first of January…

    or if are okay with overestimating the age of people by a maximum of one year and an average of six months

  • (disco)

    I like its attempt at handling leap years- they even recognize that the centennial years don’t get leap years and drop 1/100 (of course, that only applies to centennial years divisible by 4, like 2000, but not 1900) .

    And this is again why you don't roll your own date logic. TRWTF is the article gets this backwards.

    All centennial years are divisible by 4 (100 % 4 = 0), author was looking for 400 as the exemption where you have a regular leap year on a centennial, as 2000 was a leap year, but 1900 and 2100 will not be.

    http://www.timeanddate.com/date/leapyear.html

  • (disco)

    The student ID one looks like a roundabout way to strip leading zeroes. I've seen similar things done.

  • (disco) in reply to David_Green
    David_Green:
    strip leading zeroes

    Don't do that. It's not a number; it's an identifier. It's an arbitrary sequence of characters (all of which happen to be digits). You're not going to be doing arithmetic on it. Leave it as a string.

    If you want to accept input without the leading zeroes, fine; left-pad it with '0' characters. If you want to display it without the leading zeroes (why?), substring is more efficient than string->int->string.

    Just like ZIP codes, phone numbers, etc.: They're not numbers; don't use numeric types for them.

  • (disco)

    someObj.SomeProperty = (AClass) null != null ? null : instanceOfAClass;

    Um.... UM!! UMMMMMMMMMMMMMMMMMMMMMM!!!!!!!!!!!!!!!

    WHY?! WHY?!?!?! WHY WHY WHY?!?!?!?!eleventyone

    *Calms down

    Someone please tell me there is a tiny bit of logic in this statement. Please!

  • (disco) in reply to J_T

    I wish I could but... well, I wish I could, that's all.

  • (disco) in reply to J_T
    J_T:
    Someone please tell me there is a tiny bit of logic in this statement. Please!

    If you want logical statements, why are you reading TDWTF?

  • (disco) in reply to J_T
    J_T:
    WHY?!

    Why? Some programmer somewhere is a fucking idiot.

    News at eleven.

    (At least the compiler will be able to throw that crap out and issue simple code out the back end.)

  • (disco) in reply to dkf
    dkf:
    Someone programmer somewhere is a fucking idiot.

    FTFY.

  • (disco) in reply to J_T

    Oh come on, it's perfectly obvious. What about those situations where null isn't really null, it's just pretending to be null in order to try and fool the door staff? This implementation is precisely how you get around this sort of stuff that nulls try to pull when you're not on your guard. "Sorry, but if you tell me you're null but in fact you're not null, then I'm just going to have to treat you as null and if you're actually not null, you will be after I've finished with you, sunshine. That'll learn yer ..."

  • (disco) in reply to Quite

    That code is just to handle the case of typed nulls.

    But in this case - if the null of type AClass is not identical to the null of class object -, that statement will try to assign a value of type object (which happens to be null) to a property of type AClass, which is bound to fail. Not just throw an exception, but at compile time. (Unless the property is of type object. Why not, everything being of type object saves a lot of trouble with type mismatch errors.)

  • (disco)

    I've been seeing a lot of code lately from developers who mostly work with weak-typed languages, trying to use a strongly-typed language. They have this general mistrust of numbers of any sort, and will only use string variables everywhere. Lots of casts from strings to ints or doubles and back.

    The worst I've seen is people doing this while buffering output for an RNG. They end up with zeroes stripped out of sequences of numbers which does wonders for the supposedly random distribution, or strings that are accidentally null-terminated early (direct cast of bytes to characters).

    I just want to reassure them and tell them it's OK, the bad languages can't hurt them here. You are in control, you can decide how numbers will be represented, and you can trust them to never change. Unless they fuck something else up spectacularly.

Leave a comment on “A Type of Insanity”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article