Comment On Double Line

We've got two different representative lines from two entirely different systems. [expand full text]
« PrevPage 1 | Page 2 | Page 3Next »

Re: Double Line

2011-08-25 13:57 • by Abso (unregistered)
358447 in reply to 358434
[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.)

Re: Double Line

2011-08-25 14:08 • by Sectoid Dev (unregistered)
358450 in reply to 358445
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.

Re: Double Line

2011-08-25 14:23 • by Z00n3$!$ (unregistered)
358451 in reply to 358450
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.

Re: Double Line

2011-08-25 14:25 • by Peter (unregistered)
358453 in reply to 358427
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!

Re: Double Line

2011-08-25 14:29 • by Ghost of Nagesh (unregistered)
358454 in reply to 358445
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

Re: Double Line

2011-08-25 14:38 • by Matt Westwood
358456 in reply to 358454
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.

Re: Double Line

2011-08-25 14:44 • by FuBar (unregistered)
358457 in reply to 358456
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.

Re: Double Line

2011-08-25 16:01 • by Matt Westwood
358461 in reply to 358457
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.

Re: Double Line

2011-08-25 16:11 • by Martin D (unregistered)
358464 in reply to 358451
If this isn't a featured comment I'm done with TDWTF.

Re: Double Line

2011-08-25 16:22 • by airdrik (unregistered)
358465 in reply to 358447
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>

Re: Double Line

2011-08-25 16:30 • by stinerman (unregistered)
358466 in reply to 358407
Are you a LISP programmer by chance?

Re: Double Line

2011-08-25 16:33 • by Matt Westwood
358467 in reply to 358465
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.

Re: Double Line

2011-08-25 16:40 • by Z00n3$!$ (unregistered)
358469 in reply to 358464
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!

Re: Double Line

2011-08-25 17:01 • by Cad Delworth
358472 in reply to 358396
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.

Re: Double Line

2011-08-25 17:05 • by Matt Westwood
358474 in reply to 358472
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.

Re: Double Line

2011-08-25 17:18 • by Abso
358476 in reply to 358474
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.

Re: Double Line

2011-08-25 17:18 • by SR. HAKKRR (unregistered)
358477 in reply to 358461
Matt Westwood:
it's not really feasible to use COBOL for scientific applications.
You. Are. No. Fun. At. All.

Re: Double Line

2011-08-25 18:05 • by Kittens (unregistered)
358480 in reply to 358392
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)

Re: Double Line

2011-08-25 18:11 • by Jimbo (unregistered)
358481 in reply to 358435
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!!

Re: Double Line

2011-08-25 18:15 • by HaleRazor (unregistered)
358482 in reply to 358404
I was thinking the same thing...Single Responsibility principle.

Re: Double Line

2011-08-25 18:35 • by Sol the Sun God (unregistered)
358484 in reply to 358474
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?

Re: Double Line

2011-08-25 18:51 • by Spork
358486 in reply to 358392
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.

Re: Double Line

2011-08-25 19:09 • by killahdz (unregistered)
Might as well make the property generic too


public T GenericSettingAssociatedToStorePriceChangesForStoreProductPriceIfTypeIsStorePriceElseThrowsExceptionForTypesDerivedFromItemPriceAndMayUpdateProductPriceDependingOnTypeAlwaysUpdatesProductModifiedTimestampButDoesNotModifyAProductThatHasNonDefaultPricingAlreadySometimesExceptWhenSettingIsNotNull
{

set;

get;

}

Re: Double Line

2011-08-25 19:11 • by Chris (unregistered)
358489 in reply to 358438
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.

Re: Double Line

2011-08-25 20:21 • by foo (unregistered)
358491 in reply to 358412
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();

Re: Double Line

2011-08-25 21:30 • by Son Of Thor (unregistered)
I create functions that are just as meaningfull

public bool foo
{
....
}

Re: Double Line

2011-08-25 23:26 • by Scarlet Manuka
358495 in reply to 358474
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.

Re: Double Line

2011-08-25 23:27 • by Hatshepsut
358496 in reply to 358451
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?!?

Re: Double Line

2011-08-26 00:05 • by All the fake fritsen, as one (unregistered)
358497 in reply to 358496
[quote user="Hatshepsut"][quote user="Z00n3$!$"]

You wore down 3 pencils wanking?!?

[/quote]

Who hasn't done something like this?

Re: Double Line

2011-08-26 01:30 • by Matt Westwood
358499 in reply to 358480
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"!

Re: Double Line

2011-08-26 03:20 • by takes one to know one (unregistered)
358502 in reply to 358481
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?

Re: Double Line

2011-08-26 03:50 • by Nyarlathotep (unregistered)
358503 in reply to 358502
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.

Re: Double Line

2011-08-26 03:50 • by 'nuff said (unregistered)
My representative line of the day. Describing the code quality of a web site I was asked to check:
<td class="header">

'nuff said.

Re: Double Line

2011-08-26 04:02 • by Scourge (unregistered)
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?

Re: Double Line

2011-08-26 04:16 • by dkf
358506 in reply to 358476
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.

Re: Double Line

2011-08-26 04:32 • by Wody (unregistered)
The function is incomplete. It should be:

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

Re: Double Line

2011-08-26 04:51 • by ThomasX (unregistered)
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.

Re: Double Line

2011-08-26 06:05 • by keigezellig
Hmmm.. If this property is really implemented like it name says, then it has side effects which is not done...

Re: Double Line

2011-08-26 06:37 • by Anonymouse (unregistered)
358515 in reply to 358434
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.

Re: Double Line

2011-08-26 09:14 • by Z00n3$!$ (unregistered)
358519 in reply to 358495
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?

Re: Double Line

2011-08-26 09:24 • by kilroo
358520 in reply to 358499
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.

Re: Double Line

2011-08-26 09:31 • by C (unregistered)
358521 in reply to 358397
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)));

Re: Double Line

2011-08-26 11:03 • by gallier2 (unregistered)
358554 in reply to 358474
[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.

Re: Double Line

2011-08-26 11:13 • by grumpy (unregistered)
358556 in reply to 358484
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.

Re: Double Line

2011-08-26 11:48 • by Schol-R-LEA
358565 in reply to 358461
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.

Re: Double Line

2011-08-26 13:53 • by doozer (unregistered)
358586 in reply to 358410
Very good

+100000000

Re: Double Line

2011-08-26 13:54 • by doozer (unregistered)
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

Re: Double Line

2011-08-26 14:00 • by D-Coder
358589 in reply to 358491
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?

Re: Double Line

2011-08-26 16:44 • by The Great Lobachevsky
358599 in reply to 358505
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"

Re: Double Line

2011-08-27 09:31 • by Blizzaga (unregistered)
/// <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
« PrevPage 1 | Page 2 | Page 3Next »

Add Comment