Comment On Double Line

FristOfManyCommentsOrItWillBeIfICanFinishWritingItBeforeSomeoneElseGetsThereBeforeMeAlthoughIKnowThisIsProbablyAFairlyForlornHope

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

QJo:

FristOfManyCommentsOrItWillBeIfICanFinishWritingItBeforeSomeoneElseGetsThereBeforeMeAlthoughIKnowThisIsProbablyAFairlyForlornHope

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

Crack, mostly.

Double FRIST

Or maybe not.

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

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...

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.

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.

int length = 3;

Optimized.

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

print $commentNumber%8?"TRWTF is VB":"Frist!"

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....

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.

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

SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceAndUpdatesProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlready1
SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceAndUpdatesProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlready2
SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceAndUpdatesProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlready3

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

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;

}

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.

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 ^^

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

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()

...AndMakesYouCoffeeAndFixesTheKitchenSinkToo()

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

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()

	))))))))));

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

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

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.

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

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;

}

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.

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?

/// <summary>

/// 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.

/// </summary>

public bool ChangingStorePriceModifiesProductInfo

{

    set;

    get;

}

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.

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.

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"

;)

Rawr:

/// <summary>

/// 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.

/// </summary>

public bool ChangingStorePriceModifiesProductInfo

{

    set;

    get;

}

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

/// <summary>

/// 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.

/// </summary>

public bool SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceAndUpdatesProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlready

{

    set;

    get;

}

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.

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.

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

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

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

Uncle Al:

Rawr:

/// <summary>

/// 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.

/// </summary>

public bool ChangingStorePriceModifiesProductInfo

{

    set;

    get;

}

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

/// <summary>

/// 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.

/// </summary>

public bool SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceAndUpdatesProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlready

{

    set;

    get;

}

No, no, no. Clearly you are moving in the wrong direction. We want small, concise variable names:

/// <summary>

/// 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.

/// </summary>

public bool Setting463

{

    set;

    get;

}

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.

BentFranklin:

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

Malicious compliance FTW!

"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.

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.

BentFranklin:

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

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

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?

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.

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.

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.

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?

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