• MoonGlum (unregistered) in reply to anonymous

    Respect to this post :)

    This WTF is indeed a 2-in-1 and a prime example of how not to code present and past. Never in a million years is it okay to use cOut as a variable name, and all those #defines to cater for the possibility of typos...

    It is people like this that give software engineers a bad name. Throw them out, they are imposters!

  • (cs)

    This is why code should be case insensitive. Who would create a variable called cOut?

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

    You laugh, but I've long thought that it would be really cool if compilers came with a spell checker for sort of that purpose. I wouldn't have them correct things for you, but it could at least say "'mlaloc' undefined: did you mean malloc?" in the error message.

    If it were really slick, it could be interactive and ask you if you wanted to correct the source.

    (Same deal with at least some other syntax issues.)

  • Ken Hagan (unregistered) in reply to sir_flexalot
    sir_flexalot:
    This is why code should be case insensitive.

    I'm not sure this WTF can be cited as a reason for anything, except perhaps the introduction of the death penalty for pre-processor abuse.

    On the other hand, I am no great fan of case-sensitivity in code. It is immoral to distinguish between two identifiers solely by case, since screen reading software can't distinguish between them and so the practice makes life difficult for programmers with impaired vision. It some jurisdictions, it might be construed as a gratuitous barrier to employment, which raises the pleasant possibility of the original author of this WTF spending time in jail for their sINs.

  • iMalc (unregistered)

    This is the funniest WTF I've seen in ages!

    [sarcasm] Of all those time I accidentally typed 'retrun' or 'flase' or 'ture' 'viod' or ... Why did not think of that! [/sarcasm]

  • Stefan W. (unregistered)

    due to european education, I often type

    ovid // instead of void

  • (cs) in reply to EvanED
    EvanED:

    You laugh, but I've long thought that it would be really cool if compilers came with a spell checker for sort of that purpose. I wouldn't have them correct things for you, but it could at least say "'mlaloc' undefined: did you mean malloc?" in the error message.

    If it were really slick, it could be interactive and ask you if you wanted to correct the source.

    (Same deal with at least some other syntax issues.)

    Actually, Visual Studio 2005 does offer something like that, at least in the VB editor. It actually catches those mistakes (use of a superfluous letter, inversion of two letters and so on) and proposes a correction to the closest correct symbol. It does not work on keywords though, only on types/variables.

  • Plunder Bunny (unregistered)

    In the source base I work on for my day job (a 10+ year old C/C++ application), I once found an interesting alternative to using a union. It went something like this (apologies for any syntax errors - this is pseudo-code):

    typedef struct { ... int someVariableName; ... } WHATEVER;

    #define AnotherVariableName someVariableName

    (needless to say, I killed it)

  • Anonymous (unregistered) in reply to EvanED

    Smalltalk IDEs will do this for variables, classes, and message sends; Squeak at least will give a list of the closest matching symbols and offer to declare the variable, create the class, ignore, etc.

  • (cs) in reply to Spud

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

    Spud:
    #define begin { #define end }
    std::copy
  ( 
    rRcpt.begin(), rRcpt.end(), 
    std::ostream_iterator< CRcpt >( cOut, "\n" )
  );

    except that redefining begin and end will break that, of course. (It will break #include <vector> in fact, as well as <string> etc).

    The programmer is not all innocent though.

    void Serialize(ostream& cOut, vector<CRcpt>& rRcpt)

    Not const-correct. You don't modify the vector when you output it. And should use std::ostream & and std::vector, not "using namespace std". Finally style issues: function names should begin with lower-case letters and classes should not be given a C prefix so class Rcpt not CRcpt.

Leave a comment on “Many Shades of Cout”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article