• (cs)

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

  • (cs)

    "Find and replace" is sooo useful...

  • (cs)

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

    Yeah. Right.

  • Lloyd (unregistered)

    Ho, that was a funy one!!

  • (cs)

    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.

  • Ackshooerry (unregistered)

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

  • (cs)

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

  • espinafre (unregistered)

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

  • lbp (unregistered) in reply to Ackshooerry
    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.

  • (cs)

    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.

  • (cs) in reply to Ackshooerry
    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.

  • (cs)

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

  • Wizou (unregistered)

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

  • anonymous (unregistered) in reply to webrunner
    webrunner:
    I like ucout and ucot. I wonder if there's an epcot.

    Let's hope there's no UCUNT.

  • Ian McCall (unregistered) in reply to lbp

    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

  • (cs)

    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?

  • S (unregistered) in reply to Xepol
    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++

  • (cs) in reply to Ian McCall
    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.

  • jethrotull (unregistered) in reply to death
    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.

  • (cs)

    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.

  • jack (unregistered) in reply to Licky Lindsay
    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.

  • k (unregistered) in reply to anonymous

    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.

  • Number6 (unregistered)

    "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

  • kupal (unregistered)

    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

  • Mark H (unregistered)

    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.

  • j (unregistered) in reply to k
    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.

  • (cs) in reply to jack
    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.

  • (cs) in reply to Licky Lindsay

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

  • Anonymous (unregistered)

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

  • Zygo (unregistered) in reply to Ackshooerry
    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
  • Zygo (unregistered) in reply to Mark H
    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.

  • (cs) in reply to Zygo
    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#.

  • Worf (unregistered) in reply to zip
    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...

  • James (unregistered)

    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?

  • Namespace (unregistered) in reply to Wizou

    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"; }

  • Namespace (unregistered) in reply to Wizou

    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"; }

  • Namespace (unregistered)

    Oh, I see.

    "144592 in reply to 144515"

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

  • (cs) in reply to pitchingchris

    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.

  • (cs) in reply to Namespace
    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.

  • Ackshooerry (unregistered) in reply to Worf
    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...

  • AdT (unregistered)

    You forgot to mention

    #define coitus cout // What The Fuck?
  • (cs)

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

  • jaymz (unregistered) in reply to zip

    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,

  • jaymz (unregistered) in reply to jaymz

    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

  • (cs) in reply to Zygo
    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</div></BLOCKQUOTE>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. ;_;

  • (cs) in reply to Mark H
    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?

  • (cs) in reply to Wizou
    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)

  • (cs) in reply to Zygo
    Zygo:
    Besides, everyone<tm> knows boolean function names are of the form "predicateP", as in 
    inTP</div></BLOCKQUOTE>

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

  • Bob Loblaw (unregistered) in reply to Zygo
    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.
  • Spud (unregistered)

    #define begin { #define end }

Leave a comment on “Many Shades of Cout”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article