Comment On Double Line

[quote user="airdrik"][quote user="Uncle Al"][quote user="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;

}

[/quote]

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;

}

[/quote]
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;

}

[/quote]

If we're using concise variable names, surely we ought to pair them with verbose comments.

/// <summary>

/// If this is true, then setting "store price" changes store

/// product price, updates product price, and updates product

/// modified timestamp. It does not modify a product that has

/// non-default pricing already.

///

/// If this is false, then setting "store price" changes store

/// product price only, causing the product to have a

/// non-default price.

///

/// To change both the store price and the product price on a

/// product with non-default pricing, causing it to have 

/// default pricing again, just set this to true and

/// Setting281 to false, set the product price to 0, then set

/// the store price.

/// </summary>

public bool Setting463

{

    set;

    get;

}

[/quote]

(Comment extrapolated from original function name, mostly.)

My COBOL final exam left me with 3 pencils worn down completely and a hand so cramped I couldn't beat off for a week.

Sectoid Dev:

My COBOL final exam left me with 3 pencils worn down completely and a hand so cramped I couldn't beat off for a week.

I once had a similar problem, except the cause and effect were reversed.

boog:

QJo:

boog:

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.

Giggle. Thank you, that remark has made my day!

corwin766:

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?

You never learned to "soft-type" :P

Ghost of Nagesh:

corwin766:

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?

You never learned to "soft-type" :P

COBOL's rubbish. Use FORTRAN instead. You know it makes sense.

Matt Westwood:

COBOL's rubbish. Use FORTRAN instead. You know it makes sense.

FORTRAN = FORmula TRANslation, and Scientists are the ones who use formulas. But COBOL = COmmon Business-Oriented Language, i.e., is for business applications. QED. Besides, FORTRAN is only fun if you can use it on punch cards.

Now, you kids need to get off not just my lawn, but my neighbour's lawn too.

FuBar:

Matt Westwood:

COBOL's rubbish. Use FORTRAN instead. You know it makes sense.

FORTRAN = FORmula TRANslation, and Scientists are the ones who use formulas. But COBOL = COmmon Business-Oriented Language, i.e., is for business applications. QED. Besides, FORTRAN is only fun if you can use it on punch cards.

Now, you kids need to get off not just my lawn, but my neighbour's lawn too.

You can use FORTRAN for business applications, but it's not really feasible to use COBOL for scientific applications. I've said enough.

If this isn't a featured comment I'm done with TDWTF.

Abso:

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>

...

If we're using concise variable names, surely we ought to pair them with verbose comments.

/// <summary>

/// If this is true, then setting "store price" changes store

/// product price, updates product price, and updates product

/// modified timestamp. It does not modify a product that has

/// non-default pricing already.

///

/// If this is false, then setting "store price" changes store

/// product price only, causing the product to have a

/// non-default price.

///

/// To change both the store price and the product price on a

/// product with non-default pricing, causing it to have 

/// default pricing again, just set this to true and

/// Setting281 to false, set the product price to 0, then set

/// the store price.

/// </summary>

...

(Comment extrapolated from original function name, mostly.)

Except that the new comment is a step backwards in unreadability since it adds and clarifies several of the details, including a clear explanation of what a false setting means and a similarly clear explanation of how to get something to a default state.

I do agree that we should pair concise variable names with verbose comments, but our improvements must ensure that the new version is no more readable/usable than the original. I also like the reference to the other obfuscated setting.

[code]/// <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.
/// If this is false then setting store price does not changes store product price and updates product price and updates product modified timestamp but does modify a product that has non default pricing already unless Setting281 is false which reverses them.
/// </summary>

Are you a LISP programmer by chance?

airdrik:

[code]/// <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.
/// If this is false then setting store price does not changes store product price and updates product price and updates product modified timestamp but does modify a product that has non default pricing already unless Setting281 is false which reverses them.
/// </summary>

Yep, that's perfect. Sod the unit tests, that's bound to compile - can you release it to production immediately, the customer's in the CEO's office waiting at a terminal.

Martin D:

If this isn't a featured comment I'm done with TDWTF.

TransexualDruggieWithTheFuckingness? What?

Anyway, there's no chance of a comment with my name ever getting featured as Papadilililimous has a hard on for me for desecrating his comments page. I have a hard on for him too!


I wonder if there's some kind of job that I can do to change his feelings about me. I'm not just about flapping my gums, I can get my hands dirty if necessary!

Warren:

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

No need: method names in VS are limited, to 250 Unicode characters.

Cad Delworth:

Warren:

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

No need: method names in VS are limited, to 250 Unicode characters.

I'm suddenly reminded about a WTF of a language - which one I can't remember just now - such that the compiler lets you define variables with as many characters as you like, but only *actually* takes any notice of the first 31.

So if you define two variables with names 100-odd characters long, only the last 50 of those being different, the compiler will treat these as the same variable, and not tell you what it's doing.

Although it may be kind and tell you that you've just tried to declare the same variable twice - I can't say.

Matt Westwood:

Cad Delworth:

Warren:

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

No need: method names in VS are limited, to 250 Unicode characters.

I'm suddenly reminded about a WTF of a language - which one I can't remember just now - such that the compiler lets you define variables with as many characters as you like, but only *actually* takes any notice of the first 31.

So if you define two variables with names 100-odd characters long, only the last 50 of those being different, the compiler will treat these as the same variable, and not tell you what it's doing.

Although it may be kind and tell you that you've just tried to declare the same variable twice - I can't say.

ANSI C?

The reference I have here says that's the case, but only for identifiers that don't have external linkage. For identifiers with external linkage, apparently only the first six characters are significant, and they're case insensitive. Isn't backwards compatibility wonderful?

Mind you, said reference also notes that "Most compilers and linkers are more generous than the standard". And it was published in 1996, so C99 might be better, I guess.

Matt Westwood:

it's not really feasible to use COBOL for scientific applications.

You. Are. No. Fun. At. All.

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.

So long as it doesn't get mixed up with:

public bool SUPERCALAFREGALISTICEXPIALADOCIOUS

{

get;

set;

}

(perhaps that's why people talk about spoonfuls of Syntactic Sugar)

The Most Interesting Man in the World (Dos Equis Guy):

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.

Tests are for Wusses!!

We have plenty of undocumented features in our code, but at least it compiles!!

I was thinking the same thing...Single Responsibility principle.

Matt Westwood:

Cad Delworth:

Warren:

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

No need: method names in VS are limited, to 250 Unicode characters.

I'm suddenly reminded about a WTF of a language - which one I can't remember just now - such that the compiler lets you define variables with as many characters as you like, but only *actually* takes any notice of the first 31.

So if you define two variables with names 100-odd characters long, only the last 50 of those being different, the compiler will treat these as the same variable, and not tell you what it's doing.

Although it may be kind and tell you that you've just tried to declare the same variable twice - I can't say.

Sounds like UNIX Password, no?

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.

I think there's a bright future ahead of you as a system architect.

Might as well make the property generic too

        public T GenericSettingAssociatedToStorePriceChangesForStoreProductPriceIfTypeIsStorePriceElseThrowsExceptionForTypesDerivedFromItemPriceAndMayUpdateProductPriceDependingOnTypeAlwaysUpdatesProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlreadySometimesExceptWhenSettingIsNotNull

        {



            set;



            get;



        }

data was a list of chars which was the received message. It would be something like '013[the message]'. GetRange() was used to get the 'substring' of the message length, and he proceeded to get the length of the substring and take that as the length of the message, rather than actually parsing the string. End result is only the first three characters of any message were ever seen.

The sad thing was that the original working code was replaced with this for some reason.

Abso:

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;

}

No, no. Nothing beats good old C convention. Easy to read and much shorter to type too:
stngstrprcchngsstrprdctprcnupdtsprdctprcnupdtsprdctmdfdtmstmpbtdsntmdfyaprdctththsndfltprcnglrdy();

I create functions that are just as meaningfull

public bool foo
{
....
}

Matt Westwood:

I'm suddenly reminded about a WTF of a language - which one I can't remember just now - such that the compiler lets you define variables with as many characters as you like, but only *actually* takes any notice of the first 31.

Reminds me of the first computer we had, one of the early 8-bit micros; in its BASIC interpreter only two characters of the variable name were used. You could use a string variable concurrently with a numeric variable of the same name, though (A$ and A respectively).

But then, when you only have 6K of program memory you don't want to take up much of it with variable names.

Z00n3$!$:

Sectoid Dev:

My COBOL final exam left me with 3 pencils worn down completely and a hand so cramped I couldn't beat off for a week.

I once had a similar problem, except the cause and effect were reversed.

What on earth were you doing with the pencils?

Also, I think the people posting commented versions of the code have in general forgotten that the comments should not describe the function correctly. Otherwise they'd be too useful. You need to guess what the function did two or three revisions ago and write the comments based on that.

Z00n3$!$:

Sectoid Dev:

My COBOL final exam left me with 3 pencils worn down completely and a hand so cramped I couldn't beat off for a week.

I once had a similar problem, except the cause and effect were reversed.

You wore down 3 pencils wanking?!?

[quote user="Hatshepsut"][quote user="Z00n3$!$"]

You wore down 3 pencils wanking?!?

[/quote]

Who hasn't done something like this?

Kittens:

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.

So long as it doesn't get mixed up with:

public bool SUPERCALAFREGALISTICEXPIALADOCIOUS

{

get;

set;

}

(perhaps that's why people talk about spoonfuls of Syntactic Sugar)

Arrg. Oh my fucking god. You are *one fired programmer* if you come near my department - you spelt the name of the word wrong. Have you any idea how difficult that makes maintenance? Everyone know's it's "supercallifraggalisticexpealadosuhs"!

Jimbo:

The Most Interesting Man in the World (Dos Equis Guy):

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.

Tests are for Wusses!!

We have plenty of undocumented features in our code, but at least it compiles!!

what is this "documenting" that you speak of?

The Most Interesting Man in the World (Dos Equis Guy):

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.

If it works, it's production.
If it doesn't work ... we were just testing.

My representative line of the day. Describing the code quality of a web site I was asked to check:

<td class="header">

'nuff said.

Is it just me or has that string broken the side of the browser, lapsing into freedom out of the confines of the text box?

Abso:

Matt Westwood:

I'm suddenly reminded about a WTF of a language - which one I can't remember just now - such that the compiler lets you define variables with as many characters as you like, but only *actually* takes any notice of the first 31.

So if you define two variables with names 100-odd characters long, only the last 50 of those being different, the compiler will treat these as the same variable, and not tell you what it's doing.

Although it may be kind and tell you that you've just tried to declare the same variable twice - I can't say.

ANSI C?

The reference I have here says that's the case, but only for identifiers that don't have external linkage. For identifiers with external linkage, apparently only the first six characters are significant, and they're case insensitive. Isn't backwards compatibility wonderful?

Mind you, said reference also notes that "Most compilers and linkers are more generous than the standard". And it was published in 1996, so C99 might be better, I guess.

It was a WTF-y linker on one commercial Unix (AIX?) that was responsible for that statement in the standard. (The real old school linkers that only coped with up to 7 characters of identifier name as distinguishing having been long gone at that point.) The advent of C++ forced a shake-out of all that nonsense; while C was usually possible within the restrictions of 31 significant chars, C++'s internal name mangling can easily blow past that before the actual function name is reached (let alone any argument types).

The ANSI C committee tried very hard to not alienate any vendors. I can understand that, but sometimes you need to single out the runt for a vicious beating. It's for the good of all.

The function is incomplete. It should be:

public bool SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceAndUpdatesProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlready
{
ready;
get;
set;
go;
}

This is supposed to be a highly-descriptive property name?

public bool SettingStorePriceChangesStoreProductPriceAndUpdatesProductPriceAndUpdatesProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlready
{
get;
set;
}

It is not at all descriptive. Imagine an alien species that has no conception of "Store", "Price" and "Product". How are they supposed to understand this? The property name should at the very least include the Wikipedia articles for the above mentioned concepts.
Furthermore not everyone speaks english. The property name must contain its own translation in at least 10 languages to be of any use at all.
Not everyone can read. To be even minimally usueful it is obviously obvious that the property name must contain the base64 encoding of a video of a speaker explaining the property name.

Hmmm.. If this property is really implemented like it name says, then it has side effects which is not done...

airdrik:

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;

}

Exactly. I like descriptive variables too though - I call a variable e.g. "DatabaseConnection" instead of "dbconn" - but one shouldn't exaggerate.

Scarlet Manuka:

Z00n3$!$:

Sectoid Dev:

My COBOL final exam left me with 3 pencils worn down completely and a hand so cramped I couldn't beat off for a week.

I once had a similar problem, except the cause and effect were reversed.

What on earth were you doing with the pencils?

Heh, heh. Better question is: what was I using instead of a pencil?

Matt Westwood:

Kittens:

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.

So long as it doesn't get mixed up with:

public bool SUPERCALAFREGALISTICEXPIALADOCIOUS

{

get;

set;

}

(perhaps that's why people talk about spoonfuls of Syntactic Sugar)

Arrg. Oh my fucking god. You are *one fired programmer* if you come near my department - you spelt the name of the word wrong. Have you any idea how difficult that makes maintenance? Everyone know's it's "supercallifraggalisticexpealadosuhs"!

No no, that wasn't supposed to be the name of the word, it was supposed to be what the name of the word is called.

Wait, wrong story.

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.

I interpret the summary as "the data will be treated as a 3-char string", and that the real code should've been something like:

int length = int.Parse(string.Concatenate(data.GetRange(0, 3)));

[quote user="Matt Westwood"][quote user="Cad Delworth"]

I'm suddenly reminded about a WTF of a language - which one I can't remember just now - such that the compiler lets you define variables with as many characters as you like, but only *actually* takes any notice of the first 31.

So if you define two variables with names 100-odd characters long, only the last 50 of those being different, the compiler will treat these as the same variable, and not tell you what it's doing.

Although it may be kind and tell you that you've just tried to declare the same variable twice - I can't say.[/quote]

That happenned on DOS and early Windows but it was not a language limitation but one of the linker.
When C++ was invented with its name mangling scheme this limit was then lifted.

Early BASICs also had a 2 significant character limit, that was a PITA.

Sol the Sun God:

Matt Westwood:

Cad Delworth:

Warren:

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

No need: method names in VS are limited, to 250 Unicode characters.

I'm suddenly reminded about a WTF of a language - which one I can't remember just now - such that the compiler lets you define variables with as many characters as you like, but only *actually* takes any notice of the first 31.

So if you define two variables with names 100-odd characters long, only the last 50 of those being different, the compiler will treat these as the same variable, and not tell you what it's doing.

Although it may be kind and tell you that you've just tried to declare the same variable twice - I can't say.

Sounds like UNIX Password, no?

NTLM. Two times seven characters, ignore-case, IIRC, separately breakable. Should have been strangled at birth. The designer, that is.

Matt Westwood:

You can use FORTRAN for business applications, but it's not really feasible to use COBOL for scientific applications. I've said enough.

Feasible, no, but that never stopped anyone. I recall reading of some lunatic who wrote a Z80 cross-assembler in COBOL on an IBM mainframe, back in the 1970s. It's hard to imagine why this sounded like a good idea, aside from it apparently being the only language he had available to him at the time.

Very good

+100000000

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.

Very Good

+infinity +1

foo:

Abso:

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;

}

No, no. Nothing beats good old C convention. Easy to read and much shorter to type too:
stngstrprcchngsstrprdctprcnupdtsprdctprcnupdtsprdctmdfdtmstmpbtdsntmdfyaprdctththsndfltprcnglrdy();

That's the name of a Welsh town or something, right?

Scourge:

Is it just me or has that string broken the side of the browser, lapsing into freedom out of the confines of the text box?

Nope, happened to me too in my little "forced by IT to use IE7 world"

/// <summary>
/// Does the work that this class was written to do
/// by using parameters A and B, then writes the results
/// to the database
/// /* No I'm not actually going to tell you what the method
/// does, just obeying the company's coding standards */
/// </summary>
DoTheClassesWorkOnParametersAandBThenWriteResultsToTheDatabaseAndPerhapsDoSomeSideEffectsOnTheParameters(object A, object B) throws SomethingBadHappenedExceptionButImNotGoingToTellYouWhatBecauseSomeHackersMayExploitThatInformation