• QJo (unregistered)

    FristOfManyCommentsOrItWillBeIfICanFinishWritingItBeforeSomeoneElseGetsThereBeforeMeAlthoughIKnowThisIsProbablyAFairlyForlornHope

    And Akismet thinks it's spam. What is he on?

  • Akismet (unregistered) in reply to QJo
    QJo:
    FristOfManyCommentsOrItWillBeIfICanFinishWritingItBeforeSomeoneElseGetsThereBeforeMeAlthoughIKnowThisIsProbablyAFairlyForlornHope

    And Akismet thinks it's spam. What is he on?

    Crack, mostly.

  • DonaldK (unregistered)

    Double FRIST

    Or maybe not.

  • tehR (unregistered)

    It's self-documenting code. D'uh.

  • Charleh (unregistered)

    Wow, almost frist never seen so little comments on a WTF - must have clicked on at the instant it was posted.

    By the time I've finished writing this, I predict there will be at least 5 other comments...

  • (cs)

    Ah! This reminds me of some code I found from some guy who really loved Grails dynamic finders, but this guy took the concept to another level:

    findAllByDateTimeReceivedBetweenAndAmountLeftJoinByIdsGroupByAmountBookUserTitle(java.sql.Date date)

    Not exactly the name of the method, but you get the idea.

  • QJo (unregistered)

    I've thought of a way to improve it:

    public bool SSPCSPPAUPPAUPMTBDNMAPTHNDPA { get; set; }

    ... cut the name down to its initials. A dramatic improvement, though I say it myself.

  • (cs) 
    int length = 3;

    Optimized.

  • (cs)

    The first one seems to be a sarcastic response to something a PHB might have said.

  • Jerry (unregistered) 
    print $commentNumber%8?"TRWTF is VB":"Frist!"
  • Warren (unregistered)

    Clay continues, "someone should write a plug-in that limits method names to a sane amount of characters."

    He submitted it using the Daily WTF add-in. That limits bad practice for most of us....

  • (cs)

    I'm not sure how this is going to "corrupt data".

    int length = data.GetRange(0, 3).ToArray().Length;

    The summary (seems to) state that data will be a 3-character string. I thought maybe it was failing on 0/1/2-character strings, but GetRange would throw an exception, rather than "corrupting data".

    Either the summary is confusing, or I'm missing something fundamental. 50/50 odds, I'd say.

  • (cs)

    Imagine the auto-complete fun if there were several similarly named functions:

    SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceAndUpdatesProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlready1 SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceAndUpdatesProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlready2 SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceAndUpdatesProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlready3

  • AP2 (unregistered)

    When Martin Fowler wrote "Code As Documention", I think that wasn't what he had in mind.

  • (cs)

    I'm usually pro Camel/Pascal casing. However, this WTF shows readability does seem to break down with very long variable names. Maybe I'll join the underscore camp now.

    //See- so much better
public bool Setting_Store_Price_Changes_Store_Product_Price_And_Updates_Product_Price_And_Updates_Product_Modified_Timestamp_But_Does_Not_Modify_A_Product_That_Has_Non_Default_Pricing_Already
{
    set;
    get;
}
  • (cs) 
    int length = data.GetRange(0, 3).ToArray().Length;

    When you see stuff like that in one of those applications, you know somewhere up in the call stack there's something like

    try
{
    // Use the data
    ...
}
catch(ArgumentException)
{
    // OPTIMIZATION!!
    // To avoid testing if data.Length < 3, I'll just catch
    // the exception thrown here
    DoSomeVeryImportantStuffInCaseTheLengthOfDataIsInferiorToThreeBecauseExceptionsAreLikeReturnsAndCatchClausesIsWhereRealMenDoBusinessLogic();
}

    that you will totally break if you correct the aforementioned line.

  • (cs)

    For the first thing, StyleCop will give you a warning for such beautiful and descriptive names. StyleCop will also warn you if you forgot providing /// comments for public properties, methods, ...

    But such smart developers will disable that warnings ^^

  • Fjool (unregistered)

    Having 'and' in a method/test name is a smell indicating the method is doing more than it should. In this case, however... :?

    captcha: consequat - the results of eating an overripe kumquat

  • (cs) in reply to Fjool
    Fjool:
    Having 'and' in a method/test name is a smell indicating the method is doing more than it should. In this case, however... :?
    function crashAndBurn()
  • (cs)

    ...AndMakesYouCoffeeAndFixesTheKitchenSinkToo()

    and this and that and another thing, and it adds up to nothing in particular.

  • (cs) in reply to frits
    frits:
    I'm usually pro Camel/Pascal casing. However, this WTF shows readability does seem to break down with very long variable names. Maybe I'll join the underscore camp now. 
    //See- so much better
public bool Setting_Store_Price_Changes_Store_Product_Price_And_Updates_Product_Price_And_Updates_Product_Modified_Timestamp_But_Does_Not_Modify_A_Product_That_Has_Non_Default_Pricing_Already
{
    set;
    get;
}

    I prefer fluent stuff, because you can use returns! So much more readable like this:

    Setting(Store.Price
    .Changes(
        Store().Product.Price
        .And(
		    Updates(
			   Product.Price
	           .And(Updates(Product.Modified(Timestamp()
	.But(Does
	.Not()
	    .Modify(A.Product
		    .That().Has(Non().Default.Pricing.Already()
	))))))))));
  • anonymous (unregistered) in reply to Charleh
    Charleh:
    Wow, almost frist never seen so little comments on a WTF - must have clicked on at the instant it was posted.

    By the time I've finished writing this, I predict there will be at least 5 other comments...

    !nostradamus

  • (cs)

    The first one is actually from obfuscated code. The developer used a product called ItWorksBecauseItTurnsAllPropertyNamesIntoLongWindedNonsenseAndMostDevelopersHaveADHDAndWillLoseInterestFuscator.

  • OneMist8k (unregistered)

    Apropos of the WTF on female programmers, I'm going to guess the gender of each programmer.

    The first one was written by a female who likes long members.

    The second was written by a male who thinks length doesn't matter.

  • (cs) in reply to snoofle
    snoofle:
    Imagine the auto-complete fun if there were several similarly named functions:

    SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceAndUpdatesProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlready1 SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceAndUpdatesProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlready2 SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceAndUpdatesProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlready3

    Could this really be a case where it's better design (for maintenance' sake) to put a number at the end of the function? You could easily look at the end of the name to know what you're dealing with.

    Consider the alternative:

    SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceButDoesNotUpdateProductModifiedTimestampOrModifyAProductThatHasNonDefaultPricingAlready SettingStorePriceChangesStoreProductPriceButDoesNotUpdateProductPriceOrUpdateProductModifiedTimestampOrModifyAProductThatHasNonDefaultPricingAlready SettingStorePriceChangesStoreProductPriceButDoesNotUpdateProductPriceButDoesUpdateProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlready SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceAndHolyShitsnacksIHopeNobodyHasToMaintainThisSinceItsHardToSeeDifferencesInTheseNamesWhenTheyreNotLinedUpAboveEachOther

  • Abso (unregistered) in reply to frits
    frits:
    I'm usually pro Camel/Pascal casing. However, this WTF shows readability does seem to break down with very long variable names. Maybe I'll join the underscore camp now.

    I think it's improved even more if you don't mix the two systems. That is, do use underscores, but don't capitalize every word.

    Look at how nearly-readable this is!
public bool Setting_store_price_changes_store_product_price_and_updates_product_price_and_updates_product_modified_timestamp_but_does_not_modify_a_product_that_has_non_default_pricing_already
{
    set;
    get;
}
  • Someone who can't be bothered to login from work (unregistered) in reply to hfrmobile
    hfrmobile:
    For the first thing, StyleCop will give you a warning for such beautiful and descriptive names. StyleCop will also warn you if you forgot providing /// comments for public properties, methods, ...

    But such smart developers will disable that warnings ^^

    Only if they don't also use StyleCop, which will by default complain about exactly the same thing. In fact it will complain about them being missing on private ones too.

    Documenting things using the native documenting system is hardly a terrible idea. Especially given Visual Studio will show those comments if you hover over a reference.

  • (cs) in reply to QJo
    QJo:
    I've thought of a way to improve it:

    public bool SSPCSPPAUPPAUPMTBDNMAPTHNDPA { get; set; }

    ... cut the name down to its initials. A dramatic improvement, though I say it myself.

    Send your resume to Peoplesoft, they hire people like you to design their data model.

    Why use a long name when "PSAESTEPMSGDEFN" will do the trick?

  • Rawr (unregistered) in reply to frits 
    /// 
/// Setting store price changes store product price and updates product price and updates product modified timestamp but does not modify a product that has non default pricing already.
/// 
public bool ChangingStorePriceModifiesProductInfo
{
    set;
    get;
}
  • virago (unregistered) in reply to OneMist8k
    OneMist8k:
    Apropos of the WTF on female programmers, I'm going to guess the gender of each programmer.

    The first one was written by a female who likes long members.

    The second was written by a male who thinks length doesn't matter.

    That's so disgustingly sexist I'm going to reply angrily to every single post I see from now till the next WTF is posted. Come the revolution, every computer software engineer will be female and those nasty geeky nerdy boys will be banished to wherever those nasty asperger types belong.

  • QJo (unregistered) in reply to boog
    boog:
    snoofle:
    Imagine the auto-complete fun if there were several similarly named functions:

    SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceAndUpdatesProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlready1 SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceAndUpdatesProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlready2 SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceAndUpdatesProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlready3

    Could this really be a case where it's better design (for maintenance' sake) to put a number at the end of the function? You could easily look at the end of the name to know what you're dealing with.

    Consider the alternative:

    SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceButDoesNotUpdateProductModifiedTimestampOrModifyAProductThatHasNonDefaultPricingAlready SettingStorePriceChangesStoreProductPriceButDoesNotUpdateProductPriceOrUpdateProductModifiedTimestampOrModifyAProductThatHasNonDefaultPricingAlready SettingStorePriceChangesStoreProductPriceButDoesNotUpdateProductPriceButDoesUpdateProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlready SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceAndHolyShitsnacksIHopeNobodyHasToMaintainThisSinceItsHardToSeeDifferencesInTheseNamesWhenTheyreNotLinedUpAboveEachOther

    This post is the first one I've read on this site which actually makes me feel quite ill. Well done, that man.

  • ~~ (unregistered)

    Variable name for all the ZX Spectrum users: "this name is so long that I shall never be able to type it out again without making a mistake"

    ;)

  • Uncle Al (unregistered) in reply to Rawr
    Rawr:
    /// 
/// Setting store price changes store product price and updates product price and updates product modified timestamp but does not modify a product that has non default pricing already.
/// 
public bool ChangingStorePriceModifiesProductInfo
{
    set;
    get;
}

    No, no, no. Clearly, the right approach is:

    /// 
/// Setting store price changes store product price and updates product price and updates product modified timestamp but does not modify a product that has non default pricing already.
/// 
public bool SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceAndUpdatesProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlready
{
    set;
    get;
}
  • Abso (unregistered) in reply to OneMist8k
    OneMist8k:
    Apropos of the WTF on female programmers, I'm going to guess the gender of each programmer.

    The first one was written by a male who likes to claim he has a long member.

    The second was written by a male who habitually lies about length.

    FTFY

    A female programmer would be more concerned with width.

  • (cs) in reply to QJo
    QJo:
    boog:
    snoofle:
    Imagine the auto-complete fun if there were several similarly named functions:

    SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceAndUpdatesProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlready1 SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceAndUpdatesProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlready2 SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceAndUpdatesProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlready3

    Could this really be a case where it's better design (for maintenance' sake) to put a number at the end of the function? You could easily look at the end of the name to know what you're dealing with.

    Consider the alternative:

    SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceButDoesNotUpdateProductModifiedTimestampOrModifyAProductThatHasNonDefaultPricingAlready SettingStorePriceChangesStoreProductPriceButDoesNotUpdateProductPriceOrUpdateProductModifiedTimestampOrModifyAProductThatHasNonDefaultPricingAlready SettingStorePriceChangesStoreProductPriceButDoesNotUpdateProductPriceButDoesUpdateProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlready SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceAndHolyShitsnacksIHopeNobodyHasToMaintainThisSinceItsHardToSeeDifferencesInTheseNamesWhenTheyreNotLinedUpAboveEachOther

    This post is the first one I've read on this site which actually makes me feel quite ill. Well done, that man.

    I aim to quease.

  • (cs)

    Maybe IDEs should come with a tinyurl-like feature from now on.

  • Paul (unregistered)

    I sentence the first offender to 1 year of coding with autocomplete disabled. bangs gavel

  • Huey Lewis (unregistered)

    Testing? We don't need no stinking testing. The first rule is... if it compiles, move it to production.

  • airdrik (unregistered) in reply to Uncle Al
    Uncle Al:
    Rawr:
    /// 
/// Setting store price changes store product price and updates product price and updates product modified timestamp but does not modify a product that has non default pricing already.
/// 
public bool ChangingStorePriceModifiesProductInfo
{
    set;
    get;
}

    No, no, no. Clearly, the right approach is:

    /// 
/// Setting store price changes store product price and updates product price and updates product modified timestamp but does not modify a product that has non default pricing already.
/// 
public bool SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceAndUpdatesProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlready
{
    set;
    get;
}
    No, no, no. Clearly you are moving in the wrong direction. We want small, concise variable names: 
    /// 
/// Setting store price changes store product price and updates product price and updates product modified timestamp but does not modify a product that has non default pricing already.
/// 
public bool Setting463
{
    set;
    get;
}
  • The Most Interesting Man in the World (Dos Equis Guy) (unregistered) in reply to Huey Lewis
    Huey Lewis:
    Testing? We don't need no stinking testing. The first rule is... if it compiles, move it to production.
    I don't always test my code, but when I do, I do it in production.
  • (cs) in reply to BentFranklin
    BentFranklin:
    The first one seems to be a sarcastic response to something a PHB might have said.
    Malicious compliance FTW!
  • caper (unregistered)

    "Maybe I'll join the underscore camp now."

    Please do. camelCase is in my opinion useless for anything which is more than two small words stuck together.

  • NobodyCares (unregistered) in reply to ThingGuy McGuyThing
    ThingGuy McGuyThing:
    I'm not sure how this is going to "corrupt data".

    int length = data.GetRange(0, 3).ToArray().Length;

    The summary (seems to) state that data will be a 3-character string. I thought maybe it was failing on 0/1/2-character strings, but GetRange would throw an exception, rather than "corrupting data".

    Either the summary is confusing, or I'm missing something fundamental. 50/50 odds, I'd say.

    Given the only GetRange I know of in .NET is this, then I'd tend to say we've been sadly mislead. Par for the course, I suppose.

    I suspect that "data" is a list of strings, and if there's more than 3 of them then some were being ignored, which lead to much amusement later on in the form of missing messages or whatnot.

  • (cs) in reply to BentFranklin
    BentFranklin:
    The first one seems to be a sarcastic response to something a PHB might have said.

    ...or based on a PHB-mandated standard.

  • Hortical (unregistered) in reply to Abso
    Abso:
    OneMist8k:
    I'm going to guess the gender of each programmer.

    The first one was written by a male who likes to claim he has a long member.

    The second was written by a male who habitually lies about length.

    FTFY
    No ones pipes up to call that sexist.

    Abso:
    A female programmer would be more concerned with width.
    But that's blatant misogyny and chauvinism. How can you generalize about women like that?
  • (cs) in reply to caper
    caper:
    "Maybe I'll join the underscore camp now."

    Please do. camelCase is in my opinion useless for anything which is more than two small words stuck together.

    98% of my variable and Type names are two words stuck together, so I think I'm good right here.

  • (cs) in reply to caper
    caper:
    "Maybe I'll join the underscore camp now."

    Please do. camelCase is in my opinion useless for anything which is more than two small words stuck together.

    But to be fair, anything more than two small words stuck together is often in my opinion useless for naming variables.

    Then again, I'm in the "Who cares? Neither camelCase nor underscores makes code hard to maintain; code like today's examples do" camp. It's a pretty good camp. The food is so-so.

  • FuBar (unregistered) in reply to frits
    frits:
    Setting_Store_Price_Changes_Store_Product_Price_And_Updates_Product_Price_And_Updates_Product_Modified_Timestamp_But_Does_Not_Modify_A_Product_That_Has_Non_Default_Pricing_Already
    I don't understand why we ever left COBOL. It just worked. For business programming, anyway.
  • corwin766 (unregistered) in reply to FuBar
    FuBar:
    frits:
    Setting_Store_Price_Changes_Store_Product_Price_And_Updates_Product_Price_And_Updates_Product_Modified_Timestamp_But_Does_Not_Modify_A_Product_That_Has_Non_Default_Pricing_Already
    I don't understand why we ever left COBOL. It just worked. For business programming, anyway.

    I left COBOL because it gave me repetitive stress injury. No other language has accomplished that.

    COBOL design motto:Why use 1 character when 10 will do?

  • dguthurts (unregistered) in reply to OneMist8k
    OneMist8k:
    Apropos of the WTF on female programmers, I'm going to guess the gender of each programmer.

    The first one was written by a female who likes long members.

    The second was written by a male who thinks length doesn't matter.

    Best_Comment_Of_The_Day

Leave a comment on “Double Line”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article