Comment On Many Shades of Cout

That's one way to deal with C's case sensitivity I suppose. Or is it its user insensitivity?

"Find and replace" is sooo useful...

But they got it up and running faster, so it was the right decision from a business standpoint.

Yeah. Right.

Ho, that was a funy one!!

Putting those declares as a lazy workaround so they don't have to spell it right is just stupid. Might as well shoot yourself in the foot, cause its going to hurt later anyway.

Isn't the real WTF here that Andy would want to use cOut as a variable name? I mean, if I wanted to make string consisting of a bunch of Fs, I wouldn't call it printF and if I wanted to determine if some value was in a set called T, I wouldn't delcare a boolean called inT. Do I have a point, or do I have no idea what I'm talking about (it's been about 10 years where I did any programming of consequence)?

At least he sorted the lines somewhat binary:
0000 COUT
0001 COUt
0010 COuT
0011 COut
etc.

This is a What The Fuck (capitalized) like i've not seen in a loong time

Ackshooerry:

Isn't the real WTF here that Andy would want to use cOut as a variable name? I mean, if I wanted to make string consisting of a bunch of Fs, I wouldn't call it printF and if I wanted to determine if some value was in a set called T, I wouldn't delcare a boolean called inT. Do I have a point, or do I have no idea what I'm talking about (it's been about 10 years where I did any programming of consequence)?

I was thinking the same. It's kinda two wtfs in one. Andy does one by choosing a potentially ambiguous name, the previous program did one by being incapable of keeping their fingers on (or off) the shift key.

Ahem. And running replace on code to fix the typos was too onerous? I mean WTF? This was apparently the only clash with a variable so running a replace was safe.

BTW: to whiners about ambiguity of c0ut, look carefully. Its not O. its a zero. NOT ambiguous even least bit without the block from nutty spelling-indifferent coder.

EDIT: My bad. It is an O. The font fools ya.

Ackshooerry:

Isn't the real WTF here that Andy would want to use cOut as a variable name? I mean, if I wanted to make string consisting of a bunch of Fs, I wouldn't call it printF and if I wanted to determine if some value was in a set called T, I wouldn't delcare a boolean called inT. Do I have a point, or do I have no idea what I'm talking about (it's been about 10 years where I did any programming of consequence)?

Um, there's no way a poor variable name (cOut) is as bad as def'ing every possible capitalization of a keyword because you can't friggin type.

I like ucout and ucot. I wonder if there's an epcot.

I'm wondering why the code wouldn't compile ?
It is legal to declare

void Serialize(ostream& cout, vector<CRcpt>& rRcpt) {  ...  }

and use of "cout" inside the function would correctly refers to the parameter.

The only problem I see is if he wants to access the global "cout" from inside the function (for debugging purpose??)

webrunner:

I like ucout and ucot. I wonder if there's an epcot.

Let's hope there's no UCUNT.

I suspect the reverse - I suspect all the capitalisations were defined precisely to stop people declaring variables called some variant of cout. It's a bad name to be using.


Cheers,
Ian

Every now and then we get one that is just too hard to believe. Why would anybody *do* such a thing? How could anybody have ever gotten away with such a thing, if they tried it?

Was this project coded by chimpanzees or something, with one (human) coder in charge of setting up enough DEFINEs so that the random keybashing of the chimps might have a chance of compiling?

Xepol:

That's one way to deal with C's case sensitivity I suppose. Or is it its user insensitivity?

Ahem... cout? In C?

More likely C++

Ian McCall:

I suspect the reverse - I suspect all the capitalisations were defined precisely to stop people declaring variables called some variant of cout. It's a bad name to be using.

Did they similarly protect all the other keywords in the language and all other functions, types, and variables of the standard library? Why stop with cout?

Also, "ucot" is not close enough to cout to be deserve being caught by such a trap. Unless someone was just being an asshole.

death:

BTW: to whiners about ambiguity of c0ut, look carefully. Its not O. its a zero. NOT ambiguous even least bit without the block from nutty spelling-indifferent coder.

EDIT: My bad. It is an O. The font fools ya.

You look :)
It would be ambiguos even if it was zero.
Any guidebook of good programing practices tells you not to use O or l where it could be mistaken for zero and one respectively.

This is worse than making a CPP macro named current.

Yes, I got bit by that. Caused me twenty minutes of confusion, frustration, and swearing at GCC for not making sense.

Licky Lindsay:

Ian McCall:

I suspect the reverse - I suspect all the capitalisations were defined precisely to stop people declaring variables called some variant of cout. It's a bad name to be using.

Did they similarly protect all the other keywords in the language and all other functions, types, and variables of the standard library? Why stop with cout?

Also, "ucot" is not close enough to cout to be deserve being caught by such a trap. Unless someone was just being an asshole.

The hiccough would come in like so:
void sayFoo( std::ostream &Cout ) {
cout << "Foo!" << std::endl; // Whoops!
}

As an aside, the problem here -- if this were a spell-check for the incredibly lazy -- is the use of #defines. If you declare:
std::ostream &Cout = cout;
std::ostream &cOut = cout;
...

You get the spell-check effect without removing the ability of others to use the name in other contexts.

I am a pretty dyslexic typist, often getting the right letters in the wrong order. Sometimes my commonest mis-typing of 'Count' seems strangely appropriate to my mood.

"Avoid macros. Do not ever ever ever even consider starting to think about writing a macro that is a common word or abbreviation." -- Herb Sutter

I bet the guy who wrote that was a vb programmer...
"nah, if we used vb we wouldn't have this problem, stupid c++ compiler!"

Choose VB!!!
Choose VB!!!
Choose VB!!!
Choose VB!!!
Choose VB!!!
Choose VB!!!
Choose VB!!!

captcha : kungfu

one developer at my first job added macros like these to every project he worked on:
#define FLASE FALSE
#define retrun return

very confusing when you spot a typo and yet the code compiles anyway.

k:

I am a pretty dyslexic typist, often getting the right letters in the wrong order. Sometimes my commonest mis-typing of 'Count' seems strangely appropriate to my mood.

Maybe you should go into management.

jack:

The hiccough would come in like so:
void sayFoo( std::ostream &Cout ) {
cout << "Foo!" << std::endl; // Whoops!
}

I still go with my "monkeys with typewriters" theory.

It was the best of times, it was the blerst of times.

I would like to slap the original developer around a bit with a large cout.

Now, if only there was an easy way to allow the "public" keyword in Java to be redefined as "pubic", because I find myself making that typo quite a bit. Not sure why.... :-/

Ackshooerry:

Isn't the real WTF here that Andy would want to use cOut as a variable name? I mean, if I wanted to make string consisting of a bunch of Fs, I wouldn't call it printF and if I wanted to determine if some value was in a set called T, I wouldn't delcare a boolean called inT. Do I have a point, or do I have no idea what I'm talking about (it's been about 10 years where I did any programming of consequence)?

To me, CamelCase has a direct mapping to "camel_case" (and in languages where '-' is valid in identifiers, 'camel-case'), so I read

printF

as equivalent to

print_f

although I wouldn't use

inT

because that's obviously an object of type 'in', as in:

typedef struct in in_t;

Besides, everyone<tm> knows boolean function names are of the form "predicateP", as in

inTP

Mark H:

one developer at my first job added macros like these to every project he worked on:
#define FLASE FALSE
#define retrun return

very confusing when you spot a typo and yet the code compiles anyway.

Feh. If you can't spell, you can't program computers.

It's especially bad when you have big C++ class hierarchies full of virtual methods--the code compiles happily, but the behavior at runtime is as random as the spelling.

It almost makes you want to have some way to declare in C++ "this method overrides an existing virtual method of the base class, and if there isn't one then stop compiling RIGHT NOW." Actually there's nothing almost about it, I really want that feature.

In the past I found a way to deal with this: if I find a single spelling mistake in the code, I reject the entire code submission at review time, and I don't say where the error was. (Just to prevent all coding from coming to a dead halt, I publish a list of misspelled/correctly spelled word pairs to the group as needed). The worst offender got some kind of spell-checking code editor plugin instead of learning to spell on his own, but at least it fixed his code for him.

Zygo:

It almost makes you want to have some way to declare in C++ "this method overrides an existing virtual method of the base class, and if there isn't one then stop compiling RIGHT NOW." Actually there's nothing almost about it, I really want that feature.

C# has the override keyword, that will stop compilation if the parent class doesn't have any such method. It also has the new keyword that specifies that your method just happens to mask another with the same signature, but the parent shouldn't use it.

Addendum (2007-07-09 12:56):
You could also use pure virtual methods, since you're using C++. It will stop compilation when it doesn't see a matching override.

Personally, I never want to go back to C++ since using C#.

zip:

Um, there's no way a poor variable name (cOut) is as bad as def'ing every possible capitalization of a keyword because you can't friggin type.

And cOut may be a very natural variable name at that. After all, it may be a character you want to output somewhere. Or it could be the output character mode, or plenty other meanings that are perfectly logical...

Not included, but immediately below those lines:

// Just in case...

#define String string

#define strnig string

#define strng string

#define stringg string

...

...

You can't be too careful, right?

That's how namespaces are your friends.

void Serialize(ostream& cout, vector<CRcpt>& rRcpt)
{
cout << "Hi, this is the argument cout";
std::cout << "Hello, this is the global cout";
::cout << "Howdy, this is the ultimate global cout."
<< "Note that I don't belong to any namespace";
}

Sorry for the duplicate post, I didn't understand the difference between the reply and quote button. I thought replying to that comment would have some link to that comment. Anyways, here is the original post I replied to so you have some context.

Wizou:

I'm wondering why the code wouldn't compile ?
It is legal to declare

void Serialize(ostream& cout, vector<CRcpt>& rRcpt) {  ...  }

and use of "cout" inside the function would correctly refers to the parameter.

The only problem I see is if he wants to access the global "cout" from inside the function (for debugging purpose??)

That's how namespaces are your friends.

void Serialize(ostream& cout, vector<CRcpt>& rRcpt)
{
cout << "Hi, this is the argument cout";
std::cout << "Hello, this is the global cout";
::cout << "Howdy, this is the ultimate global cout."
<< "Note that I don't belong to any namespace";
}

Oh, I see.

"144592 in reply to 144515"

So there was a link to the comment I replied to. Oops.

I've considered doing this sort of thing, but in the shell rather than the code. When I make stupid typos typing in the shell they don't get preserved for posterity.

Namespace:

Oh, I see.

"144592 in reply to 144515"

So there was a link to the comment I replied to. Oops.

No one's holding it against you, baby. The forum's interface is terrible.

Worf:

zip:

Um, there's no way a poor variable name (cOut) is as bad as def'ing every possible capitalization of a keyword because you can't friggin type.

And cOut may be a very natural variable name at that. After all, it may be a character you want to output somewhere. Or it could be the output character mode, or plenty other meanings that are perfectly logical...

Like I wrote above, there are perfectly logical reasons for why one might want to name a variable printF or inT as well, but that doesn't make it okay. I find it ironic that Andy would submit this code as a WTF, when tomorrow I could probably submit Andy's code with a comment like, "This guy at my work uses variables with names like cOut. I mean, WTF?!?" and he would ragged on in the comments. Those who don't live in WTF-proof houses, and all that...

You forgot to mention

<code>
#define coitus cout // What The Fuck?
</code>

it is scary that someone would do that, too much effort. Just Find/Replace the vble one Case sensitive.

with regard to def'ing the combos of capitalization versus using a VERY bad variable name (in C anyways), im not so sure the former is worse. at least the multiple definitions are to a keyword and not a variable type itself,

by the above i mean to say the def's are of a keyword rather than using a bastardization of a keyword as a variable (oooh, long nite). i dont know why you would want to use a keyword as a variable

Zygo:

To me, CamelCase has a direct mapping to "camel_case" (and in languages where '-' is valid in identifiers, 'camel-case'), so I read

printF

as equivalent to

print_f

although I wouldn't use

inT

because that's obviously an object of type 'in', as in:

typedef struct in in_t;

Besides, everyone<tm> knows boolean function names are of the form "predicateP", as in

inTP

That should probably be inTPS.

bobday:

Namespace:

Oh, I see.

"144592 in reply to 144515"

So there was a link to the comment I replied to. Oops.

No one's holding it against you, baby. The forum's interface is terrible.

What's sad is how much better it is than the old (still-breathing in the sidebar) one. Except avatars. I really miss avatars, have no idea who anyone is anymore. ;_;

Mark H:

one developer at my first job added macros like these to every project he worked on:
#define FLASE FALSE
#define retrun return

very confusing when you spot a typo and yet the code compiles anyway.

You know, all the need for this would go away if only symbol tables used fuzzy matching. In fact, that's such an obvious(ly good) idea that I'm surprised no compiler has adopted it already - not even Intercal, which is usually such a pioneer of language features whose usefulness has yet to garner the widespread appreciation they deserve.

Thank goodness for the C preprocessor. How else could one so gracefully make up for such a linguistic omission?

Wizou:

I'm wondering why the code wouldn't compile ?
It is legal to declare

void Serialize(ostream& cout, vector<CRcpt>& rRcpt) {  ...  }

and use of "cout" inside the function would correctly refers to the parameter.

The only problem I see is if he wants to access the global "cout" from inside the function (for debugging purpose??)

If he did a "using namespace std;" or a "using std::cout" you in the namespace of this function you could go "::cout" to get the global.

otherwise "std::cout", or if you really want to be pedantic "::std::cout"

(For those of hard of thought - or just woke up - quotes ("") are to be omitted in the rendering of the code)

Zygo:

Besides, everyone<tm> knows boolean function names are of the form "predicateP", as in

inTP

...is the given parameter a Thinker...?

Zygo:

I find a single spelling mistake in the code, I reject the entire code submission at review time, and I don't say where the error was.

Glad I don't work with you, and I'm a meticulously accurate speller.

#define begin {
#define end }